Why Your Developers Are Leaving
“Big Chief’s gotta move on.” This is a family saying in our house, and we don’t really know why. When it’s time to leave or switch activities, we use this phrase to trigger the transition. As the resignations pour into bosses and HR departments during this “summer of resignation,” employers feel just as baffled when […]
“Big Chief’s gotta move on.” This is a family saying in our house, and we don’t really know why. When it’s time to leave or switch activities, we use this phrase to trigger the transition. As the resignations pour into bosses and HR departments during this “summer of resignation,” employers feel just as baffled when they hear “I need to move on” or “it’s time to make a change” as the hollow responses to why a valued employee has taken another job.
There are millions of software developers across the U.S., and more people are entering the field every day. But this supply pales in comparison to the seemingly endless number of vacancies. Many employers say as many as half of their developer seats are empty even as recruiting is “turned on full blast.” Every developer is receiving 10-20 emails and calls a week from headhunters (put Java or Python on your LinkedIn profile, and see how long it takes until your phone lights up). If you want to keep your developers, you need to understand what gives them the wandering eye and makes them leave.
Why are developers leaving, and can an employer do anything about it? You may not be able to stop all the big chiefs from moving on, but one thing is certain: understanding and empathizing with the top reasons developers leave will lead you to make some changes that might retain your top engineers. After talking with many developers, I compiled the top factors that pushed (and pulled) them out the door.
First, let’s address the green elephant in the room: cash. In this market, it’s assumed that a developer is not going to switch jobs unless they’re getting a raise. The simple economics due to the protracted disparity between supply and demand require it. When they’re getting job offers every week, no self-respecting engineer is going to take a pay cut or even a lateral when they move on. But cash isn’t why they leave (or why they stay). With so many open jobs, software engineers can select a job based on many factors, way beyond salary level. It’s those factors that employers often ignore, deceiving themselves that a more well-heeled peer will always win at the poaching game. If your salary levels are competitive, other factors like these will tip the scales.
“I’m not being heard.” This has nothing to do with software development; it drives people to quit their jobs everywhere. Bosses should understand that listening– along with validation – goes a long way to creating a happy work environment. Look at these sentences found in the honesty vault:
- “I’ve told my boss five times that if we changed how we do testing, we could save months of time.”
- “Since February, I’ve been asking our customer to meet with us instead of sending emails because we could get things done right the first time.”
- “I have no idea why every afternoon he asks me for the daily results; that’s what the dashboard is for. And he’s the one who asked me to build the dashboard.”
These observations are all for the good of the company, yet imagine expressing them repeatedly into an echo chamber. These frustrations don’t need to go on long before the resume gets refreshed and a headhunter’s call gets returned. Regular checkpoints – bi-weekly or monthly – are an easy venue for listening to employees. Listening doesn’t mean that every suggestion gets acted on; the act of genuinely validating goes a long way toward showing someone they’re valued.
“Performance appraisals and raises are a joke.” How would you like to have to complete a seven-page self-appraisal every six months? Sounds like torture. I’ve had employees tell me they quit before their appraisal was due just so they could avoid the process. Software developers function as part of a team, and those development teams often use some form of the Agile methodology. Traditional HR practices such as annual or semi-annual appraisals conflict with Agile feedback loops, and this conflict can frustrate technology people to the point of quitting. When it comes to performance assessment, the table below shows where friction can occur between developers and their employers:
Engineers frequently quit because they believe their annual rating or “grade” (which determines their salary) is detached from the body of work their team has delivered over the year. The typical engineering team delivers 25 sprints over a year’s time in the face of changing stakeholder requirements. While doing so, the team evolves through many feedback loops, adjusting its performance while holding each other accountable for delivering business value through software. The idea that at year’s end, a boss enters the picture with a goal of giving each individual a rating and raise is jarring and, in some cases, mock-worthy.
What can employers do? Several best practices have evolved around Agile performance management, and the internet has an abundance of useful blogs, videos, and tools for how to integrate Agile practices with the company’s need to comply with HR policies (such as compensation adjustments, promotions, etc.). At the very least, bosses should know that most development teams are self-assessing, and the best way to keep them engaged is not to encumber them with HR and corporate appraisal requirements. Remember: they love to build software, so let them do it. After all, that’s why you hired them!
“I used to love to code, but I’m doing it less and less every day.” Most developers love to be in the zone, that’s where they do their best work. Architecting an elegant piece of code is true artistry, and engineers are rightfully proud when they work for days or weeks on a class library or an interface to make it self-documenting, easy to extend, and efficient. Employers often feel that they’re doing the engineer a favor by making them a supervisor or giving them non-technical responsibilities, but engineers might not see that as advancement. Some see it as the precise reason they sought to be a developer in the first place – to avoid the headaches of management and meetings. Good technology bosses understand each person who works for them and don’t make assumptions about what they want from their career. I had an employee quit after being promoted to “manager,” because he believed that title was a death blow to his tech career. I didn’t need to learn that lesson twice.
“Who are we building this for?” It’s easy to see software professionals as mercenaries – hired guns who sling code for money. I’ve found this isn’t the case. As their careers age, software engineers love to see their code in action and helping the world. At the very least, they’d like to see that their code doesn’t just enrich shareholders or company owners. Here’s where employers frequently fail: they do not connect the software to the real world value of the larger mission. If you’re building a more efficient hotel reservation system, you have an opportunity to show your team how this will make it easier for families to attend weddings and reunions, and for hotels to add safety features and amenities to their properties. Software developers frequently quit when they feel like the code they’re writing isn’t helping anyone or making a difference. Employers who can vividly illustrate why their tech projects matter have an energized technology staff.
In this market, the real trick to keeping developers happy and engaged is captured in the old song: to know them is to love them. The best employers choose to invest time getting to know each technology employee, listen to what bugs them and pay attention to what really makes them happy. Remember: it’s different for each person, and even each person is going to change as they grow and evolve. If you can listen and adjust, Big Chief may not move on after all.