24
Why software engineers quit
In the last 10 years, I worked as a software engineer in different companies. With each team change, I learned more and more about the motivating reasons of a software engineer. The last company I worked in and left recently was an e-commerce company. Even if I enjoyed working there for quite a long time, there were reasons why the job demotivated me and lead finally to my resignation. In this post, I want to share some reasons why most software engineers quit their jobs.
Of course, salary is one of the main drivers for accepting or rejecting an offer. It is also kind of an appreciation for the skills and the effort of an engineer. Meeting the salary expectations is mandatory but it is not sufficient to make them stay. It is also less significant to motivate engineers on a daily basis. Further, if you reach a certain compensation level it becomes less important. We want to focus here on the aspects besides salary which has a major impact on the motivation of an engineering team.
Before moving on to the other reasons I want to point out the most important factor in an engineer's life. If you are new to software engineering you may only be interested in the coding part. In a healthy team, the purpose of the team is a 'must have'. Ask yourself why are you doing this job? Who are your customers? How does your daily work contribute to the overall goals of your company? Try to answer these questions with your product manager and your engineering manager. It will not only help to motivate you it will also ensure that you focus also on the right problems and avoid working on things that don't matter. If engineers can't connect their daily work with a higher goal, they might quit.
Product development is a long process, starting from the ideation phase and ending with the release and onboarding of the users. Most companies apply the methods of Agile development only to the implementation phase which is only a small part of the process. By doing this you miss some advantages the Agile methodology provides like team empowerment and risk mitigation. With team empowerment I mean the early involvement of engineers into the product development lifecycle which brings the following benefits:
- More creative ideas
- Early risk mitigation
- Raising ownership feeling of engineers
The worst thing you can do is hiring creative people but don't make use of them. If you treat your engineers like 'coding monkeys' you will not get all the benefits from them. If engineers feel like mercenaries instead of missionaries they might quit.
How free is your team to make their own decisions? Autonomy is rather a scale than a binary measure. It has to do with the trust of the management in the engineering team. It is also wrong to take trust for granted, it has to be gained. If an engineering team delivers results in time and builds stable features the trust of the management in that team will increase. If the management is seeing the competency of the team, they will give more freedom to the team to make their own decisions. This is the normal process.
But some bad managers can not trust their teams even if the team proved that they are capable. In the end, it was also the managers who approved the hiring of the individuals, so why not trust your hiring process?
Lack of trust will move managers to interfere in the decision-making process of the engineering team. If the management interferes too much the team will feel micromanaged. Micromanagement is the opposite of autonomy. It will demotivate an engineering team in the long term. Engineers are smart people who want to face problems and solve them in a smart way. If decisions are taken from them, they will feel useless and might quit.
Technical debt belongs to the life of a software engineer. Sometimes you take the debt consciously, sometimes you didn't know better before. The demotivating part of technical debt is when it starts to really slow you down and you work in an environment that is really unattractive. Slow and unattractive are really subjective feelings. Each team has to decide on their own what is manageable technical debt and when it starts to disrupt the daily life of an engineer.
One of the problems with technical debt is also that it can not be measured in an accurate way which makes it hard to convince your managers to take the time to get rid of that debt. If you find yourself in an environment where you always add new features which increase technical debt and it is becoming hell to add a new feature you should do something about it. If your boss doesn't react then maybe it's time to quit.
24