I’ll admit something that isn’t a great look for a post filed under management: I never much liked managing. I came up as a hands-on engineer, I liked the code, and when I ended up leading people my instinct was to stay as close to the code as I could. That felt like leadership. I was in the trenches, doing the hard work alongside everyone.
It took me longer than it should have to notice that I wasn’t leading the team so much as I was the thing the team kept getting stuck behind.
You Become the Bottleneck by Being Good
The uncomfortable part is that you don’t earn this by being bad at your job. You earn it by being good at it.
Your review is the most thorough, so every PR waits for your eyes. You’re the fastest on the genuinely hard problems, so the hard tickets quietly route to you. You hold the most context, so every real decision pauses until you’ve weighed in. None of those moments feel like control. Each one feels like helping, like being the engineer who cares most. Add them all up across a quarter and you are the single point of failure for a team that cannot move any faster than you can personally pay attention.
That’s the trap for anyone who leads from a strong-IC background. The very skill that got you the role, being the best hands-on engineer in the room, is the thing that makes you the bottleneck once the room is yours to lead.
Building Trust Into How the Work Runs
The advice everyone gives is “trust your team,” and it’s correct and almost useless as stated, because it sounds like a feeling you decide to have one morning. It isn’t. Trust is something you build into how the work actually runs.
It means making ownership explicit and genuinely end-to-end: this is yours, the decisions inside it are yours, not yours-pending-my-approval. It means letting people make calls you would have made differently, and sitting on your hands while they do. The hardest single rep, the one I kept failing, is not fixing it in review when it’s good enough but not how you’d have done it. Because the alternative, where everything meets your bar only because you personally touched it, gives you a team whose ceiling is your own attention. And your attention doesn’t scale, and it needs to sleep.
A lot of this is really about decisions, and where they queue. A leader who quietly becomes the approver on every choice is the same anti-pattern I wrote about from the other direction in Most Meetings Are a Symptom: a decision with no clear owner doesn’t get faster by routing through you, it just makes you the queue. Pushing the decision to the person who owns the work is how you stop being the queue.
“Get out of the way” is the shorthand, but it is not the same as abdication, and that distinction is the whole game. I’ll come back to it.
The Bottleneck Audit
If you want to know whether this is you, the symptoms are not subtle once you look:
- PRs sit in review because they’re waiting specifically on you.
- Decisions queue up for your input rather than getting made by the people doing the work.
- The hardest tickets land on your plate by default, every sprint.
- Standup is mostly a list of people blocked on something you owe them.
But the cleanest test is the simplest one: what happens when you take two weeks off? If the work keeps moving, you’ve built a team. If it quietly piles up waiting for you to get back, you’ve built a dependency on yourself and been calling it leadership. I’ve been on the wrong side of that test, and the vacation where everything was exactly where I left it was not the relief I expected. It was the bug report.
When Getting Out of the Way Is the Wrong Call
“Get out of the way” is good advice that becomes bad advice the moment you apply it uniformly, so a few honest limits.
Stepping back from someone who genuinely can’t execute yet isn’t trust, it’s neglect, and it sets them up to fail in public. Trust is calibrated to the person and the moment. A junior needs scaffolding, and the job is to remove it deliberately over time, not to pretend it was never needed and call the absence empowerment.
Some decisions are also one-way doors, and some domains punish “let them be wrong and learn.” In payments, a mistake doesn’t cost a redo, it costs customers and money, and there being a careful gate on certain changes is the correct call, not a failure of trust. The actual skill is sorting the reversible, cheap decisions, where you should delegate freely and let people surprise you, from the irreversible ones where staying involved is the responsible thing to do.
And the honest personal cost, the one the genre never mentions: getting out of the way means doing less of the part you probably got into this for. For a hands-on engineer that’s a real loss, not a tidy win, and pretending otherwise is how you end up quietly sneaking back into the critical path.
Staying Technical Without Being Indispensable
Here’s the resolution I eventually made peace with. I didn’t want to become a hands-off manager who only does process, and that turned out to be fine. I still wanted to be in the code.
The fix isn’t doing less work, it’s being indispensable in fewer places. You can stay technical, keep writing code, keep your hands genuinely dirty, as long as nothing critical stops the day you don’t. Be the person who sets the context and clears the blockers, not the person every path runs through. The goal is to make yourself the engineer the team is glad to have, not the one they’re structurally unable to proceed without.
The question I’d actually put to yourself isn’t whether your team trusts you, it’s whether they need you, and for what. If you stepped away for two weeks, the things that kept moving on their own aren’t your job; the things that quietly stacked up on your desk waiting for you to come back are. The work of leading is making that second list shorter.