Someone on your team is absolutely brilliant. They ship clean code. They solve hard problems. They're the first person everyone goes to when things break at 2am.
So you promote them.
Three months later, the team is disengaged, delivery has slowed, and your best engineer is drowning in meetings they hate and performance reviews they don't know how to write.
You didn't reward someone. You sabotaged your business... twice.
We've Confused Reward With Role
Here's what most organisations do: when an engineer is outstanding, the instinct is to promote them into management. It feels like recognition. It feels fair. It's also completely wrong.
The skills required to be a brilliant individual contributor, things like deep technical knowledge, pattern-matching, and solo problem-solving, differ entirely from the skills required to manage people. Research from the Institute for Strategy and Complexity Management is direct about it: these skill sets are "diametrically opposed."
The best coders work with deterministic systems. Write the right code, get the right output. Management is the opposite. People are unpredictable. Progress is slow and hard to measure. The feedback loop is months long, not milliseconds.
When you force a technical mind into a human systems role without real preparation, something breaks. The engineer fails to transition. The team suffers under someone learning on the job. And the organisation loses the one thing it was counting on... the technical output.
It's not even a new observation. Laurence J. Peter described it in 1969 in The Peter Principle: "In a hierarchy, every employee tends to rise to their level of incompetence." We've known about this for over fifty years. We're still doing it.
What Google Spent Years Proving
Google ran a years-long internal study called Project Oxygen to understand what makes managers effective. They identified eight key behaviours.
Technical expertise ranked last.
Dead last.
The top two behaviours were being a good coach and empowering the team rather than micromanaging. These are skills built through practice, feedback, and people experience... not through being the best in code review.
There is also the question of whether we're good at predicting who will make a great manager in the first place. Economist Daniel Kahneman studied this directly with the Israeli military, testing soldiers over two weeks to predict future leadership performance. His conclusion: the forecasts were "largely useless." Google's own internal research found zero correlation between their standard evaluations and long-term leadership performance.
Yet here we are, still promoting on the basis of the skill scoring lowest and relying on intuition research tells us doesn't work.
The Numbers Are Ugly
I've spent years managing engineering teams and mentoring individual contributors into leadership roles at companies like Curve. What I've seen matches what the data says.
According to Gallup research, 82% of companies pick the wrong manager every time they fill a management role. Not occasionally. Every time. Only one in ten people has high natural talent for management.
The CEB puts the new manager failure rate at 60% within the first twelve months. For individual contributor-to-manager transitions specifically, humanr.ai estimates the failure rate between 40 and 50% within eighteen months.
My own research into bad management found 99.5% of survey respondents said they've experienced one or more types of bad boss at some point in their career. Not most. Not some. Near enough everyone. Many of those bad bosses were, once, perfectly good engineers promoted beyond their preparation.
Gallup puts the cost at $360 billion per year in the US alone, in lost productivity and turnover. A single bad manager placement generates up to $2 million in losses when you factor in replacement costs and lost product velocity.
You're Paying Twice
Here is what most organisations don't track: when you promote your best engineer into management and it doesn't work, you pay twice.
First, you lose a high-performing individual contributor. An engineer spending 80% of their time on management tasks is no longer doing engineering. The technical output you relied on is gone.
Second, you now have a struggling manager. The team loses direction and confidence. Delivery slows. Good people start looking elsewhere.
Justin Leader, CEO of Human Renaissance, put it plainly: "You traded a known asset (high-velocity code output) for an unknown liability (untested management capability)."
There's also a third cost, one even less visible. Research published in Management Science in 2025 by Brittany Bond at Cornell found high performers passed over for recognition are at least 34% more likely to leave voluntarily within eighteen months. So if you don't promote your best engineer, they leave. If you promote them badly, both they and the team suffer.
This is the trap. Organisations walk into it every single time.
What Works in Practice
At Curve, I mentored seven engineers into leadership roles. Not all of them went into management. The distinction mattered enormously.
The engineers who became great managers weren't the most technically brilliant. They were the ones already curious about people, asking questions in one-to-ones, noticing when teammates were struggling, talking about team delivery as something shared rather than their own output.
The technically brilliant engineers who stayed as individual contributors didn't get less recognition. They got senior individual contributor roles with real seniority, real pay, and real influence, without anyone forcing them into work they'd hate doing.
I've written about the patterns behind great and bad leadership in Bad Bosses Ruin Lives, and the same structural failure shows up repeatedly: organisations promote on technical output, skip leadership development, and then wonder why engagement drops and good people leave.
The answer isn't to stop promoting engineers. The answer is to build two tracks.
Two Tracks, Not One Ladder
The traditional career ladder looks like this: junior engineer, engineer, senior engineer, tech lead, manager, senior manager. Leadership is the only path upward.
This is the design flaw.
A principal engineer should have the same seniority, pay, and organisational authority as an engineering manager. The path to the top of your organisation should not require anyone to stop doing the work they're brilliant at.
Companies doing this well include Google (with its Staff, Principal, Distinguished, and Fellow individual contributor tracks), Spotify, and a handful of scale-ups I've watched closely. They recognised the core problem: if the only way up is through management, you keep promoting the wrong people.
Build a technical leadership track. Invest in it properly. Pay it properly. Respect it properly. Make it a genuine path to the top, not a consolation prize for someone who didn't want to manage people.
Three things to do now:
- Audit your current ladder. Is management the only route to senior seniority and senior pay? If it is, fix the ladder first.
- Ask the question directly. Before promoting anyone into management, ask them: do you want to manage people, or do you want this title and salary? Those are different things. The conversation is worth having.
- Invest in preparation. If someone does want to move into management, don't throw them in cold. Coaching, mentoring, structured transition time... the failure rate drops significantly when organisations treat first-time management as a skill to develop, not a reward to hand out.
The Question Worth Asking
Before your next senior promotion, ask yourself: does this person want to manage people, or do they want the salary and the title?
Those are not the same thing. The answer to the question is worth more than all their code review history combined.
The best engineering organisations I've seen don't promote their best engineers to get them out of the way. They build systems where brilliant engineers stay brilliant, and where the people who want to lead people get the development first, not the job title.
If you want to dig into building the kind of engineering culture where both tracks thrive, Step It Up HR is where I write about exactly this. The leadership patterns I cover there apply whether you're in HR, engineering, or somewhere between the two.