How to reduce developer turnover in your agency

Software technology has a turnover rate of 13.2% – the highest across multiple industries. 

This is more turnover than even retail and consumer products, which are often short-term employment solutions. 

Furthermore, the turnover rate for embedded software engineers is even higher, at a lofty 21.7%.

The issue with retaining technical employees lies in their increasingly high demand and competitive compensation market. 

Employers will pay top dollar for software developers, and this incites career-hopping. 

To ensure this doesn’t happen to your team, this article outlines some strategies for reducing developer turnover – ones that don’t involve pumping up the paycheck.

Imagine a boss who never asked you how you were doing, checked in on your progress, or asked about your ideas. You’d feel unappreciated, stressed, and insecure – you’d likely leave.

This is why one-on-one meetings are crucial to reducing developer turnover. 

They’re the perfect opportunity to talk to your employees, frankly and honestly, about their satisfaction. Marcelo Tribuj said it best:

One-on-ones serve primarily to engage your employees, impress their value to the company, and listen to their thoughts and concerns.

For example, ask them about their project and how you can help. Are there any blockers? Is the documentation sufficient? 

Offer them feedback – highlight what coding solutions you approve of and what architecture could be more elegant. 

You can also set some goals for the next meeting so that they have an objective to strive for. Finally, ask them for their thoughts on the company. 

Are they worried about any recent changes? What’s their desired career growth? 

These questions help keep employees engaged, proving to the developer that the manager is invested in their performance, thus decreasing turnover. A recent study revealed the following numbers:

As a great engagement booster, one-on-one meetings are crucial to decreasing turnover rates.

This is a strategy Adobe has adopted. The software company scrapped its performance reviews altogether, replacing them with regular one-on-one meetings -‘check-ins.’ 

Adobe management saw increased attrition rates after the standard performance review and knew they needed to solve it.

Enter the check-in: an informal one-on-one meeting with no paperwork, yet beneficial to the employees’ growth. Below is the general framework:

By periodically discussing the three topics above, Adobe experienced colossal success: they saw a 30% reduction in voluntary turnover.

Adobe proves that hosting regular one-on-one meetings is crucial for retaining your employees. 

You might have a busy schedule, but carve out some time to sit down for each of your developers at least once every two weeks for 30 minutes; decide on one recurring timeslot, and put it in your calendar.

 You likely have 50 other tasks but don’t neglect these meetings. In a recent Twitter post, Jean-Michel Lemieux revealed how many weekly one-on-ones he has:

Spotify’s Chief Technology Officer has the time to have 15 weekly one-on-one meetings. 

If he can pull that off in Spotify’s fast-paced, dynamic environment, so can you. Make time for your developers – the one-on-ones will pay off.

Unfortunately, outdated work practices can be found in many companies. 

Businesses will insist on a 9-to-5 working schedule, demand on-site work, and take offense if employees aren’t glued to their computer screens. 

However, these are also all surefire tactics for your developers to leave.

Traditional work environments don’t allow any flexibility, despite this flexibility being important to developers. 

In a recent Stack Overflow survey, developers listed their most important job factors:

As we can see from these numbers, flexibility and remote work options are crucial factors. However, they’re both fairly new concepts, and not every company will offer them.

For example, take a look at this Reddit post:

This developer enjoys their job, isn’t stressed, and has even gotten a raise. However, they can’t stand the one-hour commute – it’s ‘killing them’ – and will likely leave because of this. 

Allowing remote work would solve the problem immediately.

Flexible working hours also mean a lot to developers. At the end of the day, the hours that make up the workday aren’t important; the results are. 

If a developer completes all their tasks within 6 hours, why should they sit in front of a computer for an extra 2, pretending to do work? 

Similarly, some developers prefer to code at night and sleep in the morning. Other developers work best at sunrise and like to be finished by 3 pm. 

Why should either employee be confined to Henry Ford’s 20th-century framework? 

Give your developers the freedom to work how they know best. Jennifer Jones Newbill commented on this as well:

By freeing developers from the standard constrictive 9-5, you’ll keep them happy and encourage them to stay with your company.

Outdated practices aren’t frustrating in terms of company culture – they’re also problematic within technology itself. 

Many processes today can be streamlined, and it doesn’t make much sense to constantly work manually. Even something as cumbersome as bug reports can be automatized.

For example, Shake is a modern bug report tool. All users need to do is just shake their device, and a bug report is immediately sent to the developers. Here’s an example:

This fast, efficient process – just shaking the device – is an excellent tool for reporting bugs quickly. 

You don’t even need to leave the app to report the error; there’s no need for Slack messages. 

Besides, as many details as you want can be in the bug report – screenshots, steps to reproduce, app version, logs, and more. 

As a general rule of thumb, developers are good at programming; it’s what you hired them for, after all. 

By that logic, they should be coding as often as possible. However, unfortunately, this isn’t always the case, as a recent troubling survey revealed:

Over 60% of developers spend only half their workday actively programming. 

The other half gets lost in meetings, testing, paperwork, and multiple other functions that, realistically, someone else can handle. 

Developers often aren’t happy with this turn of events, as they’re being taken away from their core function.

One Reddit developer recently asked for help about how to handle a position without coding. This was the most upvoted response: 

This developer was furious and advised the original poster to leave immediately. The other answers had similar advice – no one was willing to work in a coding-less workplace.

So, how to give your developers the time to code and keep them happy? One effective method is to pick up any non-technical task. 

After all, it’s your developers’ job to code. 

As their manager, it’s your job to facilitate relations between your team and the rest of the company, which typically includes meetings and paperwork. 

