Why Great Engineers Sometimes Make Poor Managers

Over the years I have promoted more engineers into management than I can easily count, and I have watched a meaningful fraction of those promotions struggle. Not because the people were weak, but because they were exceptional at something other than the job we had just handed them. The pattern repeats often enough that I now treat it as a structural problem rather than a personal failing, and I think the industry would be healthier if we talked about it plainly instead of pretending every great engineer is a manager waiting to be discovered.

This is not an argument against engineers becoming managers. Some of the best leaders I know came up through the codebase. It is an argument for understanding why the transition is hard, why our instincts about who deserves the role are frequently wrong, and what we can do about it before we burn out a talented person and destabilise a team in the process.

The Skills That Made Them Great Are Not the Skills the Role Requires

The thing that distinguishes a great engineer is usually a deep, almost stubborn ability to hold a complex system in their head and reason about it precisely. They are rewarded for correctness, for finding the elegant solution, for being the person who can debug the payment reconciliation job at two in the morning when nobody else can. These are individual capabilities, exercised mostly in solitude, measured against an objective standard: the code either works or it does not.

Management asks for almost none of that. The core of the role is creating the conditions in which other people do good work, which means the unit of output is no longer your own cognition but the collective output of a group of humans who disagree, get tired, have ambitions, and occasionally make decisions you would not have made. The feedback loop is slow, noisy, and rarely objective. A manager can do everything right and still have a quarter go badly because of factors entirely outside the code.

When we promote our best engineer, we are implicitly betting that excellence in one domain transfers to excellence in a largely disjoint one. Sometimes it does. But the bet is far weaker than our intuition suggests, and the cost of being wrong is paid by an entire team.

We Use Management as the Only Reward Worth Giving

Part of the problem is structural and entirely of our own making. In too many organisations, the only way to earn more money, more influence, or more recognition is to acquire direct reports. We have built a single ladder, and management is the only rung above a certain height. So a senior engineer who wants a raise, or simply wants to feel that their career is progressing, applies for the management track because it is the only track on offer.

This is a terrible mechanism for selecting managers. It optimises for people who want advancement, not for people who want to manage, and those are very different populations. The engineer who took the role for the title or the compensation will often discover, six months in, that they miss the work that made them good and resent the work that now fills their days.

The single most important question I ask a candidate for a first management role is not whether they can do the job. It is whether they would still want the job if it paid exactly the same as the senior engineering track. The hesitation in the answer tells me everything.

The Quiet Loss of Identity at the Keyboard

There is a cost to becoming a manager that we rarely name, and it is identity. A great engineer has spent years building a sense of self around being the person who can solve the hard problem. That competence is not just professional; it is personal. It is how they understand their own value. When they move into management, that source of daily affirmation largely disappears.

The new manager spends their day in meetings, writing performance feedback, mediating a disagreement between two teammates about an API contract, and they go home having shipped nothing they can point to. For someone whose entire professional self-worth was built on tangible output, this is genuinely disorienting. Some respond by clinging to the code, which we will come to. Others quietly conclude that they are bad at their job because they cannot see what they produced today.

I try to be explicit about this with anyone making the move. The dopamine of solving a problem yourself is being traded for the much slower, more diffuse satisfaction of watching people you developed succeed without you. That is a real trade, and not everyone wants to make it once they understand what it actually feels like.

The Inability to Let Go of the Work

The most common failure mode I see in technically excellent new managers is that they cannot stop doing the engineering. It is entirely understandable. They are faster than their reports. They see the cleaner solution immediately. When a teammate is struggling with a tricky concurrency bug, the manager knows they could fix it in twenty minutes, and the temptation to just take it is enormous.

But every time a manager takes the interesting work, several things go wrong at once, and they compound quietly over months:

• The team member is denied the chance to learn by struggling through it, so they grow more slowly and become more dependent.
• The manager becomes a bottleneck, because work now routes through the one person who has the least time to do it.
• The team learns that the hard, visible problems belong to the boss, which erodes their sense of ownership.
• The manager's actual responsibilities, the ones only they can do, get squeezed into the margins and done badly.

The discipline required here is counterintuitive. A good manager has to be willing to let the team produce a B-plus solution when they themselves could have produced an A, because the team's capability is the asset that compounds. The engineer who measures their worth by the quality of the solution finds this almost physically painful, and many never get past it.

Empathy Is a Discipline, Not a Personality Trait

