10 reasons your star programmer may be looking to leave

Finding and hiring topnotch programmer talent can be time-consuming -- from reading resumes to interviewing candidates to making sure the ones you like don't decide to accept someone else's offer. Yet all too often, these hard-to-find (and hard-to-hire) employees are neglected once they come on board. Justin James looks at some reasons why your top programmers might be thinking about leaving -- and how you can persuade them to stay.

Top programmers are not easy to find. It takes time to cull through dozens, if not hundreds, of resumes to find the magic combination you want, and it takes hours to perform interviews. After all of that, you still need to jump through hoops to make sure that your best candidates accept your offer rather than someone else's.

Yet all too often, these hard-to-find (and hard-to-hire) employees are neglected once they come on board. While proper compensation is, of course, a large part of employee retention, the top programmers need more than a great pay check. Here are 10 reasons why your star programmer might be looking to leave, and what you can do to convince them to stick around.

Note: This information is also available as a PDF download.

#1: Poor pay

No one works purely out of a charitable nature. So when your best people feel like their pay is severely out of line with market standards, they may start to view other pastures as being much greener than yours. Your worst enemy in retaining the stars is the thought, "I am the worst paid senior developer in this town."

I see a lot of companies that look at what the market is like only when they hire someone. Meanwhile, your best people are often aware of what is happening in the market consistently. If you have not re-evaluated your pay packages in a while, you need to. While the package may have been competitive when you hired someone three years ago, your best employees may be able to get a substantial raise by making a lateral move (if not taking a higher level position) to another employer.

#2: An uncertain future

The best people often have no intention of leaving until something out of the ordinary prompts them to stick their toes in the job market waters. At one company where I worked, the trigger for a mass exodus was the sale of the building our employer was renting to a major company that obviously was not going to keep leasing to us. A lot of people panicked and wondered whether the loss of the office space would prompt a move of the operation to another city. Instead of sitting around waiting for the other shoe to drop, they left. At another company where I worked, a large layoff spooked those who survived, and they left as soon as they could.

There is little you can do to prevent these outside influences from occurring, but you can do a lot to reassure your people when they do happen. Your best programmers are not dumb; they know when you are trying to puff them up with hot air instead of being forthright. When these events happen, give your people the straight truth and show them what you and the company are doing to prevent the need for your stars to lose their jobs. It's a tough path to walk, but too many managers cave in to the temptation to cover up the problems — and those cover-ups tend to drive people out even faster.

#3: A tyrannical manager

Some managers don't just think they need their finger on the pulse of the organization, they think they need their jackboot on the back of the organization pinning it to the floor. While micromanagement may be needed for entry level and junior employees to help guide them, senior programmers resent it. After all, if you don't trust them to make their own decisions, why did you hire them instead of junior people?

Other managers simply do not know how to overrule a decision made on technical grounds for business reasons in a way that shows respect for the technical people involved. When your superstars feel like they are always under the microscope and will be punished if they take independent action, they will leave. So lighten up and loosen up a bit. Remember, these people are the cream of the crop, and they can make technical decisions on their own. If you do need to override them for business reasons, make sure that they understand why it is happening, that their views were fully considered and noted, and that they will not be held responsible for the outcome.

#4: Office politics

Programmers, as a group, generally do not enjoy playing office politics. Most of them just want to come in to work, do a great job doing the things they love to do, and keep learning and doing new things in the process. Getting involved in budget squabbles, playing the "blame game" over project failures, and participating in turf wars over responsibilities and resources just are not on their agenda. Programmers in these kinds of environments usually want to get out. So don't involve them.

As a manager, part of your job is to shield your team from the office squabbles. Let your team know that they should refer these problems to you and show them that you're working hard to keep them out of the internal brawls. Your people will appreciate your taking the fire for them and allowing them to do their jobs in peace.

#5: Work/life balance

It is impossible to hammer on this point enough. Your best programmers work hard. Most of them work a lot more than 40 hours per week. This can and will cause severe burnout, especially after a long stretch, such as what usually happens at the end of a project. It is up to you to make sure that they don't burn out, even if they don't see it coming. Sometimes, employees hoard vacation time throughout the year, so that they can have a long vacation during the winter holidays. (Or they're saving it for another big event, like an upcoming childbirth.) Other times, employees feel guilty about asking for time off in the middle of a big project. And of course, in many organizations, taking time off is fairly irrelevant since people on vacation are constantly being called, and they return to a huge mountain of work.

It is possible, but not easy, to make sure that your people take time off and get to relax while away from the office. For starters, offer people a three-day paid weekend here and there (much easier for salaried employees) when it won't harm a project, without deducting it from their accrued vacation time. And when people are on vacation, get them to leave the laptop in the office and spread as much of their workload out to other people so they come back refreshed and don't have to burn themselves out again playing catch-up.

#6: Stale job

Your best programmers probably do not want to be doing work that they find unchallenging or that does not teach them anything new. They became really good by doing and learning new things, not by sitting around writing boring, easy applications. When you offer these high achievers nothing but busy work, they get restless — and that restlessness can take them out the door. Periodically take the time to talk with your people and make sure that they're working on projects that are at an appropriate level of difficulty and that are holding their interest. It is usually better to transition bored employees to more interesting projects than to lose them altogether.

#7: Stalled projects

For many reasons, some projects just never seem to make progress. Customers are indecisive, requirements keep changing, there is a lack of resources... the list can go on forever. High achievers like to be successful, and top programmers are no different. When your best people are on projects that are going nowhere fast, they feel useless and get frustrated. Eventually, they leave. While no manager likes having these projects to begin with, recognize the fact that these kinds of projects kill morale. Take steps to keep the spirits up in the ranks.

#8: Lack of recognition

People who are among the best in any given field often expect to be treated as a cut above, and with good reason. It may not always be possible to treat your best people to bowls of M&M's with all of the brown ones removed, but it is quite within your power to treat them like they are topnotch people. One way of showing recognition is to defer to their judgment, as previously mentioned. You can also give them a bit of latitude to experiment and take risks. Your best people should have enough responsibility to do things like use some advanced techniques that you would not let a less experienced developer use. Giving them this chance shows them that you recognize their ability and that you trust them. You should never treat them like a junior or entry-level developer. That would make them think their years of experience are not valued or maybe not even noticed.

#9: Poor environment

Some environments just are not conducive to employee retention. In addition, your best people will probably have the most opportunities to leave, and they're less likely to need their current job as a resume builder. Put those things together, and you have a recipe for high desertion rates. So what can you do? Try to improve your environment. This covers a wide range of things, from the office furniture to the condition of the carpet to the difficulty in finding a parking spot to the attitudes of co-workers. Not everything is under your control, of course, and some people will never be happy no matter how great things are. But if you put some effort into improving the environment, your employees will notice.

#10: Things outside of your control

Many managers tend to assume that their employees' satisfaction is completely their responsibility. This is simply not the case. Just because your star is grumpy does not mean that it is your fault. His family might prefer it if they moved to another city, or her commute may be too long. You have no control over these things. While most employees will be reluctant to say, "I'm looking to leave" regardless of the reason, employees do verbalize unhappiness with non-work problems more than work-related issues. If you hear an employee mention a problem that a change in employers might correct, take heed.


Justin James is the Lead Architect for Conigent.

Editor's Picks