What is the normal rate of turnover among developers and does it impact productivity?

Question

Not a techie, but know that techies are found here, so am asking here. I am a relatively new generalized HR/talent obtaining person at a bank where we keep having to hire more developers and I recently got moved to that project. We have about 25 developers total and are needing to source 35ish a year.

The hiring became a project because the group is plagued with project delays and because a senior manager yelled at the manager of the tech group for not being able to deliver projects on time. That triggered a complaint, and because the manager is a woman and the senior manager is a man, that yelling issue needs to be fixed. Manager wants more developers as everyone is new to the codebase.

To me, that rate of turnover is insane and I think something is wrong in the department itself. That's my instinct anyway. I can see it causing a lot of delays when onboarding developers and whatnot. But the dev friend I have in the team says that "we are lucky to keep them that long." He's been here just 6 months and asked about the process for references.

I'm in Toronto Canada for anyone asking.

Answer 1

What is the normal rate of turnover among developers

You turnover rate looks insane to me. It's more what I´d expect with callcenter-agents. If you really mean you need to source 35 employees to keep your steady 25 active developers level you'd have a fluctuation rate of 140%. Should be somewhere between 10 and 20%. (In 2017 in the IT sector I found an overall turnover rate of 16% for Germany and (2) 18% in the US in 2016)

and does it impact productivity?

Yes, it impacts productivity deeply. Just a quick-and-dirty ballpark estimate:

1. Your new developers have to learn the tech-stack, development process, business requirements etc. Let's say that takes them half of their time for the first 6 months (100%-0% in a linear degression). That's ~3 lost months right there.

2. Getting a working atmosphere, team dynamics and office setup right can impact a developers productivity greatly - some research (1) suggests by a factor of 10!

So if your average developer stays only around 8.5 months first learning and then getting demotivated quickly, your team of 25 has about the productivity of a happy and professional team of 2-3 developers!

---

Edit because of comments: Some jobs just have a higher natural turnover rate. Typically that is low wage, low qualification jobs. Those jobs are often taken on by people until they have something better, for example by students etc. That is not to say this is a good thing anywhere. Replacing an employee always costs you money and normally it hurts quality as well as productivity!

Any business that regards people as expendable will hurt itself!

If you talk to management about this, it sometimes helps to express this in monetary terms. Apart from recruitment costs, you also invest money into the professional development and learning of domain knowledge of each employee constantly over time. This is the company's human capital. Once the employee quits, you lose this investment. This about the same as not doing oil changes on your company fleet and instead have your vehicles break down and replace them every half year. You can easily lose millions this way!

---

Also, you don't want to get to zero fluctuation. A little influx of new ideas is a good thing and not all people will fit the team for all time. The dangerous thing is, with such a toxic work environment you are probably losing the good people and only keep those who can't find a better job or have found a way to keep getting paid while distancing themselves so far from the company that they take little interest in its goals (they have resigned on the inside). (3)

---

(1) As explained in the book "Peopleware" by Tom de Marco and Timothy Lister

(2) https://www.glassdoor.com/employers/blog/turnover-retention-rates/

(3) Blog article about loosing the talent, thanks to @Josh Johnson

Answer 2

[...] the group is plagued with project delays and because a senior manager yelled at the manager of the tech group for not being able to deliver projects on time and that triggered a complaint and because the manager is a woman and the senior manager is a man, that yelling issue needs to be fixed.

It's absolutely not a problem with turnover, or developers. It's a toxic environment and consequent wrong PM-ing issue!!. It must be fixed ASAP for the project to be salvageable.

Manager wants more developers as everyone is new to the codebase.

Brooks's law (thanks @Benjamin but I used a different link) proves that the best you can do to kill the project is hiring more staff, in the false belief that it will recover the delays you accumulated.

Every new hire is new to the code base, and everyone needs ramp up.

Let me add an iconic quote about what is happening in your company

If you get 9 women pregnant today, you will get 9 babies at the end of 9 months, not 1 baby after one month

In the project management's scope, adding new resources requires pausing an existing resource from activity (coding) in order to train new hires. This has the immediate effect to delay the project, which is the opposite of your manager's expectations.

A suffering project doesn't benefit from additional resources, especially in software industry: it will simply suffer the new hires. I'm not going to be intentionally rude, but sounds like your management comes from the world of agriculture and farming, where you can hire a new harvester overnight.

In the end, your turnover is insane because the project has management issues. I am unable to go into the details of the remediation strategy, but surely renegotiating the deadlines would be my first choice. And in the end, at this point the project is so critical that it must be salvaged or killed.

