There is a decision I have watched founders and executives make over and over again, with the best intentions and genuinely painful results.
They take their best technical person — the engineer everyone respects, the specialist who always has the answer — and they promote them into management. But because they need the output, because replacing that expertise feels expensive, they tell this person to keep doing both. Lead the team. Stay hands-on. Keep producing.
This is not a promotion. It is a trap.
The Pride Problem
Technical experts build their identity around mastery. Being the person with the right answer is not just a job description — it's a self-concept. It's the thing that got them recognized, promoted, and respected. And when you ask them to become a manager, you are asking them to walk away from the very thing that made them feel valuable.
What actually happens is simpler and more human than most organizations want to admit: they don't walk away. They can't. So they stay hands-on, because that's where their confidence lives. When someone brings them a problem, they solve it. When someone makes a mistake, they fix it. When a junior team member is stuck, they take the keyboard.
It feels like helping. It isn't.
Every time the manager jumps in, they teach the team one thing: don't bother thinking, just wait for the manager to do it. Over time, the team stops trying to figure things out. Why would they? The answers always come from the top.
The Emotional Toll Nobody Talks About
What makes this trap particularly cruel is that it punishes the person it's supposed to reward.
The technical expert who became a manager is now caught between two worlds. When they're in leadership meetings, they feel guilty about not doing "real work." When they're heads-down in the code or the data, they feel guilty about ignoring their team. They're failing at both roles, and they can't figure out why, because they're working harder than they ever have.
By month six, the resentment sets in. Not loud resentment — quiet, grinding resentment. They're working sixty-hour weeks maintaining their technical output while their team feels neglected and stagnant. The best people on their team start looking elsewhere, because they came to work for someone who would help them grow, and what they got was a supervisor who just takes the keyboard away when things get hard.
The manager doesn't understand why good people are leaving. They're doing everything right, technically. They just don't see that the job has changed.
What Founders Are Actually Optimizing For
Founders make this mistake because they're optimizing for speed. Who can solve the problem right now? Who is the fastest path from stuck to done?
But that's the wrong question. The right question is: who can build a team that solves problems without me?
Those are entirely different goals, and they require entirely different people doing entirely different things. A great individual contributor asks "how do I solve this?" A great leader asks "how do I build a team that can solve this, and the next thing, and the thing after that?"
You cannot do both at scale. At some point, every growing organization has to make a choice about whether its best people are going to be great individual contributors or great leaders. Asking them to be both — without giving them the support to actually make the transition — is just asking them to do two jobs poorly.
What Actually Works
Stop asking your technical experts to stay hands-on when you promote them. If you need their expertise to remain accessible, give them a path that doesn't require them to manage people — a principal engineer track, a staff architect role, something that honors what they're actually good at.
If you genuinely want them to lead, give them the support to learn how. Not a one-day management training seminar. Real coaching, real feedback, real time to figure out that their job has fundamentally changed.
The manager who stops jumping in and starts asking "what do you think we should do?" will initially feel like they're losing productivity. They're not. They're building something that compounds. Teams that learn to think for themselves get faster, not slower. Decisions get made at the right level. Problems get solved without waiting for the bottleneck to clear.
You might lose one person's individual output for a few months. In exchange, you get the collective capability of a team that doesn't need a hero anymore.
That's how you scale without breaking your people.
If this pattern sounds familiar — whether you're the manager caught in the trap or the founder who put someone there — I'm happy to have a real conversation about what it looks like to change it. Schedule a call or reach out directly.