Whenever you start looking at your ability to retain software developers, you should keep in mind that numbers might be considered high or low due to a variety of factors. Personally, I’ve seen companies in different industries perform a lot differently and whenever our HR leadership would report data on our retention, I would ask for market benchmarks for companies similar to ours.

In this article I will explain how to measure your software engineers retention and what’s considered good or bad depending on a few cases.

How to measure retention and turnover in your software development team

Measuring retention is pretty straightforward: consider the number of software developers that have left your organization in the last 12 months and calculate their percentage. If you have lost 5 developers in a population of 20 developers, your retention rate was 75% and your turnover 25% – both numbers are not particularly good.

Of course this is pretty simple math – you can redo it on a quarterly basis as well. What you need to consider though is why people left the organization. In most cases you can simplify it with voluntary and involuntary termination. You should consider only voluntary terminations in this value: they are the ones that decided to leave your company and were not laid off or fired due to other reasons.

When I was running our company I would put a lot of attention to our turnover in the product and engineering organization and always tried to test new ways to motivate our software engineers.

Given this, at the same time I was always more curious about two specific cohorts of people:

1. People that left within 2 years from joining the company: it was a suspicious signal of something not really clicking for them in our company. If you leave within the first 2 years you haven’t really moved the needle or learned a lot. It brings me to think there is something not good we probably did and we need to investigate.
2. People that left after 4 years from joining the company: in this case you are likely losing a rockstar or at lest someone that will definitely be missed and impact your roadmap. I have seen some of these cases and while some of them were simply “tired” of working on the same product or company, a few ones were quitting because of bad actions on our side. A bad VP of Engineering, a series of missteps on our leadership team etc. At some point I’ve hired a VP of Engineering that was hands-off, he did not care a lot about setting directions and did not coach his team. We quickly lost 2 key people after 3-4 months and that was a signal that things were not going well. We ended up letting this person go but the people we lost because of him meant that our product lost several months of development.

Needless to say if you are seeing a turnover rate of 25% in your engineering/product team you clearly have a big problem. More about what good and bad numbers look likr in this upcoming paragraph.

Benchmark: what’s a good retention number in the market?

LinkedIn says that engineering positions are among the most impacted by turnover with 11.5% turnover on a yearly basis – that’s quite a big number but it doesn’t really provide us any specific suggestions on titles/roles, we must assume that includes software engineers in the IT category.

While 11.5% is already a good indication of the industry benchmark, I find it more interesting to look at the overall tenure as a way to visualize the problem.

This is coming from a study conducted by Zippia (a US-based organization that has more than 7M jobs active in its platform) on more than 103,000 software engineers. Zippia says that 69% of developers stay less than two years in a company, which is probably a bit too big but close to reality.It’s really impossible to find the same data divided by industry and company size but after spending a lot of time looking at similar data, I think this is pretty accurate and what you should probably consider for your organization if you have more than 50 developers. In this case your turnover might need to be calculated using a 2-year period to better understand how you compare to the rest of the market.

Over the years, looking at our company and external ones (sometimes much bigger than Cloud Academy), I’ve seen healthy turnover for software engineers being between 5 and 7% per year, so assuming you have a team of 50 people, losing about 2-3 people per year. This is not too good (assuming it takes a few months to replace them) but that’s what you have to deal with. If you are losing more than that, let’s say more than 5 people per year, I think there is definitely something wrong that you should address.

Product companies vs consulting/service companies

There is always a big difference between the retention of software engineers in product-oriented and consulting companies. This is simply due to the nature of the business and the type of software engineers they attract. Product-focused organizations tend to attract software engineers looking for impact and to contribute to build a product, sometimes from scratch (not necessarily a startup, it can be a new product line inside a large organization as well). Consulting companies are usually attracting people that want to grow fast and are easily frustrated by working on the same project for too long. In my experience this cohort of software engineers is much more motivated by technical challenges than product-oriented roadmaps where you see your impact growing quarter over quarter with more customers adopting it.

The advice for consulting companies is to rotate your software developers as much as you can: most of them join your company to constantly learn new things and build new skills. When they get “stuck” for months and months on the same customer and project, the risk of losing them increases.

Needless to say this difference must be considered in the hiring process: it’s not easy for someone that spent his entire career in consulting to move to a product company and vice versa. I’ve seen a few people successfully going through this transition but I’ve also see several developers failing at this: they simply couldn’t adapt to a different way of working and they were ultimately quitting after a year or so.

Exit interview: read them often and be strategic about the changes

Exit interviews are the most precious source of knowledge if you want to fix your retention issues for software developers. If your HR team is not conducting them yet, ask them to implement a simple one today and have an HR representative conducting them every time someone leaves the organization. People tend to be very open in exit interviews and – if you structure questions well – they will tell you a lot about what your company could have done better and help you reduce turnover rate. Especially for CEOs and founders, exit interviews can be tough. You will find things that you couldn’t imagine would trigger people to quit but also things you suspected were happening and you could never really tell. That was for me reading that I simply hired the wrong VP of Engineering and even if all the signals were there, I simply took too long to fix my mistake.

For software engineers I think you should coach your HR team on asking specific questions related to your technology stack and internal dynamics with other departments: this will be the only way to discover that things were too slow for instance, or that changes were happening too often and not in a clear way. Some people will likely exaggerate in their exit interviews but most of them will report the exact reasons why they left and that will be enough to build your strategy.

Survey your software developers

In our organization we used to send out a complete survey to everyone in the company once a year. It was managed by HR and meant to let us understand what our people liked or disliked about our company. Looking back I think we could have done a better job simply having a dedicated survey for engineering and product – especially in tough periods where we got exposed to more turnover.

The problem with a yearly survey for the entire company is that it’s usually too long and you can’t really dive deeper into specific areas. A lot of people will complete it in a rush and don’t pay too much attention. Something you could solve with one that really talks about your software engineers.