Introduction

Based on exit interviews I and friends who are also managers have done over the three years here is a list of reasons, and possible fixes, on why engineers leave their jobs. And while no one example below is a flip the table thing, over time, it will grind people down until they see no hope and leave.

Hire managers that cannot build software

What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch.

You can fix this

Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature. It cannot be some fluffy feature like changing a line of text but a customer feature from the backlog. It should be sized to about three days, and the manager should work the same way as the team works from a collaboration perspective etc.

Hire too many managers and introduce layers of them.

Once you have too many layers of management, it moves the decision making higher up. It will require a meeting to change something. More discussions lead to less direction at the team level. When a higher-up manager wants something done, they may communicate poorly to the next manager, and eventually, the team misses out. The poor communications lead to teams wondering what they are supposed to be doing.

You can fix this

Flatten out your organisation, remove as many layers of management as possible.

Do as many meetings as possible.

Suppose it is not clear what people need to do. If people are unsure how software gets made, if there are many dependencies between teams, have a meeting, make a Gantt chart and hold people to that timeline, have as many meetings as possible to review the Gantt chart. If there are any open questions, ensure you have another meeting to get that question answered.

You can fix this

Design your organisation to minimise collaboration between teams, but have high collaboration within the team.

Make the process of defining software painful.

If an engineer has to shoulder the effort in finding out what needs building, then building the feature and doing it on their own, this will lead to unhappiness. Software development should be a team effort. Teams that don’t have a product person and other vital functions to help align the work will have discontent within the group.

You can fix this

A way to approach taking the burden of the engineer, When creating a ticket, a minimum of three people should talk for 10 mins on the ticket to ensure all the relevant detail is on the card, describing what the change is, how it will be tested etc. I have found the best three are an engineer, a tester and a product person. The product person should lead and provide context on what needs building while the developer asks for the behaviours of the feature and the testers questions how things are tested. If there is no consensus on what needs doing, the engineer does not start to build software. It should not solely be on the engineer to look for the info.

Make delivering software painful.

After writing your ticket, you still have the build-out of what was requested. If the development environment is hostile, you cannot develop locally, or it is difficult to test the change in your dev environment. If tests are flakey, or if it just stops working for no reason regularly, it makes life challenging for an engineer.

You can fix this

Depending on how rough your path to production is, there are a couple of ways of fixing it,

1. Do nothing. Let it hit a wall. I would not recommend this as it could be an existential threat to your job.
2. Start taking time back to fix these issues, starting with 20% time, analyse what is wrong and make a plan to start chipping away at it.
3. Write improvements to your new tickets, especially if it’s maintaining existing code.

Make engineers estimate their work.

Make them guess a month in advance of doing their work, and then when they don’t finish on time, you can blame them for not being good at predicting future events.

You can fix this

Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting.

Make the teams too small.

In some companies, it seems ok to have teams of three “app” engineers. They have adopted this model of “app” teams that make features. Any ops and QA is done outside the team or is part of a shared team. It is great until someone wants to take a day off and another person calls in sick. Suddenly it is challenging to be an effective team and puts lots of pressure on one person to deliver, do this long enough, and the person will crumble and leave.

You can fix this

In my opinion, Have a minimum team size of six.

Borrow from other teams

If you are an engineer who gets moved around to other teams when the company needs to get something done, it can be demoralising and provides a sure-fire way of grinding someone down as they get very little time to grow a career as an engineer.

You can fix this

Make teams long-lived, with a mission and do not move people around.

Epilogue

The above are some common anti-patterns for running engineering teams. There are fixes. Some of them are very easy to say and hard to implement because you live in a system, and changing systems, especially ones based on humans, are complex.
So I leave you with this common saying I acquired from a boss I had in the UK many years ago.
If you cannot change your company, change your company.