It is my experience that some projects, for political or marketing reasons, cannot just afford a delay.

Answer 3

If you are losing them at 8 months, they are deciding to leave at 6.

I assume that most people quit to other jobs. It usually takes some time to find another one searching part-time and assuming they are somewhat selective. Let's say a month assuming they are a good developer. Add on another month to collect a paycheque while waiting for the new job to start. That makes the decision to leave at 6 months.

Your devs are basically giving it the probation period and deciding to go elsewhere afterward.

But the dev friend I have in the team says that "we are lucky to keep them that long."

He is commenting on your company, not the developer market in general. I bet he is on the job hunt himself.

As for whether high developer churn harms the project, I have been working solely on one system for the past 8 months. The other developer on the project has been here a year. The project is 4 years old. I would estimate that 1/4 of work I have done has been duplicate in one way or another as we did not know the functionality had already been built. Problematic enough for you?

Answer 4

It's clear when you ask the question that you know you have a turnover problem. That's not new information. A lot of answers have been geared towards the impacts and describing the cost that this kind of turnover incurs. That's all really great information, and none of it helps you fix it.

Great, your problem has a huge impact and you need to fix it. What is your problem, though? Turnover is a symptom it's not the problem.

You have a culture problem.

You have people who neither trust nor respect each other, and they're clearly not encouraged to do either. While the stats show turnover for the organization, how many people do you have who have been there 5+ years? These may be some of your problem areas. What are your development plans? How are your middle managers leveling up your individual contributors? What is their path to empathy for their peers?

1. You need to eliminate hostile or toxic behavior immediately.
2. Identify your most senior people. Are they trustworthy? Are they respectful? How do they lift the people around them? If you can't answer these questions with positives, then this is your first solution point. They need to be leveled up in soft skills, leadership and empathy. If they won't, they need to be replaced.
3. Listen to the pain points. Your individual contributors will have a LOT of complaints. Tie them together into common process points, and use that to identify the process improvements that will alleviate that pain.
4. Separate the people from the problem. Describe the problem to someone who has no idea what you're talking about. Use no names; use only roles. If you can't separate the person from the problem, the person is the problem.

Great, you've started fixing the process - What about the people?

People in general want to feel needed and valued. They want their work to matter to someone else. They want to become better at what they do, and they want to be able to do more. They accomplish this through their managers and supervisors.

1. What do your training programs look like?
2. What incentives for advancement are available?
3. How are successful actions rewarded?
4. How are individuals held accountable for misteps?
5. How does their work get promoted to a place of value?

You need to be able to answer these questions very cogently. If you can't, then your people are leaving because the company doesn't value them the way they want to be valued.

What about the toxic/angry folks?

A lot of people will tell you they need to be fired. Many people are ready to give up on them. Someone who gets angry or frustrated is someone who is showing you how much they care. They might not care about the right things at the moment, but they are invested in what they do and who they are in their position. I encourage you not to give up on these people. I've invested in my toxic individuals in the past, and it's paid off in huge dividends. These people have become some of my highest performers.

1. You need to listen to them. Hear their problems. Help them get past them. This takes time. It takes encouragement.
2. Connect them to their peers. Educate them on how their behavior is impacting the people around them. Expect better from them. Tell them that's not acceptable and that you need their help.
3. Find their value points, and help them achieve them. If it's getting work in front of a customer, do what you can to help them do that. If it's interacting with other areas of the organization, find opportunities to make it happen.
4. Identify their toxic behavior and address it right away when it happens. You don't have to hammer people. Just make it clear you're watching and expect better.

Wow, there's a lot to do here. Am I the problem?

You just might be. It's possible that they don't trust the company or leadership. If you're in management, it's critical to identify this. So many times this comes as a result of the leadership messages not matching the leadership actions. Often it's just the perception of disrespect that comes with the separation in information.

1. Be as honest and transparent as you can with your folks.
2. Leadership needs to maintain a cohesive and consolidated message.
3. Management needs to respect their individual contributions and do what it takes to lift them.

Servant leadership has always worked for me. If your individual contributors believe that management's work is done for the benefit of them, they will lift mountains. It takes honesty. It takes belief. If people are expected to behave to a higher standard, their leaders must exemplify that standard. If you want your individual contributors to be respectful and empathetic, then you must be respectful and empathetic. If you want them to work hard, you must work hard. You will cultivate the culture you deserve, not the culture that you want.

Until the culture is fixed, people will continue to leave and the turnover will continue to be at epic levels.

