5 reasons why your software engineers are quitting their jobs

Many software companies are aware that they have to attract top engineering talent to compete in the market.

However, employing software engineers is just the initial step. Keeping them engaged so they don’t feel compelled to leave your company is arguably an even more challenging task.

In this article, we’ll dive into five reasons why your engineers may quit their jobs. The old cliche states that knowledge is power; knowing these common pitfalls can help you keep engineers in your company.

Boring projects

If your software engineers are quitting their jobs after a certain amount of time, it could be that they’re just—bored.

Although it can sound oversimplified, boredom can be a major reason developers leave their jobs. Developers want to be challenged, inspired, work on exciting projects that provide them with opportunities to learn and grow.

A survey by Stack Overflow, which got nearly 23.000 responses, showed just that. On a scale from one to five, where one is “not important at all”, and five is “very important”, developers assessed the importance of various factors in their potential job.

As you can see, respondents rated opportunities for professional development as the most important. Considering that the engineering field is constantly changing, the desire to learn isn’t that surprising.

One of the engineers who had first-hand experience with the perils of work-related boredom is Bruno Marnette, vice-president at Two Sigma. He described how he worked the whole year on the same project.

Although he admits that he learned a lot, he found the work too monotonous, so he left his job.

When he later founded Enki, he organized the work so that no one was on the same project longer than three months. That prevented repetitiveness and boredom during longer projects.

Some companies know that their developers could leave if they feel too constrained at their job, so they employ different strategies to counteract that. For example, Atlassian, a company that created Jira and acquired Trello in 2017, has ShipIt Days.

Atlassian developers get 24 hours to use their imagination and creativity and work on whatever they want. The emphasis isn’t on whether their project will become a usable product for consumers but on breaking the boredom of everyday tasks and having fun at the workplace.

You can get a sense of the positive atmosphere ShipIt creates in the video below:

With practice like that, Atlassian gives their engineers a chance to work on their passion projects and present them to colleagues, with no pressure to deliver results.

You can apply the same philosophy to your business; by giving your engineers a chance to be creative and work on different projects, they are less likely to quit because of boredom.

Also, as we mentioned earlier, a good strategy to combat boredom among your employees is giving them opportunities to learn new skills. For example, developers at Netlify built a learning platform called Jamstack Explorers.

In addition to being a learning resource for developers outside of their company, it was an opportunity for their team to learn and practice Next.js, Sanity.io, Cloudinary, and serverless functions, as their developer Sarah Drasner described.

Netlifys’ developers were challenged to learn by creating that resource. At the same time, companies worldwide can use their courses to prevent boredom among their engineers. It’s a win-win situation.

By giving your developers challenging work and different tasks, you can easily eliminate boredom. Sure, sometimes there aren’t any exciting projects available, but everything can be interesting with enough variety.

Too much legacy

When you have too much technical debt in your company, your developers could be bogged down by trying to repair bad code and work on legacy projects with outdated tools. That isn’t only an inefficient way to use their time and knowledge—it can be a factor in their decision to quit their job.

According to Diff, technical debt is a metaphor developers use for short-term compromises to a software project’s code or quality design. That leads to difficulties when someone else tries to develop, test, and maintain that project.

It’s called “debt” because, as with any debt, interest needs to be paid—in this case, with the time and effort of every developer that comes after and tries to deal with the mentioned issues.

Maarten Dalmijn, head of product at Rodeo, summed up the problems that too much legacy can cause to developers.

As he points out, developers essentially waste their time dealing with technical debt instead of doing productive work.

That can be frustrating and impact engineers’ morale; a survey from Stepsize shows that more than half of them consider dealing with technical debt demoralizing.

Besides impacting the developers’ morale, technical debt lowers the production speed and quality of the overall product, the survey shows. This pushes the engineers to search for a job where those elements are prioritized.

The havoc that legacy can cause for developers is illustrated in the example of one developer working with 10 years worth of accumulated technical debt.

As he describes in his post, the monolith he’s dealing with has all sorts of problems, including objects that are no longer used, mixed-up naming, and quick fixes that someone else made long ago. All of that poses a risk for the project, and a situation like that can contribute to engineers looking for a job that won’t make them waste time.

Legacy can be a problem that impacts large companies as well. One notable example is Twitter, which reached a point where they had to overhaul their whole architecture built with Ruby on Rails.

As the company grew, Ruby was no longer suitable for their needs, primarily for real-time updates and delivering search results. They accumulated an increasing technical debt and eventually realized that they needed a significant shift to continue growing. They switched to Scala, which met their needs and eliminated technical debt.

That way, their developers could continue working on important features that were too difficult to implement with the previous programming language, which certainly was more fulfilling than dealing with more and more technical debt.

Engineers want to do meaningful, impactful work and develop exciting new projects. Tampering with exotic code, old databases, and inefficient solutions can eventually increase frustration and drive them away.

Bad environment

A workplace isn’t solely about working, despite what the name suggests. Engineers aren’t robots who function isolated; an environment where they work and the colleagues they share day-to-day life and responsibilities with can be a deciding factor for staying on the job or quitting it.

Suppose the engineering team members aren’t on good terms with one another, so they distract or annoy each other. In that case, that can impact their productivity and satisfaction with the job—nobody wants to spend a good part of their day surrounded by that kind of atmosphere.

Furthermore, if developers quit because of a bad environment, that’s an even bigger problem for the business. However you put it, a bad environment is a significant factor both for employees and the company.

For example, developer Michal Nagielski put together a hierarchy of developers’ needs in the workplace that depicts the importance of the working environment.

The way the hierarchy works is that you can’t move up to the upper level if the conditions on the lower level aren’t met. Therefore, without the ability to work and get along with their colleagues, developers can’t reach their full potential at their job, making them look elsewhere.

