Five Reasons Why Software Engineers Quit and How Managers Can Retain Them for Longer

Strategies to keep your dream team working together for ages

Photo by Dustin Tramel on Unsplash

When an experienced software engineer quits, replacing them is an expensive exercise in terms of costs and impact on productivity.

First, it takes a few months to find a comparable replacement in the competitive market. Then it’s another month before the new hire starts in their role. Only three to six months later, they eventually get up to speed. In total, that’s six to nine months of reduced productivity.

Secondly, the new hire’s salary is usually higher than the salary of the person they replace. The team has to spend time interviewing the candidates and onboarding the new hire, further impacting the team productivity. If a recruitment agency is involved, the replacement costs grow higher.

If a company reduces the churn rate, it saves money and maintains productivity. Even though it is impossible to keep the entire team forever, management still can do a lot to retain its key staff. So, let’s look at some common reasons (the ones I’ve heard of most) why developers quit and discuss what managers can do about them.

The talent market is competitive, and many software engineers would take advantage of that and join another company to get a 15–20% salary increase.

To control the risk of their staff leaving due to being (or feeling) underpaid, engineering managers need to review the salaries of their people a few times a year, not just annually.

Suppose a review shows their team member’s salary is significantly lower than what the candidate manager or other companies would offer to a similarly experienced today. In that case, the manager should consider a pay increase for that person that would make changing the job for that person not worth their effort. Not many developers will change their job if all they get is a 5% pay increase.

Management should review salaries proactively because it is easy for most underpaid developers to find a new job quickly. Moreover, some people find asking for a pay rise awkward, and they would rather look for another opportunity instead of discussing their pay with their boss.

Furthermore, management can make promotions and pay increases semi-automatic for junior roles. Good junior and mid-level developers get sizeable pay increases if they change jobs often. So if they get a reasonable pay rise at their current job, they would have fewer reasons to go elsewhere.

Alternatively, a company can offer equity to engineers instead of a pay rise. A positive effect of this measure is that it changes the employees’ attitude towards the company as they become co-owners of the business, even though that is only a tiny part of it.

Many ambitious engineers quit when they realise they can’t further their career in the company and have to stay in the same role for many years.

Introducing a transparent career progression policy and running regular promotion cycles can reduce this risk.

The career progression policy for the Individual Contributor track is not that hard to define for the entire engineering team. It needs to clarify the expectations for each level and the criteria for promotions, with each promotion typically requiring 18 months to three years to earn.

A good career progression policy guides developers and their managers on how to prepare and implement a development plan.

When most developers know they are not far from earning the next title, they are less likely to apply for that role elsewhere.

It’s best if managers are proactive in mitigating this risk and talk to their team members about their career development. Some developers are not comfortable raising this topic with their managers or are unaware of available opportunities, so they look for them elsewhere.

Most prefer to work with modern technology, tools and architectures rather than engineers maintaining legacy systems. New tech is exciting, and a chance to use it is a way to keep skills up to date and remain relevant in the job market.

Engineering managers should ensure that the team is:

  • Continuous migrating to the current versions of current languages, libraries and frameworks,
  • refactoring and rearchitecting the systems to make them more maintainable and to reduce tech debt,
  • identifying and adopting emerging tools and practices to increase its output.

Engineering managers have to be proactive here too, and clarify to the team that continuous improvements in their systems and the way the team works are encouraged and appreciated. One way to do this is to allocate time each week or sprint for such work.

Software engineers thrive in an environment where they continuously solve exciting, challenging, and meaningful problems. Most assigned to work on tedious tasks get bored after a few weeks, and if this continues for several months, they may lose interest in their job and quit.

Engineering managers should ensure their team members work on varied tasks to manage this risk. Sometimes this requires moving people between projects or teams to create variety and give a person a new challenge to reignite their interest in the job.

Another option is to delegate some of the manager’s responsibilities to the team members to help them grow further and demonstrate that their manager trusts them.

In addition, managers need to keep an eye on what tasks their engineers pick up to ensure that everyone gets a fair chance to work on something exciting and that tedious work is spread out between all team members more or less equally. That should prevent some engineers from taking advantage of their role in a team and hoarding the most exciting tasks leaving the boring ones to their colleagues.

Another thing managers can do to make their team members’ work varied to support them in contributing to the team and the organization in more ways than just building software. For example:

  • Experienced can be encouraged to mentor juniors, run internal training and engineers workshops;
  • some may have the right skills to help with interviewing job candidates for the engineering team;
  • some may do a secondment in a non-tech role and closely work with Product, Design, Analytics, Customer Support, etc.

In addition, managers need to regularly check in with each team member and discuss how they feel about the current work, what they would like to work on next, and what they would like to work on in the long term.

Few engineers bring these topics up with their managers themselves. The best ones often feel that they should be taking on the tedious tasks for the team’s benefit, giving others a chance to work on something fun. Too much of that may lead to burnout and lower job satisfaction, so the managers need to monitor this situation.

I think engineers quit because of poor cultural or organizational fit either during their first six to nine months in the role or after several years with the company when it changes too much and no longer is the place where they feel they belong.

To reduce the risk that a new hire would leave, the hiring manager needs to clarify to that person at the interview stage what the organizational environment is like and how the team operates. Furthermore, the manager needs to find out what environment the candidate considers best for them, their preferred way of working and what types of companies the person has worked for.

Being transparent at the interview stage should set the right expectations for both sides, identify potential difficulties the person may have when joining the team, and lower the chance of making a hiring.

As for the other case, to a certain degree, managers can help engineers feel that they still belong in the organization even if it has changed over the years. For instance, managers can ensure that their people are supported and the team and stakeholders hear their concerns and appreciate their contribution.

One crucial point is that, despite all the changes in the company, engineers should feel that they can succeed in the current environment and keep growing and delivering excellent results.

To sum up, here is how managers can retain their team members:

  • Review each team member’s salary at least once a year to ensure they are not paid below market.
  • Introduce a transparent process for promotions on the Individual Contributor track.
  • Support adoption of newer and better technologies and tools and allocate time to maintain existing systems and fix tech debt.
  • Assign varied tasks and projects to people, consider moving them to other teams if necessary, and ensure no one keeps working on similar tasks for too long unless they choose to.
  • Delegate more to the team members and empower them to decide how to do their work.
  • Find ways for software engineers to contribute to the business beyond writing code. For example, include them in design, product and support meetings.
  • Help each team member realise that they can succeed in their current role and keep growing and producing great outcomes.

Leave a Comment