I've watched it happen a dozen times.
Your best engineer ships feature after feature. They debug problems nobody else sees coming. The team respects them. Leadership notices.
So you reward them. You make them a manager.
And within six months, you've lost your best engineer... and gained your worst manager.
The Peter Principle Is Thriving in Engineering
Laurence J. Peter named this phenomenon back in 1969. People get promoted based on their performance in their current role, not their ability to do the next one. They rise until they reach a role they're bad at. Then they stay there. The concept has its own Wikipedia page, and researchers who simulated it even won an Ig Nobel Prize for proving random promotions outperform merit-based ones in Peter Principle organisations.
In software engineering, this pattern is everywhere.
Gallup's research puts hard numbers on the problem. Only 1 in 10 people naturally possess the talent to manage others. Companies pick the wrong person for management roles 82% of the time.
82%.
Think about what this means. In a company with 50 managers, 41 of them should not be doing the job they're doing. Not because they're bad people. Because they were promoted for the wrong reasons.
Managers account for 70% of the variance in employee engagement. Half of all employees have left a job specifically to escape their manager. US companies spend $1.5 billion a year on engagement programmes, and average engagement levels haven't moved in 20 years.
My own research backs this up. In surveys I've run through Step It Up HR, 99.5% of respondents said they've had one or more types of bad boss. Not 50%. Not 80%. Ninety-nine point five percent.
The system is broken. And the engineering industry keeps feeding the broken system by turning great coders into reluctant managers.
The Double Loss
Here's what happens when you promote your best engineer into management.
Loss number one: You remove your strongest technical contributor from the work they do best. The person who spotted architectural flaws before they became production incidents. The person who mentored junior developers by sitting next to them and pairing on hard problems. The person whose code reviews taught the whole team something. Gone. Replaced by someone less skilled, or by nobody at all.
Loss number two: You install a manager who doesn't want to manage. They sit in meetings wishing they were coding. They struggle with conflict resolution because they've spent a decade solving problems with logic, not emotions. They avoid difficult conversations about performance. They micromanage the technical decisions they used to own, because it's the only part of the job they understand. Their team feels the tension. Morale drops. Your best people start looking elsewhere.
I've lived this. I've been the engineer who got promoted. The first time I became a CTO at a startup, I didn't want the title. They needed it for their fundraising deck. As the tech founder, you're the "CTO" with invisible quote marks. And the skills required to be a real CTO... strategic business leadership, managing managers, budgets, cross-department communication... none of those are the skills you got hired for.
The transition from engineer to engineering manager requires learning to let go of writing core code, negotiating with product managers, building cohesive teams, and handling conflict. Those are entirely different muscles. And the higher you go, the further you get from the work you loved. By the VP of Engineering level, coding is a crime. You have more important things to do.
Management as the Only Way "Up"
The root problem is simple. Most companies have one ladder. Write code, become a senior engineer, then... manage people. There's nowhere else to go.
If you want a raise, a better title, more influence... you take the management job. Even if every fibre of your being says you'd rather be designing systems.
Engineers are logical. They look at the incentive structure. Higher pay goes to managers. More decision-making authority goes to managers. The org chart points up through management. So they take the management role. Not because they want to manage. Because the system leaves them no other choice.
This is organisational design failure. Not a personal failing.
Build Real Career Tracks
The fix isn't complicated, but it does require organisations to rethink what they value.
Pat Kua's Trident Model describes three distinct career paths:
1. Management Track — 70-80% of time spent on people, organisation, and enabling others. This is for people who genuinely want to develop and support teams.
2. Technical Leadership Track — 70-80% of time on technical vision, risk management, architecture decisions, and growing team knowledge. Leadership without people management.
3. Individual Contributor Track — Deep specialist work. Execution, expertise, and impact through technical depth.
All three tracks should reach the same level of seniority, compensation, and respect. A Staff Engineer should earn as much as an Engineering Manager. A Principal Engineer should sit at the same table as a VP of Engineering.
The traditional dual-track model (IC vs Manager) is a step in the right direction, but it often fails. As Kua points out, the IC track tends to overemphasise individual contribution when most organisations need technical leadership. The Trident Model fills the gap by recognising the role of the person who shapes architecture, sets technical direction, and mentors... all without managing anyone's holiday requests.
What Good Looks Like
Before promoting anyone into management, ask these questions:
Do they want it? Not "would they accept it if offered?" Do they actively seek out people problems? Do they volunteer to run retrospectives, mentor others, and mediate disagreements? Or do they do those things reluctantly because nobody else will?
Do they already manage? The best managers are doing the work before they get the title. They're coaching peers. They're having tough conversations. They're thinking about the team's health, not their own output.
Would you trust them with a firing? Management isn't all team lunches and stand-ups. Sooner or later, a manager has to deliver bad news. Have a performance conversation. Let someone go. If you wouldn't trust this person with the hard parts, don't hand them the role.
What will you lose? Be honest about the cost. If promoting your best architect into management means your system design quality drops, the trade-off has to be worth it. Often, it isn't.
Stop Calling It a Promotion
Management is not a step up. It's a step sideways into a different profession.
An engineer who becomes a manager isn't doing the same job with more authority. They're doing a completely different job. The skills transfer is minimal. The daily experience changes entirely. The feedback loops are different. The satisfaction comes from different places.
The best thing you do for your strongest engineer might be to give them a raise, a Staff Engineer title, and the authority to shape your technical direction... while keeping them far away from one-on-ones and performance reviews.
Build three ladders. Pay them equally. Respect them equally. And stop assuming "up" means "managing people."
Your best engineer deserves better than a job they'll hate.