However, the most important factor, according to Nagielski, is the physical working environment. Developers who don’t have that basic need met most likely won’t stick around for long.

One of the most important aspects of a working environment for developers is the ability to focus and work distraction-free.

For example, an open-plan office where every department works together is an unsustainable environment for most developers—it rarely allows high-focused work due to multiple distractions.

Therefore, many companies provide developers with a dedicated working space. For instance, STX Next, a Python development company, has separate rooms for developers where they can focus more easily.

As you can see, they still work in a shared space, which makes collaboration and building relationships easier, but they don’t have to deal with distractions from all the other employees and their workflow. That way, they are less likely to quit due to a bad working environment.

And when it comes to building relationships and bonding as a team, you can contribute to that by offering recreational activities to your engineering team.

Having fun at work is a great way to have a positive work environment. Let’s look at Dropbox; they provide various ways for their employees to relax and bond.

For example, they have a coffee shop inside their headquarters. Their developers can hang out there in a pleasant environment. With facilities like that, it’s unlikely that their staff can quit because of the bad working environment.

Having friendly colleagues and a work environment that’s pleasing and functional are basic needs for most employees—your software engineers are no exception. Provide them with that, and you can minimize the chances of losing valuable staff because of a bad working environment.

Poor benefits

If you offer low salaries and poor benefits to your engineers, don’t expect to form a good engineering team. Most developers who value their work and skills will look for an employer who also values that.

Employers who think that engineers are greedy and only care about stashing the money are missing the point.

Salary and benefits have implications other than financial; they are a way to show your developers that they are appreciated and that their work matters to the company.

And without that, your engineers can quickly find another employer who would offer them more. According to a survey done by Stepsize, salary is the number one factor when choosing a job.

As you can see above, salary may be the most important only by a small margin, but it’s still the number one factor. If you don’t want to lose your engineers, you should be competitive in that regard.

Keep in mind that good software engineers are highly sought after and know their value. Those who agree to poor benefits are usually inexperienced. In today’s job market, few developers would work for benefits like the one in the example below, which refers to an experience from the 1980s.

Engineers can avoid horror stories like that easier than ever before, thanks to the fact that other companies’ information and benefits are just a few clicks away. Engineers can quickly find out where they’re going to have better benefits.

For example, Zuhayeer Musa co-founded levels.fyi, a website for developers’ salary data to enable them to do just that.

If you offer poor benefits to your engineers, they can check what your competition offers to their employees and quit their job at your company.

Here’s an example of top companies with the highest software engineer salaries in the US, according to levels.fyi.

As you can see, the website also lists other compensations besides the salary. You can see the value of stocks and bonuses that the software engineer can get in these companies.

That’s because benefits are more than just a salary. For example, some companies offer other financial benefits like the previously mentioned stocks and bonuses, and some offer other perks like medical examinations, wellness reimbursements, learning classes, etc. Meta is one of them.

Similarly, Apple offers a range of incentives, especially financial ones, including stocks, retirement plans, and income protection.

Benefits like those show your engineers that they’re appreciated and valued in their workplace. Who would want to quit a job that makes them feel that way?

Stress or burnout

Subjecting your engineers to excessive stress, long work hours, and tight deadlines can cause them to quit. You don’t want that, so you should avoid pushing your engineers to the breaking point.

That breaking point is also known as burnout. According to the World Health Organization, burnout results from chronic workplace stress that hasn’t been successfully managed.

Those who experience burnout are exhausted, demotivated, distanced, cynical about their job, and their efficiency reduces. All of that can result in resigning.

According to a study done by Haystack on software engineers, the recent pandemic of COVID-19 increased the risk of burnout among them—83% of engineers reported experiencing it.

The factors that cause burnout in the workplace are most often the following:

• demanding workload;
• problems with management (role clarity, communication, feedback);
• toxic atmosphere;
• lack of autonomy and influence;
• lack of personal and professional development opportunities.

If your business has the problems listed above, there’s a high chance that you risk losing your engineers. They can always look for a workplace that won’t negatively impact their health.

And the ones that don’t recognize the signs in time will quit when the burnout gets so severe that they become physically unable to work.

In developers’ stories like those above, you can see how burnout can impact an individual. The first one had to quit his job after they couldn’t get out of bed anymore and never returned to the same position in the company.

Furthermore, the second experience describes the efficiency of a burnt-out developer; despite their efforts, tasks that are usually routine become virtually impossible.

It’s understandable that engineers who experience that amount of work-related stress quit their job and look for something less intense.

That’s especially the case in the gaming industry. Some companies are notorious for pushing their engineers to their limits to meet deadlines and maximize profit. The result is often a toxic workplace, underpaid employees, and staff resignations.

One example is Rockstar games, a giant in the industry which has often been criticized by its former employees because of the mentioned practices.

There are multiple testimonials about burnout at Rockstar and examinations of the working conditions in the company.

However, that kind of stress level seems to be a rare case among software engineers. According to research by Stack Overflow, the majority of developers work 40 to 44 hours a week.

Despite that, some developers are still clearly overworked: 7% of them work ten or more hours a day, and there are 1,8% that work 70 hours a week or more, which can be a cause for concern.

If you don’t want your software engineers to quit, you should be aware of common causes of burnout and the ways to prevent them. An engineer’s job can be demanding, but within reason; if you don’t pay attention to the signs, your engineers may look for a different workplace.

Conclusion

Nobody wants to lose a great employee.

People are the company’s greatest asset, especially software engineers. A good team of hardworking and creative engineers can mean the difference between mediocre companies from great ones.

Luckily, you can do a lot to keep your team members by minimizing boring projects, taking care of legacy and technical debt, improving the environment and benefits, and preventing burnout.

Those are significant tasks, but they bring significant results which can greatly improve employee retention.