7 Components of Developer Retention

by Mechaferret on September 4th, 2009

I spend a significant percentage of my time doing recruiting. Much of this is the natural consequence of building teams in a growing company — but some of it is replacing people who have left. The latter recruiting can be frustrating, not to mention expensive: we all know about acquisition costs and ramp-up time and the value of human capital. I’d always rather retain an existing employee (assuming they are good, and I try not to hire them if they are not good) than hire a replacement.

To that end, I’ve compiled a list of what I believe to be the 7 essential components for retaining software developers. They are structured in a nontechnical-executive-friendly way (since, in fact, I originally came up with them to present to my nontechnical-executive manager). Some of them are things you may not have much control over (for instance, you may not be able to change your company’s product line so that it qualifies as “cool”), but at a minimum being aware that your company is lacking in one area might allow you to build up some of the others to compensate.

The 7 Essential Components for High Retention Levels for Software Developers

  1. Cool productsThe hallmark of a good software developer is their desire to work on products that are (a) meaningful and (b) interesting. Doing an in-house CRM for a bank or an inventory management system for an auto dealer is almost certainly interesting; developing a social-network-based recommendation engine or a location-aware iPhone app almost certainly is.Now, as a hiring manager, you may not have a lot of control over the products you work on. If they are already cool, you’re set. If not, perhaps you could propose some small interesting side projects. Or resign yourself to high turnover and/or hiring people who don’t have to care about what they do.
  2. Cool technologiesMost software developers have a strong preference for working with interesting new technologies. Sometimes, even in great jobs, business necessity requires working in non-choice technologies: you’re rewriting the entire web site in Rails, but there’s a new product that you need to support in the old Perl purchasing code right now. However, business constraints like schedule and budget should be the only reasons that non-preferred technologies are used; a happy development team is one in which technology choices are left to technologists rather than business people as much as possible.Recent examples of how this should work: (1) choosing to use Rails instead of CodeIngiter on a new application, even though the previous application is in PHP, and having the only input from executive management be “Wow, you do seem to be developing much faster”; (2) replacing a proprietary third-party SIP stack with Asterisk, even though it will take 6 months, because the delay our biggest customer is complaining about will never be fixed in the proprietary stack and we can fix it ourselves in Asterisk since it’s open source, and then we won’t have to spend another $500K on licenses at the end of the year to support our traffic growth.

    Current cool technologies¹: Rails (may be reaching saturation), Django, jQuery, RabbitMQ, Hadoop, iPhone apps, location-aware apps

  3. Cool hardwareProviding developers with high-end hardware makes sense from a pure productivity perspective: it makes no sense to have your expensive developer sit and wait for 5 minutes to load a page to test because they are running on a Celeron computer with 256MB of RAM. However, it also carries hiring and retention benefits. Tech people like shiny new hardware. I have seen a candidate accept an offer that was $12K less than a competing offer but provided a high-end Macbook Pro instead of a Windows machine.
  4. Career pathPeople like to feel that they are growing. The simple satisfaction of learning new things and working with cool new technologies can satisfy a lot of that (see #2), but if you still have the same job duties and responsibilities year after year after year, even the learning can start to seem routine.In big companies, career paths are handled naturally by having a hierarchy of titles and responsibilities: you move from junior developer to senior developer. If the team consists of one junior developer and a CTO, however, it may look like there’s nowhere for the junior developer to go. That isn’t actually true: the junior developer can still take on greater responsibilities and move up to senior developer even if there aren’t 1000 other junior developers to be compared with. Managers just need to make sure that they call out this movement explicitly, possibly with titles but more importantly with increased responsibilities: pull aside your junior developer and say, “I’ve been impressed with your progress, so I’m going to put you completely in charge of a part of our next release.”

    Not doing that risks having your developers leave for another position because they “feel I’ve gone as far as I can here.”

  5. Respect as professionalsSoftware developers are professionals, plain and simple, just like lawyers or architects. Too often, however, they are treated more like construction workers than architects.  Managers should seek out the technology advice of their developers, instead of disregarding it as being of no more value than a suggestion from a temp in the call center. There’s no easier way to infuriate good software developers than to fail to give them respect as professionals, and that’s also the quickest way to get them to quit.
  6. Respect for the work of creationA software developer is staring blankly at a screen, or wandering around randomly, or sketching something on a pad, then putting it down, then picking it up again, then reading a blog. This is not goofing off. It’s trying to come up with a good design, or figure out a tricky algorithm, or fix a baffling bug. Insisting that your developers always look busy may make managers feel better, but it makes for much less actual productivity. Again, if you want to judge your developers the way you judge your outbound sales people, resign yourself to high turnover and low-quality developers.This need is of course not unique to software development: Obama’s campaign team knew when to play Rock Band.
  7. Schedule downtimeThe realities of scheduling software development are that (1) it’s hard to estimate the time to complete a given task accurately (2) estimates are almost invariably too low rather than too high (3) the obstacles to the business pressure to meet the estimates anyway are lower than other activities because there are few absolute physical constraints (e.g., if the concrete foundation hasn’t set yet, you can’t begin building the walls no matter how much pressure you’re under) (4) the people who write software tend to like to stay up late and consume caffeine. Add these together and you have a recipe for teams working 20-hour days, seven days a week, to meet a deadline. Even when a team isn’t on a death march to meet a deadline, the rhythm of software development often results in longer hours as deadlines come up, especially if the deadline is important to the business. Most developers understand that and are fine with it (some may even enjoy it²).What isn’t fine, however, is that after the team does put in the extra hours to meet a deadline, they aren’t allowed any downtime. The week after a tight deadline should be “light work” (or even “comp time”), not “business as usual”. And the next tight deadline needs to be a few months out, not two weeks later.

    It would seem obvious that if you want people to put in long hours, you have to give them time to recover before expecting them to do it again. But many managers fall prey to either the fallacy of “since they worked that one week, they should be able to work that hard all the time” and thus schedule so that the team is always working long hours, or the fallacy of “there’s a minimum amount of work that should be achieved in a given day, and every employee should achieve at least that every day, no matter how much harder than that they worked the week before”. Both of these drive developers to lower productivity, exhaustion, burnout, and finally leaving for another job.

¹ This list of “cool technologies” is, of course, only my opinion.
² Yes, I fall into the “may even enjoy it” category.

From People

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS