Why Your Best Engineer Might Be Your Worst Manager Hire
Every team has that one engineer. The one who fixes the scary bugs, knows the whole system in their head, and ships twice as much as anyone else. When the manager role opens up, everyone already knows who’s getting it.
Six months later, something feels off. The new manager is in back-to-back meetings all day and still pushing code at midnight. PRs wait days for their review. One-on-ones keep getting cancelled. The team, which used to be fast, is now oddly slow.
And the engineer who used to love their job looks tired and a bit lost.
You didn’t just get a struggling manager. You also lost your best engineer. That’s a pretty expensive trade.
Why we keep doing it
Honestly, it makes sense on the surface. This person is the best at the work, the team respects them, and they know the system better than anyone. Who better to lead it?
There’s also a quieter reason. In a lot of companies, management is the only real way up. If you want a bigger title or a better salary after a certain point, you have to start managing people. So the promotion becomes a reward for being a great engineer, not a decision about who would be a great manager.
This isn’t just a tech thing. A study by Benson, Li and Shue looked at sales teams across 214 firms. The best salespeople were the most likely to get promoted into management. But on average, the stronger a new manager’s own sales record, the worse their team performed after the promotion.
That’s the Peter Principle in real data: people get promoted based on how well they did their last job, not on whether they’re suited for the next one.
It’s a completely different job
The biggest problem is that we call it a promotion, like it’s the same job but bigger. It isn’t. Almost everything about how you measure a good day changes.
The skills that made someone a great engineer, like going deep, owning the hard problem and being the person everyone asks, are often the exact habits that get in the way as a manager. Nobody tells them that on day one, so they keep doing what made them successful, and it slowly stops working.
Signs it’s going wrong
It rarely blows up all at once. It shows up in small, familiar ways.
The new manager still picks up the hardest tickets, because they’re faster than anyone else. Which is true, and also the problem. The team never gets the chance to grow into that work.
Code reviews turn into rewrites. Instead of explaining what could be better, they just fix it themselves. The engineer feels corrected, not coached, and stops trying the hard stuff.
They become the bottleneck. Every decision, every design, every release has to go through them. When they take a week off, the team more or less stops.
The people side gets pushed to the edges. One-on-ones get moved for “urgent” work. Feedback is either missing or comes out too blunt, because in their head the bar is their own level.
And they burn out. They’re doing a manager’s job during the day and their old job at night, and they’re not great at either anymore. Quite often they leave, and you lose both.
Two types I’ve seen again and again
Over the years, two patterns keep showing up for me.
The brilliant jerk
I’ve seen many examples of people who are really smart but just don’t listen. They’re usually right about the technical stuff, and they know it. But if you question their approach in a meeting, they get loud. Sometimes they literally shout.
After a few of those meetings, people stop disagreeing. Not because they’re convinced, but because it’s not worth the fight. Good ideas stay quiet, and the team slowly starts working around this person instead of with them. Eventually nobody wants to be on their team at all.
Get saurav omar’s stories in your inbox
Join Medium for free to get updates from this writer.
However smart they are, they’re not doing the team any good. They’re spoiling the culture, and that cost is bigger than whatever they ship.
The person who is everywhere
The second type is much nicer to work with, which is why it’s harder to spot. These are sensible, helpful people who try to solve problems for three or four teams at the same time. Every escalation comes to them. Every tricky decision waits for their opinion.
It feels great at first. But it causes two big problems.
First, nobody else grows. If one person always jumps in to solve the hard thing, the rest of the team never gets the chance to learn it.
Second, they become the bottleneck. Too many teams depend on them, so work piles up waiting for their time. When they’re on leave or stuck in another fire, everything slows down.
They’re everywhere, and because of that they’re nowhere. Spread across everything, they can’t go deep on anything. And that has a huge cost that rarely shows up in any review.
What to do instead
The fix isn’t “never promote great engineers.” Some of them turn into brilliant managers. The fix is to stop treating management as the default reward.
First, build a real path for engineers who want to stay engineers. Staff and principal roles should come with real money, real scope and real respect, not just a new title. If the only way to get a raise is to manage people, you’ll keep getting managers who never wanted the job.
Ask them if they actually want it. It sounds obvious, but a lot of people get promoted without anyone asking. And ask the deeper version too: “Do you want to spend most of your week on people problems instead of technical ones?”
Let them try it before it’s official. Give them a tech lead role, a small project with two or three people, or have them run hiring for a quarter. They’ll find out quickly whether they enjoy it, and so will you.
Make it okay to go back. If someone tries management and realises it’s not for them, moving back to engineering should be normal, not seen as failing. Otherwise people stay stuck in a job they don’t like because going back feels embarrassing.
And when someone does move, support them properly. Don’t just change the title and walk away. Give them a mentor, some training, and a manager who checks in on how the change is going, not just on delivery.
If you’re the one being offered the role
If you’re a strong engineer and someone just offered you a manager role, it’s flattering. It’s also okay to slow down before saying yes.
A few questions worth being honest with yourself about:
- When a teammate gets unblocked because of something you did, does that feel as good as shipping something yourself?
- Are you okay with most of your day being meetings, conversations and context switching?
- Can you watch someone solve a problem slower than you would, without taking over?
- Are you saying yes because you want the job, or because it’s the only way to grow here?
If the last one is the real reason, say that out loud to your manager. It might lead to a better conversation about the IC path than either of you expected.
To wrap up
Being a great engineer and being a great manager are both valuable. They’re just different jobs, and being good at one doesn’t mean you’ll be good at, or even enjoy, the other.
The companies that get this right stop asking “who’s our best engineer?” when a manager role opens up. They ask “who on this team already makes the people around them better?” Sometimes that’s the star engineer. Often it isn’t.
So look at your own team. If your best engineer got promoted tomorrow, would it be because they want to lead, or because there was nowhere else for them to go?
