For a long time, I thought being a good lead meant being involved in everything. Every pull request, every architecture decision, every "quick question" in the team chat — I wanted my hands on all of it. I told myself this was about quality. Looking back, it was mostly about control, and it nearly broke my team.
This is the leadership mistake I'm least proud of, and the one I learned the most from: I became the bottleneck.
The story
When my team was small, being in everything actually worked. Five engineers, one of me, and I could review every change the same day. People felt supported. Things shipped. I got praised for being "hands-on," and I leaned into it harder.
Then the team grew. Ten engineers, then more. The same habits that made me look great at five people started quietly suffocating everyone at fifteen. Pull requests sat for two days waiting for my review. Decisions stalled because everyone had learned to wait for me to bless them. Engineers stopped proposing ideas because they knew I'd redo it my way anyway. The team's speed was capped at exactly one person's capacity — mine — and I was exhausted defending that ceiling.
The moment it became undeniable was a release that slipped a week. When I dug into why, every delay traced back to something waiting on me. Not on a hard technical problem. On me. I was the single point of failure in my own team, and I'd built it on purpose without realizing it.
What hurt more was a quieter signal. A strong engineer told me, kindly, that he'd stopped suggesting improvements because "you usually have a way you want it done." He wasn't angry. He'd just adapted to me. That sentence sat with me for weeks. I had trained capable people to be passive.
The turn
Fixing it was harder than causing it, because the problem wasn't a process — it was my ego dressed up as standards. I had to accept a few uncomfortable things.
First, that "done differently than I'd do it" is not the same as "done wrong." A lot of my reviews weren't catching bugs; they were enforcing my personal taste. That's not quality control, that's a preference tax, and the team was paying it in time.
Second, that my job had quietly changed and I hadn't. I was still measuring myself by how much I personally touched, when I should have been measuring how much the team could do without me touching anything.
So I started letting go on purpose. I picked two senior engineers and made them owners of whole areas — not "do the work and I'll review it," but "this is yours, you decide, you're accountable." The first few weeks were genuinely hard. They made calls I wouldn't have. Some were better than mine. A couple were worse, and I had to sit on my hands and let small mistakes happen so people could learn from them instead of from me.
A team that can only move as fast as its leader isn't a team. It's a leader with very expensive assistants.
I also changed what I reviewed. Instead of every line, I reviewed the things that were genuinely hard to reverse — data models, public APIs, security boundaries, big architectural bets. The reversible stuff, I let the team own. The blast radius of a bad button color is small. The blast radius of a bad schema is not. I learned to spend my attention where mistakes were expensive, and to stay out of where they were cheap.
Key lessons
Involvement doesn't scale; judgment does. Your value as a leader isn't how many decisions you make — it's how many good decisions happen without you. Past a certain size, being in everything is the same as blocking everything.
Taste is not quality. Before you send something back, ask whether it's actually wrong or just different. Most rejections I used to make were the second kind.
Review by blast radius. Guard the decisions that are hard to undo. Let the team own the ones that are easy to undo. This single reframe freed up most of my time.
Passive teams are usually made, not hired. If smart people around you have gone quiet, look at yourself first. People stop contributing when they learn it doesn't matter.
Letting people make small mistakes is an investment. It feels like lowering the bar. It's actually how you raise people who don't need you.
Action steps
If you suspect you've become the bottleneck — and most hands-on leads are, at some point — try this:
- Audit your delays for a week. For every blocked task, ask "what is it waiting on?" Count how many trace back to you. The number is usually higher than you'd guess.
- Name real owners, not helpers. Give specific people end-to-end ownership of an area, including the authority to decide. Say it out loud so the team knows.
- Define what only you should touch. Write down the small set of decisions that truly need you (irreversible, high-risk). Everything else is delegable by default.
- Change your review habit. Stop commenting on style and preference. Comment on correctness, security, and things that are hard to change later.
- Ask your team a hard question. "Where do I slow you down?" Then don't get defensive about the answer. The fact that they'll tell you is the whole point.
Final thoughts
The team got faster the moment I got out of the way — not a little faster, dramatically faster. Things shipped that I never saw until they were live, and they were good. Engineers who'd gone quiet started proposing ideas again. And strangely, I enjoyed the work more, because I was finally doing a leader's job instead of doing five engineers' jobs slowly.
Being the bottleneck feels like dedication from the inside. From the outside, it's a ceiling you've placed on everyone around you. The best thing I ever did for my team was admit I was that ceiling — and then get out of the way.