There is a comfortable myth that some people are simply born with people skills and others are not. In my experience the truth is more demanding and more hopeful. Managing people well is a discipline that can be learned, but it requires deliberate practice in a set of activities that many strong engineers have spent their careers avoiding.

Reading the room in a tense meeting, noticing that a usually vocal engineer has gone quiet for three standups in a row, understanding that the real reason a project is stalled is an unspoken conflict rather than a technical blocker. These are observational skills, and they are not less rigorous than debugging. But they operate on a system that does not produce stack traces, and someone who has trained their entire mind to expect deterministic, inspectable behaviour can find human ambiguity genuinely frustrating.

The engineers who make the transition well are usually the ones who approach people problems with the same curiosity and humility they bring to an unfamiliar codebase. The ones who struggle tend to treat human behaviour as noise to be minimised rather than signal to be understood. That orientation matters far more than whether someone is naturally extroverted.

Avoiding Conflict Looks Kind and Is Quietly Cruel

A surprising number of technically brilliant people are conflict-averse, and management is, in large part, the professionalisation of difficult conversations. You have to tell someone their performance is slipping. You have to deny a promotion that someone feels they earned. You have to deliver a roadmap decision that disappoints a team that worked hard on the alternative. None of this is optional, and all of it is uncomfortable.

The new manager who avoids these conversations is not being kind, though it feels like kindness in the moment. They are allowing problems to fester, denying people the honest feedback they need to grow, and ultimately forcing a much harder conversation later when the situation has deteriorated past easy repair. I have seen managers let an underperformer drift for a year because they could not bring themselves to have the conversation, and the cost was borne by every other person on that team who picked up the slack.

Clear, direct, timely feedback delivered with genuine care for the person is one of the highest-leverage things a manager does. It is also exactly the skill that someone who has spent a decade preferring the company of compilers to the company of people is least likely to have practised.

From Depth in One System to Breadth Across Many

Engineering rewards depth. You go deep on a service, a language, a problem domain, and your value grows with how completely you understand it. Management inverts this. A manager has to hold a shallow but accurate model of many things at once: the technical state of several projects, the emotional state of several people, the political dynamics with adjacent teams, the priorities coming down from the business, the hiring pipeline, the budget.

For a mind trained to seek the bottom of a problem before moving on, this enforced shallowness is uncomfortable. The manager rarely gets to fully understand anything, because as soon as they begin to go deep on one issue, three others demand attention. The job is a constant exercise in deciding what is good enough to stop looking at, which is the opposite of the perfectionism that often defines a great engineer.

In a regulated fintech environment this tension is sharper still, because the manager must maintain enough technical fluency to judge risk, compliance, and architecture while no longer being close enough to the code to verify those judgements themselves. They have to learn to trust their people and ask the right questions rather than know all the answers. That shift, from knowing to trusting, is one of the hardest in the whole transition.

What I Have Learned to Do About It

The most important change I have made is to build a genuine technical track that runs as high as the management track, with equivalent compensation, equivalent influence, and equivalent respect. A principal engineer at our organisation can earn as much and shape as much as a senior manager. This single structural decision removes the pressure that pushes people into management for the wrong reasons, and it keeps our deepest technical talent doing what they are extraordinary at.

For those who do want to manage, I treat the transition as a real change of profession that deserves training, not a reward to be conferred and forgotten. I look for the early signals: the engineer who already mentors others without being asked, who writes the clear design document that brings a fractious team to agreement, who seems energised rather than drained by a long conversation about someone else's problem. I give them small, reversible doses of responsibility before any title changes, and I make it socially acceptable to step back to engineering if it is not the right fit.

That last point matters enormously. We have to dismantle the idea that returning to an individual contributor role after trying management is a demotion or a failure. It is a sensible course correction, and treating it as anything else guarantees that people who discover they hate the job will stay in it out of pride, doing damage to their teams and themselves for years.

Conclusion

Great engineers sometimes make poor managers for reasons that have nothing to do with intelligence or work ethic, and everything to do with the fact that we keep asking people to switch professions and then act surprised when the new profession requires different aptitudes. The skills diverge, the rewards are misaligned, the identity cost is real, and the daily work is almost unrecognisable. None of this is anyone's fault, but all of it is our responsibility to manage well. If we build honest dual ladders, select for genuine interest rather than ambition, train people for the actual job, and keep the door open in both directions, we get better managers, happier engineers, and stronger teams. The worst thing we can do is keep handing our best builders a job they never wanted and calling it a promotion.