For example, if a new feature needs to be explained to the Sales and Marketing departments, you can fill them in. 

Compose a brief with screenshots so that your developers don’t have to spend time writing it; or, worse yet, explaining it in a meeting. 

If it should come to a meeting, attend it alone. As their manager, you should know the project well enough to answer any questions. 

That way, your developers can devote their time to technical tasks. This software manager summed it up nicely:

This manager has delegated technical tasks to his entire team, which they are sure to appreciate—working in such a technical-centric environment will probably reduce developer turnover.

In the same vein, it’s essential to fight for reasonable deadlines when negotiating with stakeholders. 

Argue against unrealistic expectations and calmly explain to any stakeholders what can and can’t be delivered. 

Provide your developers the time they need to complete a feature without any unnecessary overtime. Ben Dovey explains below how he did it:

This approach is the correct way to handle projects; be frank with stakeholders and give your developers plenty of time to code. 

They’ll appreciate you advocating for them – something that will definitely incite loyalty to the company.

You’d be hard-pressed to find a junior developer happy to remain a junior developer. 

After all, who’d be satisfied perpetually stagnating? In fact, a Glassdoor survey found that lack of career growth is the 2nd-most common reason software engineers leave their jobs:

With these insights, it’s clear that offering career advancement opportunities are a must for decreasing developer turnover.

That being said, career advancement opportunities aren’t synonymous with managerial positions. 

Managers must have highly sophisticated people and soft skills, whereas some developers prefer sticking to their trade: coding.

Because of this, two career paths exist: individual contributors and managers. This is a practice many companies have implemented, including Facebook, Airbnb, and more.

Individual contributors are experts in their niche; they push product strategy while executing and iterating deliverables. 

This career path allows them to continuously develop their technical skills, which often results in them mentoring juniors. A standard growth plan looks like this:

While an entry-level engineer operates autonomously, the principal engineer will determine and headline company-wide projects – but not manage them. 

This career path is ideal for developers who want to avoid a people-centric role; they’ll be thankful for the option and will likely be eager to advance.

The classic managerial advancement has a much larger focus on interpersonal relations. 

Managers do their best to support other employees, aligning goals across multiple departments and removing obstacles for individual contributors. 

They assess if roadmaps are realistic and determine how much can be expected from a project.

Below is a standard managerial growth plan:

Software managers’ primary role is to support their teams, guiding them and helping them achieve their goals. 

More people-orientated developers will flourish in these roles and will likely stay at companies that offer this opportunity.

Besides these two career paths, there’s also a philosophy known as ‘unstructured learning.’ 

The most well-known case study is Google, which reserves 20% of employees’ time to work on external projects. 

By allocating time to work on side projects, workers foster innovation and creativity and come up with solutions they might have never thought of within the standard corporate workday approach. 

The CEO of Hireology attests to the method’s success:

By giving developers free time to work on what interests them and what they feel genuinely passionate about, you’ll gather your developers’ loyalty; they’re almost guaranteed to stay. 

Developers greatly appreciate working in an atmosphere of trust and collaboration; that way, they’ll all be able to assist one another as one cohesive community. 

If you can create this atmosphere, you will likely retain your developers.

In a collaborative environment, developers work on projects together, devising creative solutions and completing tasks more quickly. 

Individually, they wouldn’t be able to work as efficiently. In fact, Elon Musk refuses to retain non-supportive co-workers.

The SpaceX CEO vetoes any uncooperative employees. 

By building an environment of only team players, developers should be much more likely to stay, as they know they’ll always be supported.

If you’re unsure what a quality community looks like, one company has mastered the concept – Paragus IT. 

This IT provider has constructed a ‘Wall of Fame’: a wall listing former employees, highlighting the benefits they bought the company. 

Instead of resenting and ostracizing the departed workers, the company honors their accomplishments. 

Those workers remained a substantial part of Paragus’s community, despite no longer being employed there.

Below is an example of a ‘Wall of Fame’ plaque:

Paragus truly values every contribution made towards the company and even considers those no longer employed part of its community. 

This strategy paid off; the company successfully reduced its attrition rates. It makes sense, as their developers couldn’t find a stronger community to be a part of.

Besides the ‘Wall of Fame,’ Paragus inspires the community with more conventional methods. For example, the company provides staff lunches and even operates an office ‘pub’:

By providing a relaxed, social setting, employees are sure to connect with one another and build meaningful friendships. 

That will then translate into a healthy, collaborative community environment that developers will love to be a part of.

Besides these outward efforts, a community environment often depends on mindset – you need to address the root causes. 

Ideally, your developers should function as a whole; they should all share the same vision, values, and goals. 

This will unite developers in their work, as they operate under the same principles. Ken Blanchard explains it below:

If there is no vision to guide people, they tend to revert to selfishly focusing on themselves. 

However, by imparting the company’s vision and goals to them, your developers will realize that they’re all in this together as a community. 

That sense of collaboration, trust, and motivation is bound to increase your developers’ desire to stay with your company. 

Employee retention is a problem even at the biggest companies; technical employees at both Tesla and Dropbox tend to leave after only two years. 

You’ll never be able to eliminate turnover completely, but you can implement practices to reduce it.

Keep your developers technical – make sure they’re programming, and offer career advancement opportunities. 

Organize one-on-one meetings and create a community-like environment, so they’ll receive all the support they need. Finally, abolish outdated work practices such as a strict 9 to 5 schedule.

By sticking to these methods, you’re bound to reduce developer turnover in your organization as much as possible.