So, I read The Daily WTF. It’s a funny blog, and occasionally can give you insight into bad and good programming practices. Also, occasionally, the person who runs the site, Alex Papadimoulis, writes a rant about something in the computer industry. Now, Alex is a bright guy, but I frequently disagree with some of his Soapboxes. Today (well, yesterday) is no exception.
First, let me say I think he’s right on many levels. You should always plan for people to leave, and you shouldn’t make believe that everyone will spend their entire career at a given company. You should be upfront with new employees about them leaving, as well as the potentials for improvement and empowerment. Promote based on skill, not tenure, and for the love of god, do not promote people to lead positions that cannot (or choose not to) lead.
In addition, foster alumni relationships for former employees and keep it alive; don’t treat former employees as exiles who don’t deserve the time of day. Always welcome them into the office with open arms. They helped you, and if they left on good terms (which they usually should unless you fire them) you should be happy to see them.
Here’s the one place where I don’t agree with Alex: keeping people around is almost always better than letting them leave, regardless of price, and benefits are not the only way to keep them. People leave because they get bored or they are no longer learning anything. But there are ways to fix that easily, I think, that will actually make your company money, as opposed to random benefits, which only cost you money.
- Encourage pet projects. Google’s 20% time here is awesome. Trust me, you can afford it. Even if you can’t always use the end result, it will keep your employees interested in their work, give you new products and / or tools, and in some cases will keep employees looking at new and educating themselves in interesting new technologies.
- Encourage mobility. Allow people to switch projects at almost any time (of course, restricting movement near the end of project cycles). This will encourage people to look at the other projects people are working on, and will keep them interested. In some cases, this will also keep them educated because they’ll get to work with people of different expertise levels throughout the company (though this only works if you’re working with many different technologies).
- Be agile with your process and listen to employee problems. If new (or old) employees don’t like their code review process, figure out why and try to fix it quickly. In many cases, employees may like what they’re working on, but don’t like the way things are being done, or how slowly change takes to complete. Be able to make process changes quickly or at least show that you are making progress on changing things.
- Lastly, be able to recognize when people are being resistant to change just for the sake of being resistant to change. They like doing it “their way” for whatever reason, but don’t ignore modern research into what makes good software just because certain people believe their way is better. In many cases, research proves them wrong.
Yes, you’ll never be able to keep people from leaving, but if people are willing and able to fulfill 90% of their personal and academic curiosity in an agile environment, you should be able to keep them until they decide they what to move to, say, a different state or work on something that’s completely outside of the bounds of what you’re company does. By just saying “people will leave,” you create a culture where the problems aren’t actually solved, and you’ll always have mediocre talent. By creating an atmosphere where people aren’t afraid to leave, but have no reason to, you get the best of both worlds.