Why Your Best Engineers Are Leaving

When a strong engineer resigns, the instinct is to treat it as a transaction. Post the role, review the compensation, update the job description. If there's an exit interview, the answers are noted and filed. By the time the replacement is onboarded, the departure has been administratively closed.

The problem is not the process. The problem is that the process is designed to fill a seat, not to understand what the departure was telling you. And engineer departures — particularly of the best ones — are almost always telling you something worth understanding.

The Selection Effect

The engineers who leave first are not a random sample of the team. They are the ones with options — which means, almost by definition, they are the most capable. They have the strongest track records, the most legible skills, the widest professional networks. When the market for their profile is reasonable, they can find a new role within months. When it is strong, within weeks.

This matters because the sequence of departures is not neutral. A team that loses its strongest members first degrades faster than the headcount loss suggests. The people who remain are not just fewer — they are, on average, less experienced, less connected to the organisation's institutional knowledge, and carrying a higher share of the work that was distributed across a larger team. The departure of one strong engineer often accelerates the departure of others: they observe that someone they respected chose to leave, and the question of whether they should forms in their own minds.

What engineers call "culture" is usually a proxy for something more specific: can I do my job well here? When the answer becomes no — consistently, not occasionally — the ones with options act on it. By the time the departures become visible at a leadership level, the underlying conditions have usually been present for months.

What the Departure Is Actually Signalling

Analysis of exit interview data consistently finds that compensation ranks fifth or lower as an actual driver of engineer attrition. The leading causes are structural: stagnation — the work has become repetitive and the team is not building new things; autonomy erosion — decisions are being made without technical input and engineers are executing rather than contributing; and impact disconnect — the work being done cannot be connected to outcomes that matter.

Each of these is a symptom of a management or prioritisation failure, not an individual failure. A team in maintenance mode is in maintenance mode because product leadership has not created the conditions for new work. A team executing without autonomy is doing so because the decision-making structure does not create space for technical judgement. A team that cannot connect its work to impact is working in an organisation where the link between engineering and business outcomes has not been made legible.

The engineer who leaves citing "lack of growth" is describing a structural condition. The most common response — a conversation about career development paths, a training budget, an individual growth plan — addresses the surface and misses the cause. If the work itself is not interesting, no development programme compensates for it. If the team is building the same things in the same ways with the same constraints, the individuals within it cannot grow regardless of what is written in their development plans.

The Technical Debt Problem

Technical debt is not a technical problem. It is a prioritisation problem — the accumulated result of decisions, made over time, to trade future cost for current speed. And it is one of the most consistent drivers of engineer attrition, precisely because its effects are invisible to the people making those decisions and inescapable for the people living with them.

Engineers working in high-debt environments spend their days fighting fires rather than building things. Every change requires navigating a system that was not designed for change. Every feature requires working around constraints that should have been addressed months ago. Progress is slow not because the team is underperforming, but because the environment makes progress genuinely difficult. The best engineers — the ones who know what good looks like — find this particularly intolerable. They have seen cleaner systems. They know the difference between a constraint that is inherent to the problem and one that is the consequence of decisions they had no part in making.

Replacing a departing engineer with someone new does not resolve this. The new hire arrives in the same environment, encounters the same friction, and eventually reaches the same conclusion. The team can spend years cycling through talent without ever addressing the conditions that are causing the cycling.

The Craft Question

There is a characteristic that distinguishes organisations where strong engineers tend to stay from organisations where they tend to leave, and it is not pay, perks, or flexibility. It is whether the organisation treats engineering as a craft worth investing in, or as a cost centre to be managed.

This distinction shows up in specifics. It shows up in whether technical decisions are made with technical input or handed down from above. Whether time is allocated for improving existing systems or only for shipping new features. Whether engineers are expected to simply execute requirements or to contribute to how requirements are formed. Whether the organisation's leadership understands and acknowledges the difference between fast delivery that accumulates debt and sustainable delivery that does not.

Organisations that treat engineering as a craft attract and retain engineers who take their craft seriously. Organisations that treat it as a production function attract engineers who are comfortable being production workers — and lose the ones who are not.

What a Departure Requires

The right response to a strong engineer's departure is not a backfill. It is an investigation.

Not a post-mortem that produces a document and a set of recommendations that go unimplemented. A genuine attempt to understand what conditions in the organisation made staying less attractive than leaving, and whether those conditions are still in place for the people who remain.

The questions worth asking are not the ones on the standard exit interview form. They are: what became frustrating about the work over time, and when did the frustration start? What decisions were made in the last year that the team disagreed with but did not feel able to challenge? What would have needed to change for the decision to stay to have been the more obvious one?

The answers to these questions, taken across multiple departures and treated as signal rather than noise, describe the actual state of the engineering environment. They describe it more accurately than any survey or performance review, because they come from people who have already concluded that candour carries no professional risk.

A leadership team that reads this signal and acts on it stops the cycling. One that reads it as HR data and responds with process changes is likely to have the same conversation again in six months, with a different name in the resignation.