last day (15 days later) » 

01:53
34
Q: What is the normal rate of turnover among developers and does it impact productivity?

MapleLeafsFanNot 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 ...

@JoeStrazzere 35/25= 140% meaning 140% of your staff has to be replaced during a 12 month period or an average working duration of 8.57 month
"because the manager is a woman and the senior manager is a man, that yelling issue needs to be fixed." shouldn't this be fixed no matter which genders are involved?
I think it would be worth it to investigate why the turnover is so high. Lack of tools due to penny pinching, poor management, improper use of project management methodologies, impossible goals, and poor quality legacy code could all contribute.
@JoeStrazzere could be, I don´t think its entirely clear formulated. Hence I put the "If you really mean " in my answer. Strange use of the word turnover for a HR person, if they don´t meant that. Maybe OP can clarify?
@JoeStrazzere anyways it´s sad. While the market is starving for good good developers there are company's out there that unnecessarily burn trough dozens of them at a time while keeping everyone involved unhappy ...
@MatthewGaiser probably yes, but legal considers it less of a problem so...
@JoeStrazzere Yeah, we should have about 25 developers on a team which has been around for a while. In the past year we have hired 35.
@JoeStrazzere I would have thought that it would be impacting productivity, but since nobody has done anything about it I wasnt sure I was right. My grandfather was a factory worker at a mill and he talked about being an interchangable widget. Maybe software dev is the same? idk.
We also have high turnover like that in our call centres and nobody has an issue there either.
01:53
Management likes to think that developers are all the same, but as a developer who has to work on a lot of other people's code, I can tell you this is not the case. (Actually it's not true for anyone, not even factory workers, if you look at old motion studies, etc., you can see that the most efficient factory workers are MUCH more efficient than the average. What may be true with repetitive tasks is that there is a "good enough" point. Software development really shouldn't be repetitive, though, so better makes a big difference.)
Software developers are definitely not interchangeable with each other in a general sense.
What do your exit interviews provide as far as reasons for your developers leaving?
@selectstriker2 Exit interviews are a very unreliable source of information. The recommendation what reasons to state why you are leaving are always something generic like "personal / professional development goals doesn't fit the current employment anymore" as not to burn bridges. You cant expect the people who already left to help you fix your problems. Better to concentrate on those who still are there and ask them what needs to change.
@MapleLeafsFan - what is your actual HR role? Are you an HR rep? An internal recruiter? An independent recruiter? Something else? These seem like questions you should be discussing with your manager and/or HR peers. Seems like it would be hard to hire the right kind of people without knowing what's actually going on within the project/department.
@Daniel That might be true for a couple of developers, but I suspect that if a ton of developers are leaving after only 6 - 12 months they are likely frustrated and not worried about burning bridges with this company. I agree that talking to the current developers is another thing that must be done.
Do you have at least few older dev? More than 2-3 years? Maybe they have information on what is the issue?
01:53
@DragandDrop: My guess is that anyone who stays longer than a year or two in this environment has given up and become part of the problem ...
I don't think that the dev-friend comment, "we are lucky to keep them that long" is contradicting that this is an insane situation. They're likely saying that the business is even worse than you can perceive as a non-developer.
I’m voting to close this question because any answer to this would be way too localized. Normal for this will change with the specific combination of location, condition of the economy, industry, start up/establish company, and technology stack. Retention rates are impacted by way too complex a set of factors for strangers on the internet to tell you what "normal" should be.
Kat
Kat
@Myles I disagree, having to replace your entire department and then some every year is a ridiculous amount of turnover, and it will absolutely affect productivity in any position that requires some time to get up to speed.
@Myles I also disagree. While every company is different and some may have a higher turnover rate than others, if you have a much larger than average turnover rate and you don´t know why / that is not your specific goal for whatever reason, you have a problem and its helpful to discuss this.
25 developer slots, 35 new bodies per year. That's 140% turnover per annum, which is absolutely nuts. I'd say that your intuition regarding the state of this department is absolutely correct. Perhaps going back in history and determining when this state of affairs began might lead to insights into the problem - and in my mind, at least, this is a HUGE problem for your company. No group can work effectively when there's no continuity.
01:53
@Kat Fully agree that it is a problem and it is an interesting one, however the workplace is a Q&A site with specific parameters not a discussion forum. The question as asked "What is the normal rate..." does not fall within these parameters. Also please note that most answers below are not actually answering the specific question that was asked.
Just on that call center point - I’ve worked with call centers before that have done serious analysis on performance of staff. I’ve seen it described as taking 6 months before staff are fully onboarded (and this causing minimal callback/costs to business with incorrect answers). High turnover there can be exceptionally costly for businesses, so you might want to look into that too - but it may be a harder problem to fix than the developers.
Something is bad in this department. Yelling is a symthom. But with this turnover the code should be a mess and delays or quality iossues are not a surprise no matter what you do. Ask them. Some would be shy, some may vent. You may end looking for a new manager which is easier that looking for 35 developers. And please change the toxic environment.
Thinking of @MatthewGaiser's answer: When was the last time this team ever produced a deliverable? In general terms, what was it? Did it work?

last day (15 days later) »