Happy Developers, Happy Checkwriters, and the Real Cost of Developer Turnover

Scrum, when used incorrectly, feels like a vise. Impossible, iron-clad expectations and poor grooming practices mean that every morning starts with dread, and every workday ends far later than the developer would like. As sprint progress starts to slip and the burndown line stays stubbornly above it’s smooth expected curve, the developer start blaming themself. “I must not be working hard/fast/effectively enough”. So they put in longer hours, develop a pronounced caffeine addiction, and continue to neglect their basic self-care needs (dishes pile up in the sink, fridges go bare, and gym equipment grows evermore dusty). At long last the sprint ends with stories mostly-finished, a slightly-disappointed Product Owner, and a developer who’s getting tired of this s@#&.

A shortsighted Product Owner will see this and think “So what? This developer was hired to deliver results, and they’re expected to do just that. If they can’t handle the hours we’ll replace them with some post-college wizkid who can”. What this Goofus fails to understand is how profoundly expensive high developer turnover can be. Estimates vary, but most studies on the cost of replacing a developer range from 0.75x to 2x their yearly salary. For a developer earning $90k, that’s a cost of $67,000 to $180,000 to truly replace their value. Yikes! Why are turnover costs that high?

Knowledge Is Capability

In software development, knowledge truly is power, and this knowledge extends far beyond having “leet hacking skillz”. With a free Sunday morning and a cup of coffee in my hand I attempted to map at a high-level all the different forms of knowledge that a good software engineer needs. Below’s what I came up with, and I’m certain I’ve barely scratched the surface with this list:

And for people who can’t read chicken scratch that looks like the chicken chugged straight vermouth all day:

Engineering Knowledge

The most obvious mark of a good engineer is their ability to develop secure, usable, maintainable, extendable, scalable, available, performant, portable, efficient, and testable solutions to meet complex requirements in whatever languages/tech suits the situation. This requires a range of abilities from having a solid architectural vision, to thoughtfully implementing effective solutions, to thoroughly testing the system’s response to every conceivable scenario (because if an end-user can break it, they will), to quickly understanding & repairing the root-cause of bugs. No wonder engineering’s such a well-paid field!

Luckily for turnover-inducing checkwriters, engineers carry these skills from company to company, honing them over the course of a career. You can always find another good engineer if your offer is good enough. Unluckily for said checkwriter, these skills only account for part of what makes a great engineer.

Domain Knowledge

Many companies still try to create a clear line between business’s & IT’s scope of responsibility & knowledge. Business people/Product Owners learn the end users’ needs, dream up a product vision, write detailed requirements, and chuck them over the wall to IT. IT then directly plugs these detailed requirements into their business-logic layer, and builds the application around it.

This approach seems preferable to Product Owners, since it turns software development into a commodity and engineers into replaceable resources (like cogs in a machine). Many developers also prefer this approach, since they’re not distracted by annoying business meetings and can focus all their attention on coding. Unfortunately project after project has shown that this approach usually doesn’t work. Business-speak is drastically different from code-speak, and though BDD tools like Cucumber have attempted to mitigate this problem, there’s always implied requirements that Product Owners fail to express in words, and requirement misinterpretation/assumptions made on the IT side. Therefore an IT team with solid domain knowledge can be a godsend to any project. Developers should understand enough about their users and good software design to develop a “spidey-sense”, that allows them to build software for their users, while conforming to requirements. Software can tick every requirements box, but be slow, clunky, and confusing. A developer should be able to put “user goggles” on, build, and test their software from the perspective of an end user trying to achieve a certain goal or realize a certain experience. When developers leverage their domain knowledge and build from the perspective of their users, not only will their software meet requirements, but it’ll be a joy to interact with and provide a wealth of benefits.

Domain knowledge represents the main cost of developer turnover. High-quality engineering practices transfer from company to company, and new languages/technologies/systems can be learned by any skilled developer. But the domain knowledge and business sense that a good engineer picks up from their time in the company can work wonders for delivering value. Not only is a domain-savy engineer better than a new-hire at accurately interpreting requirements, they can also help advise the product owner on how to efficiently deliver value, due to knowing both what users want and the work required to deliver it. To loose these developers is to loose a large chunk of useful knowledge.

Interpersonal Knowledge

Though many of the qualities outlined in Interpersonal Knowledge transfer well from company to company, never underestimate the need for networking & connections in the field of software. American culture paints a charactiture of programmers as overweight weirdos with an aversion to natural light, unhealthy Doritos addiction, and inability to speak to anyone “IRL” (think Comic Book Guy from The Simpsons). Though this may represent some members of the community, and indeed most developers consider themselves introverts by nature, development attracts all kinds, and there’s a lot of interpersonal communication that goes on in a professional developer’s daily life. Outside of working effectively with a team of widely skilled individuals from vastly different backgrounds, in many larger companies developers need to constantly reach out to other departments for help with infrastructure or integrating with other systems. Having a rolodex of contacts throughout the company can help a developer work wonders in a short amount of time, and this rolodex can only be built through time and experience with the company. To loose all senior developers and replace them with new-hires can leave the new team floating on an island, unsure of where to go when things outside of their control break.

Turnover is Expensive

So while I’m not saying to pamper developers and let them take every Friday off (though I wouldn’t mind that…), organizations must consider the pressure they place on these people with families, hobbies, and houses to keep clean. The churn-and-burn model of staffing doesn’t work well in such a Knowledge-focused field as software development.