Why It Pays to Care About the Happiness of Your Software Developers
I thought about starting with a quote from the Dalai Lama about being wisely selfish but then I thought, no, that’s immediately going to alienate a bunch of people who really might need to read this. So instead I’ll ask a couple of questions - how are your software development efforts going? Getting projects completed on time and near budget? Customers satisfied? Money rolling in? Developers sticking around? If the answers include no then I’d ask you to take the time to read this and consider if maybe the problem isn’t with the industry/sales team/techies/exchange rate/economy but instead with how happy your developers are. Here’s why it’s an idea worth pondering:
Cost of turnover
It is difficult to do the sums on what this ads up to but that is no excuse not to consider these costs. Some people think about 150% of the employee’s salary. I would argue for developers the cost is at least that high due to the complex nature of the job and the amount of accumulated knowledge needed to be productive on all but the most basic of systems.
Some of the factors to consider when calculating the cost of turnover:
- Recruiter fees or in-house hiring costs, the average here is 17% of the candidates salary.
- Lost productivity for managers and other staff who have to filter and interview candidates.
- Lost development time both for unhappy employees that quit and continuing employees who have to stop development to train new hires. Unless you work in a startup with a small codebase and straightforward business case this can take months. And that’s after you’ve managed to find the right candidate, not an easy thing in today’s market.
- Suboptimal productivity as other developers get up to speed on areas of the code or infrastructure that they were previously unaware of. We aren’t all experts in all of the things that are associated with technology, that’s why I don’t know what is wrong with your phone/tv/alarm system/camera.
- Loss of precious intellectual capital. We all try to write stuff down, but there’s not a wiki in the world that can mimic the cross-referencing and contextual depth of the human brain. Some of this capital will be lost for good to the detriment of your software, and the rest will have to be re-learned to the detriment of your bottom line.
- If someone leaves because they are unhappy they are either an outlier or representative of the way you manage your team. If it is the latter then team churn such as this is demotivating to the rest of the team. And a disengaged employee is an unproductive one.
Developers are in demand
This is a reality of the current job market and it doesn’t look likely to change anytime soon. And here’s something I’m sure you suspect might be true and yes, it is: writing code for a living is challenging and difficult and sometimes it is like pulling teeth and not everyone wants to do it. Good developers come in all shapes and sizes and strengths, when you find the right one for your team treat her well and you will reap the benefits. But if you don’t she’s probably not going to stress about it because there are a bunch of other companies lining up to offer her a job. She can even auction herself off to the highest bidder.
But that’s just if she chooses to go and puts the wheels in motion. Time and again I’ve seen developers leave because they’ve had a frustrating day (always with management, never with technology) and that was the day the recruiter emailed, like he does most days, with an opportunity no better or worse than average. This time she decided to reply instead of sending it straight to the trash. The new opportunity will be for more money and it will be working on shiny new stuff and you can’t compete with that. All you can do is put a little bit of effort into keeping her happy so she doesn’t answer the email. It is a sellers market. If you don’t accept that you will not be in a position to hire competent, reliable people.
Developers are not interchangeable
Software development is never the same from one project to another. It takes a while to build up a mental model of the system and from there make valuable contributions to improve it. Whenever you restructure or alienate a developer enough so that he leaves your company you will then be paying someone else for the time it takes them to build that mental model. And for the remaining developers’ time it will take to help them do so. You wouldn’t throw unused toilet paper in the bin, leave the air conditioner on all night or pay rent on empty buildings so why be careless with the less tangible but extremely valuable asset of mental capital?
This has been said over and over again but clearly needs repeating - paying for more developers does not speed up production or improve software quality. It decreases both and puts your project at risk. Developers are creative knowledge workers, each unique and valuable. Treat them as such.
Investing in employee happiness pays off
If you’ve finished this and are completely incensed by the smug, precious tone of this blog post, well that’s fair. I am acutely aware that there are lot of people who can’t make the case for better working conditions because they are worried they won’t be able to find work elsewhere. I fell into this profession through luck and have stayed in it because I like doing it. Now I manage developers and I love my job. But I’m sick of the dreadful waste I see around me because some of the people (not all!) who run companies don’t seem to understand the realities of this industry. It is my hope that improving conditions for some workers will have a ripple effect to all as the economic and human benefits of doing so become difficult to ignore.
All we want to do is build the best software for you that we can because we love making smart things that are useful to people. So work with us and let’s get it done. We’ll be happy, you’ll be rich and successful. Wisely selfish.