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.

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – DarkCygnus
    Commented Apr 17, 2020 at 1:53
  • I wanted to edit this, the title in particular, since it doesn't really match the answers below, but I'm not sure what you actually want to achieve here. Is it simply to confirm whether this rate of turnover is insane? Or do you also want to figure out how to find the root cause / address the problem?
    – Lilienthal
    Commented Apr 17, 2020 at 10:10
  • 3
    Does your management know its not there to force people to keep deadlines, but to do everything in their power to help the people work optimally to match the deadline? I think the issue is that your manager thinks he can just sit and wait while you drown in problem instead of actually doing the management to help you. The problem does not lie on the developer side.
    – Chapz
    Commented Apr 17, 2020 at 10:35
  • 1
    Exit interviews. What are they saying? That's going to give you the answers you need.
    – ndm13
    Commented Apr 17, 2020 at 14:16
  • 1
    @Lilienthal That was the reasoning for my close vote. The question as asked in the title is too specific to provide a proper Q&A response and has collected a bunch of interesting answers to adjacent questions without addressing the one that was asked.
    – Myles
    Commented Apr 17, 2020 at 16:31

10 Answers 10


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

  • 70
    You can probably reduce that further because a team of 2-3 developers can communicate more effectively than 25.
    – Nathan
    Commented Apr 16, 2020 at 7:25
  • 6
    +1 for learning requirements etc. And a great opportunity to mention yet another book: The Mythical Man Month. You won't ever be able to know how many developers take how long to develop [put in any software] when constantly throwing new developers onto the task. Just think about what the documentation should look like, when trying to succeed with such a high turnover!
    – Jessica
    Commented Apr 16, 2020 at 9:06
  • 4
    @Alexander Your link is very interesting but it talks about "normal" old code, tested and working for some time. And a rule of thumb means it is most often true, not always. The cost of refactoring must be compared to the cost of not being able to keep any developer for more than a few months. I know I wouldn't touch OP's code base with a stick even for double my salary.
    – Jemox
    Commented Apr 16, 2020 at 11:34
  • 19
    @MapleLeafsFan: Is that what you got from my answer? Sorry, I´m a little bit shocked here! nobody should be thought of as being interchanged easily. At least not if you want a healthy business. Worked here in Germany for a call center for some time and actually did a statistical analysis. Replacing an agent cost us ~10.000€ so getting fluctuation down was a real money saving goal. Replacing a programmer surely costs you between 50,000 and 300,000 depending on salary, proficiency and time in the company. So apart from hurting productive, its real damn expensive!
    – Daniel
    Commented Apr 16, 2020 at 12:59
  • 9
    @MapleLeafsFan No. No, they should not. This is, sadly, apparently a common attitude among some managers, and is itself a leading indicator of other toxic attitudes and practices in the workplace. Commented Apr 16, 2020 at 13:57