Answer 5

You need 35 people a year to keep 25 positions filled.

Even with the most boring, unfulfilling job imaginable, you should eventually end up with a bunch of people who don't care about that and who are happy to arrive in the morning, leave in the evening, and take their money at the end of the month.

You didn't. That means your jobs don't just not attract people, there is something actively driving people away. Two bosses sexually harrassing everyone without exception? Actual violence in the workplace? A nasty smell in the office that makes me think of dead people under the floorboards? There must be something like that. 140% attrition rate is just not normal.

Does it impact productivity? What productivity? I wouldn't expect there to be any productivity there at all. You have newcomers who have to learn the environment first - and there is nobody experienced who can teach them. No productivity from the new people and reduced productivity from the not-quite-so-new ones for four months. Then when they are just about ready to do some work, the previous generation leaves and the next bunch needs to be taught. Once that is done they've had enough and leave. No work is done.

You have some hard work ahead of you. I'd say you need eight to ten true professionals with good salaries who power through, no matter what. They need to be given free hand to fight back against any obstacles (for example if the CEO shouts at them, to physically remove him or her without fear of repercussions). With free hand to make development decisions (in case you have idiotic management that can't keep goals unchanged for a week).

Answer 6

While there's no perfect answer to the question "What is a normal turnover with developers ?" (it will vary from company to company and everyone is different), I would say that most of the time devs will try to stay at least 2 or 3 years in the same company if they can.

It looks good on the resume, you have the time to learn the subject and build a good relationship with people. After 2 or 3 years, you can change job to have a nice increase in salary and go work on new projects with newer techs.

If a developer doesn't stay more than a year, it means that something didn't sit well with him. Leaving so soon may hurt his career :

• he will have to justify staying for such a short time in future interviews.
• it will be hard to use these few months of experience in any salary negotiation. Career wise, it's lost time.

So I'd say that any company that have a turnover of less than a year is doing things really, really wrong. But then the answers of Daniel and usr-local-ΕΨΗΕΛΩΝ give better explanations on that subject.

Answer 7

If you need to hire 35 devs a year to fill 25 positions, your average dev stays for 8.6 months. That is, indeed, insanely short.

Turnover rates like this can have a huge impact on productivity. There are several factors contributing to this:

• Depending on project complexity and his experience, a dev needs something between a few weeks and a few months until he reaches his peak performance, because he has to get used to the existing codebase, his co-devs style of programming, company standards, external components and stuff as such. To have some easier math, lets assume onboarding takes 2 months and a dev stays for 8 months. In 2 years, thats 6 months of onboarding. You would've saved 4 months worth of onboarding if he stayed 2 years.
• The rest of the team needs to get used to the new dev as well. This includes everything you need to know for project management reasons: How fast is he? How competent is he? Does he communicate well? Does he have special needs? Without all this information, you project management will be based on shaky assumptions.
• High turnover amplifies some typical software development problems, like poor processes or poor documentation. If everyone knows what is expected of him and is familiar with the codebase anyways these points are still important, but you can compromise on them. If you do that in a high turnover environment, each of the many new devs will waste many, many hours of his (and others!) time, trying to figure out how everything works and what exactly he has to do.
• Knowledge gets lost and so has to be reacquired. "Oh, you need to know how to integrate X and Y? Well, Dave did this 2 years ago, he dug through the specs for a month. He left, and so did everybody he ever talked to about this. Guess you have to redo it. Here you can find the specs ...".
• It's much harder to find processes that work for your team, because your team is a very volatile thing.

The other part of your question, namely "What is the normal rate of turnover among developers", is much harder to answer. So I'll do a kind of framechallenge: Don't ask what a normal rate is, ask what your want your rate to be and how to achieve it. Your company is different from every other company, so you answer might differ from the norm. There are even some rare circumstances where a high turnover isn't a problem at all.

Answer 8

Notice! It is mainly opinion based. May be subject to 'anecdotal evidence' bias based on my own experiences and my acquaintances. More objective assumptions are at the 'summary' section.

I would like to post an answer from totally opposite point of view.

You mentioned that it is a bank or other financial institution. It is quite normal that they may have a toxic work environment and may have large turnover. What they offer in exchange is a little bit higher salary. I don't know why. Maybe some banksters still have a corrupted mindset that they can get everything through money, or simply banking business is such profitable.

I will tell a little of my own story. I have been working in banking industry for a short time (only 4 months). It was short after studies because they recruited students through some kind of career market organised at my university.

