Limiting Developer Turnover

I wish I could title this article “Eliminating Developer Turnover”, but that’s not realistic. Turnover, especially among software engineers, is inevitable. Gone are the days of an employee staying at one company for their whole career. Now, job hopping is the name of the game. By my estimation, the average software engineer’s tenure is around 16 months. Zippia’s analysis of ~103K software developers provides a quantitative analysis [1]. They found 45% of software developers have an average tenure of 1 to 2 years, with a whopping 69% having a tenure of less than 2 years.

I tried finding the exact turnover rate via the U.S. Bureau of Labor Statistics (BLS), but that number doesn’t exist. Other online publications will state the turnover rate is 57.3% for software developers. This statistic is completely made up. I spent hours reading BLS reports, scratching my head, trying to verify how these other blogs came to this number. While BLS does capture turnover rates via its Jobs Openings and Turnover Survey (JOLTS), it doesn’t gather it for specific occupations. From what I can tell, the original article created a made-up statistic, then others referenced it without verifying.

While the 57.3% turnover rate is fabricated, the fact remains that software developers switch jobs…a lot. Even though we’re in a recession, I have a hunch that won’t change. Tech companies are laying off 10% to 20% of their workforce [2], but experienced developers aren’t out of a job for long. While I’ve personally noticed the resume quality and quantity trending upwards in the last couple of months, it is still an employee’s market, especially for mid-level and senior software engineers.

Regardless of the macroeconomic conditions, it’s important to keep developer turnover low. While programmers leaving your company is inevitable, it can be limited by taking proactive actions. Below are a couple of my best tips on how to decrease overall software engineer turnover. With a little bit of tweaking, these tips can be extended to all types of employees.

#1 – Are they Fairly Compensated?

I’ve found that the number one reason software engineers leave is due to salary concerns. Most developers feel like the only way to get a raise is to jump ship. Software career sites reinforce this by suggesting programmers should leave their job every one to two years. Oftentimes, when developers leave, they will get a $10K to $40K increase in compensation, which makes me think that companies aren’t being proactive with their raises.

Companies tend to bring in new hires at market rate, while existing employees tend to fall behind. Unknowingly, companies are incentivizing their most loyal employees to leave their current position by paying them less than what they’re worth. Giving an employee a raise that is under the rate of inflation pretty much guarantees they will be looking for another job soon. This is exacerbated in our current economic climate where official inflation numbers for 2021 were 7%, and in 2022 were 6.5% [3].

Not to mention, most companies don’t give meaningful salary bumps when a software developer gains seniority. There’s a massive difference between a junior, mid-level, and senior software engineer. Even within the tiers, there is gradation. For example, once a new college graduate gains a year of experience, the market says they deserve a large pay raise. For many companies, this is a bitter pill to swallow. With only one year of experience, this relatively new engineer is suddenly more valuable. It’s BS, but it is what it is.

I also must stress the word “fair”. Most companies can’t and shouldn’t compete against Amazon, Facebook, or Google’s compensation package. But the salary should be relatively competitive to the market they live in. It’s why I generally disregard resumes from high cost of living areas like New York City or San Francisco. While we could hire them, they would eventually think they were being treated unfairly and look for another job.

#2 Do they Fit the Company’s Work Modality?

A big part of limiting developer turnover is hiring the right person in the first place. This revolves around whether they fit the company’s work modality. I find the term “culture fit” vague, overused, and a catch-all. Instead, I focus on work modality as it describes how an employee is expected to work.

For example, employers either have a remote workforce, all in-person or hybrid approach. Developers, especially as they get more experienced, start to prefer one over the other. While you would assume they would all want to work remotely, that isn’t always the case. A lot prefer to work in-person as work is a social thing for them. They need collaborative brainstorming, personal interactions, and hanging out with their co-workers to keep them happy. Other employees like the flexibility of the hybrid approach–some days in-office, some days at home. Then, there are those who want to be fully remote with no commute. The most important thing is to hire someone who fits the company’s environment.

There’s more to work modality than just where work is happening. It can be anything from the number of meetings, to how the team communicates over Slack, or if cameras are required to be on during Zoom, or a host of other things. For example, at my company, we’re a team, not a family. This means we have zero social commitments. Instead of having a big company get together for the holidays, our employees would rather spend that time with their families. And our employees love that aspect of our company! That’s because we hired people that fit our work modality.

#3 Are they Constantly Learning or being Challenged?

Developers love learning or being challenged. Oftentimes, they will leave a job because they’ve stagnated by doing the same thing over-and-over again. It’s part of the reason that they may be suggesting changing the company’s tech stack. They enjoy working on new things! They like tinkering to master something, or they want something exciting to work on. It’s why, if an engineer is stuck on maintenance work, they quickly become unhappy.

This can creep up on companies, especially as the company grows larger. At the start, developers are working on green-field development: building new products, learning new frameworks, implementing new features. They’re happy. But eventually, the code gets released. The product starts requiring maintenance. Bugs must be rooted out and squashed. Technical debt begins reeling its ugly head. Coding is no longer as fun and they feel like their skills are stagnating.

Maintenance work is inevitable and it’s important to have a plan to eventually get engineers to greenfield development again. Give them a concrete timeline of approximately nine to fifteen months where they will transition onto more exciting projects. See if your company can pay for them to attend conferences, or reimburse them for books or Udemy courses. There’s always something your company can do to help them level up their skills. If developers are growing, they are less likely to jump to another company.

#4 Do they have a career path?

For a software developer, there are two career paths–management and technical. Management tends to be relatively straightforward. They start out as a developer, rise in seniority and experience, become a tech lead, maybe become a project manager, and eventually have teams of developers reporting to them.

From a company standpoint, building a technical career path for an employee is much, much harder. It requires organizational buy-in as you must provide developers commensurate pay raises and titles for their elite skills. It can feel strange paying an individual contributor more than some managers. But in software development, those extremely experienced technical resources can generate outsized returns for the business.

An important aspect of choosing an employee’s career path is making them part of the discussion. Find out what they are passionate about. Are they anxious to run their own team of people? Or do they want to be the company’s technical expert in a certain area? It’s all about letting them know that they are valuable and that they are in control of their career.

Conclusion

Developer turnover is an inevitable problem, but it can be minimized. Implement the four tips above–fairly compensate your employees, pick the right people for your company in the first place, keep your employees challenged, and help them choose a career path that will have them staying at your company for years to come.