Why Do Developers Leave?
Everyone wants to attract/keep good developers, and the first step to recruiting and retaining them is to understand why developers are leaving their previous job. Regardless of the advancement level, there are many reasons why developers look for a new job.
I would like to share with you my professional experience of changing jobs, which hopefully will be valuable whether you are a developer, looking to get into development, or you are a recruiter or company looking to attract developers. If you would like to know more about me and my history, take a look at my article “From spare-time freelancer to full-time developer and beyond”.
1. Boring Projects
There is nothing worse in development then working on tedious projects for a long period of time without freedom to improve it. If opening the office door on a morning is followed by a sigh then this is a ‘I want to leave’ symptom. There is a simple and obvious cure for this — swap the developers around, give them other responsibilities and opportunities, to stop them becoming bored. But, this is easier said than done — due to company targets and project requirements — and developers are often expected to power through.
2. Wrong Culture and Environment
If you find yourself surrounded by people you have nothing to talk about with, and you feel like conversation subjects do not resonate with you and are annoying (and often working remotely does not help), your workplace will not have a good impact on you. People you work with create the atmosphere which you absorb. Being a developer can be stressful and if you add unnecessary stress factors such as inappropriate comments from other colleagues, you will soon start hating your workplace. If you add air conditioning and heating issues, an uncomfortable chair and a tight space to work in, then it is not hard to end the day being annoyed and frustrated.
3. Other Devs
You can work with great managers, team leaders, HR, but other developers are closest to you and have the biggest impact on you. Ideally, each developer would understand what teamwork actually is and be supportive, friendly and avoid unnecessary and nonconstructive criticism. There are many types of developers but in my opinion “I know best” and “I don’t like it” developers are the worst. It is great when you have someone next to you who has more experience but sharing it with the team is what makes it actually valuable to others.
The “I Know Best” Developer
You’ve been working on a feature for some time, you are excited to release it and then you are slapped in the face with comments on a pull request that your implementation is bad from the “I know best” developer. Criticising for the sake of criticising is a completely different beast to offering constructive criticism (someone pointing out a fault politely with the intention of helping you improve your code, ideally accompanied by some positive feedback too). I liken it to slicing into someone’s abdomen to hurt them, compared to slicing into their abdomen while they are under anesthetic and for a life-saving operation. The feedback may be very similar, but it is how it is done and why it is done which separates a barbaric attack and an act of heroism. Okay, maybe that was a little dramatic. But you get the idea.
These devs seem to think you deliver potential issues on purpose to spice up the day, or possibly have some sort of sneaky plan to ruin the code base! I have no idea what drives their thinking but these comments, if reoccurring, can make you feel like whatever you do is not good enough and that no matter how hard you try, you will be criticised.
The “I don’t Like It” Developer
The “I don’t like it” developer is similar to the “I know best” developer, but I believe his drive is that you have not written the code the way he would. Which should not be a surprise because you are not him (mind blown). They quite often cannot understand that solutions can be delivered in many ways but the symptoms of their actions can impact you in the same way as a previous type. Try to ignore any malice in these comments and take what’s valuable in them — knowledge — they may share some of it in their comments, as they also desire to be perceived to be better.
The “I Can’t Be Asked” Developer
There is also “I can’t be asked” developer, who will give you a demotivating look anytime you want to introduce an improvement that could lead to extra work, even if it is a benefit for a company and the team in general.
Working alongside any of these three types of non-team-players can wear a developer down, and ultimately push him/her towards the door in search of a better team to work alongside.
4. Salary Expectations / Poor Benefits
Money, money, money…this is what we work for and quite often we feel like doing the same job for another company we could have more. Simple as that. Money is a practical thing, but it also has emotional implications. If you discover your company is underpaying you, it gets you thinking… am I not valued? Do they not appreciate all the hard work I do for them? Is this all they think I am worth?
Also, if you have just your salary, and no other benefits, what is there to encourage you to go above and beyond for the company? One email from a recruiter listing benefits that you like the sound of and you will be considering a move.
5. Too Much Legacy — not catching up with technologies
This goes hand in hand with the first point as it can be very boring to just work on the same old legacy project, but a lack of new technologies can also be a major blocker in your personal development. Fears that you will end up being unattractive in the market if you work on ancient technologies for a long time are real.
In the development sector things move very very fast and companies struggle to stay on top, but a company leaving their tech stack too far behind is dangerous. Not only do they put the company at risk, but they could also be jeopardising their developer’s future careers. A company might be tempted to brush this off thinking “so what, we don’t want them to move anyway” but developers are a bright bunch, if you feel like you are becoming stagnant in a job you might be forced to jump ship before your skills are put at the risk of becoming outdated.
6. Lack of common goals and motivation
Why do you work for your current company? What is your goal and motivation behind it? If this is just a salary then I am afraid it is not strong enough to keep you going for a long time. You need to believe in the product you develop otherwise you will soon become disillusioned. If you do not believe in the product you develop then you will not be as effective in your work. You will be just doing the job for the sake of doing it.
7. People leave management not the company
Company is an abstract term. We often say — “I like this company” — but what is about that company that you like? Do you mean the people? Projects? Management? Often, it is argued that people leave management rather than the company, and there is a simple test to see if the company is managed properly. Do people still work if the managers are not there? Does the company continue as usual, or do people just do the bare minimum or even nothing? From speaking to other developers, this is a biggy when it comes to moving on. So I’ve split it into three common sub-sections.
Lack of Trust
Developers need to be able to trust management and in return management will be able to trust developers. If we do not trust the people around us, we will always find a reason to question their actions. People focusing on problems find more problems, people focusing on possibilities find more opportunities.
Not Feeling Valued
Another management issue is neglecting employees and not making them feel valuable. Simple catch up meetings once in a while with constructive and honest feedback should be enough, but even this sometimes is missing. Employees will then be not sure what they do in the company and what they can expect from it.
Broken Promises
Actions speak louder than words. If you are promised something by your employer and it is never delivered, you can lose faith in them. This links back to the trust idea. If you are constantly told you will get something and it never appears, then eventually when the management is about to genuinely offer you something more you won’t believe it. Like the boy who cried wolf.
(Here is another interesting read about how employees leave management not companies)
Hierarchy of Developer Needs
Ever heard of Maslow’s Hierarchy of needs? It occurred to me that developers also have a hierarchy of needs in the workplace. Here is my Hierarchy of Developer Needs, with the most vital at the bottom building up to the ideal scenario at the top. The theory behind Maslow’s Hierarchy is that you are unable to move up to the next level of the structure unless the level underneath is there. I have tried to structure my interpretation in the same way.
If you can find all of these things in a workplace, then you are in a great situation to be your most satisfied and producing the best work. If the company cannot even offer the lower levels, then you are unlikely to be sticking around and are more likely to be feeling discontented and not producing your best work.
Dear Employers Everywhere…
If you want to keep the best developers (and indeed staff in all departments), then this is my advice to you:
- Build relationships with your staff members. Nothing bonds a company better than strong and honest relationships. If your employees feel like anything can be discussed, you are fixing a massive leak in the staff bucket.
- Do not promise things you cannot deliver. Dishonesty ruins trust, and without trust there is no cooperation and growth. If you can’t offer something, be honest. At least you can offer honesty, which is often a lot more valuable than money.
- Respect your employees. They work for you to help you grow and without them your business cannot flourish.
- Employees are human too and have a private life. This means that they are highly unlikely to be happy sacrificing their life and time outside work to do “little tasks”. If the contract is for a certain amount hours, both sides should stick to it unless both sides agree otherwise. If your employees are happy in their job, occasionally they might choose to do a little extra outside of working hours because they have a great idea or get engrossed in a project. The moment you force them to is the moment they stop wanting to.
- If you do not listen to your employees they will leave. It is understandable to have policies but it is even better to have a reason behind them. Saying “we prefer” without specifying a reason means that most likely it is a trust issue.
- Provide training if needed. Every developer has a different set of experience. If you need your staff to work with a new technology, support them with training to allow them to do this to the best of their ability.
Dear Fellow Developers…
But, of course we (developers) must take some responsibility for leaving too…
- The perfect codebase does not exist. The moment you create your first line of code in your first file, you may have caused a potential future issue. Developing is not an easy job. Deal with it.
- Be a team player (overused phrase but the sentiment is relevant). If you want to be on your own and be in charge of everything, write your own app. Support those around you.
- You are not the best. Lower your ego, share the knowledge, educate others. This is how you can grow as a true professional. The moment you think you are the best you cut off any opportunities for your own growth.
- Before you begin making demands of your manager and company, make demands of yourself. Are you fulfilling your side of the bargain? Are you being the best employee you can be? If you want to be treated with respect, earn and maintain it. It is a long road and needs work. Do not expect to be treated like a king just because there is a high market demand. It’s not nice.
- Learn, learn, learn. The more you know, the better your solutions will become. Are you actively looking for challenges or being a bit lazy?
- Be worth your costs. You need to be profitable for a company to keep you, so deliver what the business needs. Sorry, law of economy. Imagine you are a one-man company and your boss is your client. Why does your boss want to keep using your services? Are you constantly striving to offer the best services you can? Better than your equivalent elsewhere?
- Deliver to the best of your knowledge. Sometimes codebase will not allow you to but if it does, leave it the way you’d like to pick it up.
If you found this article interesting, keep an eye out for my follow-on article ‘Why developers struggle to find a new role” coming soon. In the meantime, any feedback on your own experiences are welcome.
