Stop Promoting Your Best Engineers Out of Engineering
I’ve watched this happen so many times now. An org’s most talented engineer gets tapped for management. They stop coding. They start doing 1:1s, sprint planning, budget reviews. Within a year the team has lost its strongest technical voice and the engineer is miserable. Everyone loses.
I want to be clear – management is important. Great EMs are worth their weight in gold. This isn’t about management being bad. It’s about the assumption that management is the only path to more impact and more money for people who are really, really good at building things.
Classic Peter Principle: people get promoted to their level of incompetence. The engineering version is more specific: we take our best builders and promote them into a role where they don’t build anymore. We just assume that the skills that make you a great engineer – technical depth, systems thinking, attention to detail – will transfer to management. Sometimes they do. A lot of the time they don’t.
The skills that make a great manager are mostly orthogonal. Empathy, conflict resolution, organizational design, hiring judgment – you can be a world-class distributed systems engineer and have none of these. And that’s fine! But then we shouldn’t be surprised when the promotion doesn’t work out.
When you promote a strong engineer into a management role they don’t fit, three bad things happen at once. You lose a great engineer. Their technical output goes to near zero, and the institutional knowledge they carry gets stale as the codebase moves on without them. You get an okay-at-best manager. Harsh, but usually true. Someone who’s still figuring out management while simultaneously missing the work they used to love is not going to be great at either thing. Their reports feel it. And you signal to every other engineer that advancement means leaving the keyboard behind. The most ambitious people on the team look at that and think: the way to grow is to stop doing the thing I’m good at. That’s an insane incentive structure.
The answer is a legitimate IC leadership track – staff, principal, distinguished, whatever – that offers comparable pay, recognition, and influence to the management track. Some companies are starting to do this, but a lot of them are doing it badly. The titles exist but they’re decorative. There’s no real differentiation in scope or expectations.
A real IC track needs a few things. The comp has to be comparable – if your principal engineer makes significantly less than your director of engineering, your IC track is a participation trophy and everyone knows it. The scope has to be clear – “what does a staff engineer actually do?” needs a real answer, not hand-waving about influence. And there has to be actual organizational authority. IC leaders need to be in the rooms where technical decisions get made, with the standing to set direction and push back on bad ideas.
Stay in the codebase
There’s a related problem I want to call out, which is senior ICs who’ve drifted away from actual technical work. They go to meetings, review designs, give opinions. But they don’t write code. They don’t debug production issues. They don’t experience the same friction the rest of the team faces every day.
This is what I’d call the architecture astronaut problem. Without grounding in the day-to-day reality of building and operating systems, your technical judgment slowly rots. The best staff and principal engineers I know still write code regularly. Not as much as they used to, but enough to stay calibrated.
I try to keep at least 40% of my time on hands-on technical work. Not because I love coding (though I do), but because it keeps me honest. It’s easy to design systems on a whiteboard. It’s much harder to design ones that are pleasant to actually build, deploy, and operate. The only way to tell the difference is to do it yourself.
If you run an engineering org, take a hard look at your IC track. Is it real or is it decorative? Check your attrition data – how many senior engineers left for management roles at other companies because yours didn’t offer a real alternative? Invest in IC leadership development with the same seriousness you invest in manager development. And when a staff engineer’s design prevents a class of outages, celebrate that publicly. Make the multiplier work visible.
The companies that figure this out keep their best technical people. The ones that don’t keep losing them to management roles they never wanted, or to companies that actually value what they do.