I can tell, that salary was quite impressive but it did not offer a position where I could develop my skills as I wanted and the environment was a little bit toxic. It made me to change my plans. I decided to find a job for lower salary but greater opportunities for learning new programming tools/technologies and for friendly working environment.

But some of my friends stood still at that company and they liked it. They enjoyed the salary and they simply got used to stressful workplace.

I also met some people who changed jobs from my present to my past company and they enjoy it more. It is unbelievable but everyone has his own personal preferences which is hard to argue with.

Summary

To sum up, high turnover may not be a bad thing under certain conditions:

• They recruit huge load of young workers, mainly fresh graduates.
• They have got an efficient onboarding process and tutorials up to date and ready to use. Usually workers who have been working for medium to short time and are fresh train just recruited younger colleagues. Veterans stay focused on their own important tasks. They are bothered only when necessary.
• Most of workers who have left the company are people who have been working there less than 1 year.
• People who fit into specific working environment stay there for years.
• People who gained specific and important domain/business knowledge usually remain at the company. They are usually motivated by higher raise/promotion.

Answer 9

Consider that you have a mismatch between what you are asking people to do and how you hire and do things. Technology is not as a rule a soft science. If you ask the impossible people will quit. So making sure:

1. That the expectations placed on your developers is realistic.
2. That your workers have enough time execute on those tasks.

What people unaccustomed to tech work do not understand is that: Nothing can actually exactly prepare you for the job at hand. Except doing that job. Now, it is very hard to gauge how much time you would need to become productive. But it is also hard to do a task that is infinitely big from your standpoint.

So it is very important that you actually have some senior developer who's job is to split tasks into manageable chunks. And it really sounds like you have lost all your coordination talent, so there is nobody bringing the new people up to speed.

The solution is probably not increasing number of people, but decreasing it. You can not just pump in new developers at infinite pace. They will just make it impossible for those few who could work effectively to work effectively.

Another can be being constantly overwhelmed by changing scope. Workers need to know they are getting something done. So they need to be able to take a chunk of work and do that chunk of work. Having done the chunk needs to be acknowledged.

Just because the chunk is now considered obsolete is not the workers fault. Its the leaderships fault. The worker has achieved the chunk that they set out to do and that should be correct. For example: Its not the painters fault if the office wall is green when you asked him to paint green. Though you may have after he started painting decided that it should be pink. Painter can only execute on things that have been agreed to. Even so you can only pull the rug under person so many times.

People can leave simply because your process is not working.

Answer 10

I've worked in a range of companies, in several countries; in my experience, developers typically expect to stay in a role for 2-3 years; they then seek promotion, or leave. In most companies where I've worked, this seemed to lead to an annual turnover rate of around 20%; we could reduce that by increasing financial rewards, improving career development options, and finding cool projects for people to work on.

The exceptions were companies with a culture problem - as other answers have hinted, you have a culture problem.

You also have a vicious circle problem.

Senior management have high, possibly unrealistic expectations.
They put pressure on middle management to deliver against those expectations.
Middle management tries what they can; adding more developers (thus bumping into Brooks' law), and then shouting.
Shouting leads to reduced morale among the team.
Reduced morale reduces productivity - unhappy people don't work as hard.
Reduced morale causes people to leave, which also reduces productivity.
Growing the team leads to a reduction in productivity through recruitment efforts, and Brooks' law.
Reduced productivity further increases the gap between expectations and output.

Rinse and repeat...

Breaking this cycle is incredibly hard. This kind of environment creates incentives for people to invest in politics, rather than delivery - the survival strategy becomes "don't get blamed for bad outcomes", rather than "work to create good outcomes".

It's not enough to stop the shouting (necessary, but not sufficient) - the team will continue to respond to the incentives, and leave if they don't like the environment. Developers in Toronto have lots of options.

The first step is to get buy-in from senior management that you have a problem, and that continuing to do what you're doing will not cause the project to magically fix itself. Culture problems and vicious circles usually need senior management to drive the change - more often than not, they define the culture, and they have the levers to pull that can break through the vicious circle.

The best way I know of breaking the vicious circle is to find a way of re-setting expectations, and getting the developers an achievable goal. I inherited a situation like this once, and we agreed that rather than worrying about the full 18-month project scope, we'd pick a 3-month time horizon, and agree what we could do in that time frame. We negotiated a "must/should/won't" set of deliverables between management and the developers, and agreed ways to resolve problems the developers had raised ("the requirements aren't good enough", "we never get useful feedback", "the office is too noisy") etc. We used this 3-month mini project to re-set the culture and rebuild a bit of trust.