[...] 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.

  • 7
    also known as en.wikipedia.org/wiki/Brooks%27s_law -> adding manpower to a late software project makes it later
    – Benjamin
    Commented Apr 16, 2020 at 7:25
  • 3
    The farming example does not fit. In the Corona crisis, German farmers are lacking trained harvesters from eastern Europe. Training German students or unemployed people who possibly leave after some month (due to the hard work) takes a lot of time for the farmers. Therefore, some farmers don't want to employ German untrained harvesters. At least in the area of asparagus and strawberries this is the case. I don't know if apple harvesting is similarly affected ... . Anyway: farming is bad example ;-) Commented Apr 16, 2020 at 14:45
  • 14
    @daniel.neumann: I think I would defend the farming comparison. Assume trained harvesters, not completely untrained ones. Someone who can pick asparagus at one farm can be productive within the day at another. But even expert, trained programmers will have a ~6 month ramp-up time to be productive at a different software shop. Commented Apr 16, 2020 at 15:10
  • That's a good answer. Unfortunately the fallacy of thinking that adding additional people means speeding up a delayed project is incredibly common in IT but also other functional areas/ industries.
    – BigMadAndy
    Commented Apr 17, 2020 at 8:28
  • 1
    “Get 9 women pregnant today” — believe me, I'm trying. It's more difficult than it sounds! Commented Apr 17, 2020 at 13:50

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?

  • 10
    "I bet he is on the job hunt himself". No need to bet, the question says "He's been here just 6 months and asked about the process for references."
    – Ben Voigt
    Commented Apr 16, 2020 at 18:39
  • 1
    Such a great point. If one estimates ~6 month normal ramp-up time to productivity, this leads to the possibility that absolutely no one has done any productive work in recent memory. I wonder: Has this team ever produced any deliverable? Commented Apr 16, 2020 at 21:27
  • @BenVoigt I completely failed to read the next line there. Yeah, he is already on his way out... Commented Apr 16, 2020 at 21:50
  • @DanielR.Collins my friends at banks were rushed to push code quickly, so I suspect that the answer is yes, but... They haven't given me many details about code, but another friend is a junior at a company and they have a webpage which makes 160 API calls to load as nobody bothered to consolidate anything. So I suspect they just ship whatever. Commented Apr 16, 2020 at 22:43

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.

  • 7
    If I didn't already work with an awesome team, I'd work for you in a heartbeat.
    – psaxton
    Commented Apr 17, 2020 at 2:01
  • @psaxton - Thanks, I appreciate that. Commented Apr 17, 2020 at 14:23
  • I think I have a very different understanding of toxic people. In my eyes there is a huge difference between people who are angry/complaining/critisising/... and people who are actually toxic for the environment. Working with complainers can actually get you their loyalty and help you improve as an organisation (or an individual) in a major way. Actually toxic people, however, (and there are few) simply need to be removed.
    – fgysin
    Commented Apr 20, 2020 at 9:44
  • 2
    @fgysinreinstateMonica: If you can't rehabilitate a toxic person or are unwilling to invest the effort it takes, then - Yes, that's absolutely correct. If you have the luxury of time and a little patience, a toxic person can be rehabilitated, and many times that person can be returned to a significant value source. There is also the value assessment of deciding if the value at the end is worth the investment itself. Is the attempt to rehab worth more or less than finding a replacement? Speaking frankly, there are some individuals for whom that investment will not pay off. Commented Apr 20, 2020 at 14:41

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

  • 4
    35 people for 25 spots doesn't mean they're replacing EVERYONE. They could easily have a poisonous employee(s) are are left with seriously bad management. Commented Apr 16, 2020 at 16:08
  • 3
    @DarkMatter: If they don't replace everyone every 8 months, they're replacing half the team every 4 months. That hardly makes it better.
    – MSalters
    Commented Apr 17, 2020 at 14:57
  • 1
    I expect they have a core of 6-12 toxic employees, a dysfunctional management, and it takes new people 2-3 weeks to realize just how bad this is and a few months to find new employment. So yeah, "better" isn't the right word, but that is probably what it is. Commented Apr 17, 2020 at 18:24

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.

  • There are statistics for average turnover in a certain field. That could be viewed as about "normal"
    – Daniel
    Commented Apr 16, 2020 at 14:54
  • It will depend on the field, the company size, the experience of recruits, the country... Maybe someone will find the statistics of the turnover of junior devs in banks in Toronto (which is precisely OP's situation) but I feel like my answer is giving a good enough average.
    – Jemox
    Commented Apr 16, 2020 at 16:54
  • If industry average is at about lets say 15% and you have about 20% you can say it´s higher than normal - maybe explained by the regional or demographic difference or more likely by the company culture. Also where did you get that OP is hiring only junior devs?
    – Daniel
    Commented Apr 16, 2020 at 17:06
  • Chiming in as a Dev myself.. I regard a 2 year stint in a company as a minimum. The only times I've left earlier than that were when the company couldn't support me (one closed down, the other ran out of work for me to do), the only other reasons I would leave before that is if it were a truly hostile or toxic working environment, or if something came up in my personal life. Commented Apr 16, 2020 at 17:08
  • @Daniel It's not written but I made a guess on the fact that experienced people have an easier time spotting toxic companies and avoiding them. Also, I feel like we spent far too much words on the one sentence introduction to my answer. Do you disagree with the 2 or 3 years estimate ? Do you want to add something ?
    – Jemox
    Commented Apr 16, 2020 at 17:36

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.


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.


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.
  • 6
    Uh... so you're just out into the workforce, and have experience with one particular bank - and you're willing to pronounce judgement not only on banking jobs in general, but that the people taking those jobs must be motivated by greed. Geez. My wife works at a bank, and it's about the most laid-back atmosphere around. I have friends working programming in banks, and they say it's a pretty 'bleh/boring' culture.
    – Kevin
    Commented Apr 16, 2020 at 21:40
  • 2
    I agree with @Kevin in that Fintech organizations vary wildly in their environments and cultures. Some are extremely laid back and really great places to work. Others are shark tanks. Commented Apr 17, 2020 at 1:27
  • 1
    Buah, I have worked in several industries and definitely wouldn't describe banking as the worst one. It's also hard to generalize things like culture. I once worked in the same company in two countries and the culture was very different (I know the two countries well enough to know the differences in company cultures weren't based on the cultural differences between the countries).
    – BigMadAndy
    Commented Apr 17, 2020 at 9:05

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .