Last updated: July 6, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
An engineering manager becomes the bottleneck when nothing ships without their review, their approval, or their opinion. The fix is not learning to move faster through the queue. It is moving decisions out of your head and into a system your team can run without you. Speed follows. It always does.
The most uncomfortable diagnosis I deliver is not about the code. It is about the person who hired me to look at the code. Something slowed down. Velocity stalled, releases got heavier than they used to be, and the leader wants me to find the technical reason a team of good engineers suddenly cannot seem to get anything out the door on time. More often than not, the real answer is standing at the front of the room. Nobody wants to say so out loud.
Here is the version I have said out loud to more than one very good leader. If you are the bottleneck, you are not leading. You are just a senior IC with a calendar full of one-on-ones.
That lands hard. It is usually true. And it usually describes someone working incredibly hard, which is what makes it so difficult to hear. The bottleneck is rarely the lazy manager. It is the diligent one. The leader who reviews every pull request, sits in on every design decision, and genuinely believes the quality bar depends on their eyes being on all of it. I see the same thing under a stalled team that is convinced it has a tooling problem. Most of the time it is a clarity problem, not a technology problem, and the leader is Layer 1 of it.
The Mirror Nobody Wants to Hold Up
An engineering leader is a bottleneck when the flow of work depends on their personal availability. Approvals wait for their inbox. Decisions wait for their opinion. Engineers reach the edge of their own authority and stop, idling until the leader frees them, which means the whole team can only ever move as fast as one very full calendar allows.
Nobody writes that on a status report. It hides. It hides because every single instance of it looks like responsibility. You did not refuse to delegate. You wanted a quick look first. You did not block the release. You only asked to be in the loop before it went out. Each moment feels like diligence. Each one is small. Stack a quarter of them together and it is a wall.
Here is the part that stings. If your best engineers are waiting for permission to make decisions, that is not a people problem. That is a you problem. I have watched whole teams get labeled slow, or junior, or checked out, when the real issue was a leader who had quietly trained them to wait. People adapt to their manager. Punish one independent call and you have taught the entire room to ask first next time, and they will, for years, long after you have forgotten the day you snapped at somebody for shipping without checking.
How to Tell If You Are the Bottleneck
You will not feel like a bottleneck. You will feel busy. And busy feels like the opposite of the problem, which is exactly why the diagnosis is so hard to accept from the inside of your own packed calendar. So do not trust the feeling. Trust the evidence. Here is where to look.
- Pull up last week’s calendar. Count the meetings that existed only so someone could get an answer that lived in your head and nowhere else. That number, in hours, is your bottleneck.
- Open your review queue. How many pull requests are waiting on you specifically, rather than on any competent peer? A queue with your name on every row is a design flaw, not a badge of honor.
- Ask the team one question you might not want the honest answer to. “What are you blocked on right now?” Then count how many of the answers are, when you strip away the polite phrasing, you.
- Look at cycle time. Find where work sits longest. If the longest wait in the whole pipeline is “pending your sign-off,” you have your diagnosis, and you did not need me for it.
The tell is almost never dramatic. It is the quiet gap between “the work is done” and “the work shipped,” and the name that keeps showing up inside that gap is yours. The table below is the version I keep coming back to. It maps the story we tell ourselves against what the team actually lives.
| What you tell yourself | What the team actually experiences |
|---|---|
| “I just like to stay close to the details.” | Nothing merges until you have personally looked at it. |
| “I see the whole picture, so it is faster if I decide.” | Five engineers sit idle while one decision waits in your inbox. |
| “I have an open-door policy.” | Your calendar is the critical path, and there is a line outside the door. |
| “I trust my team completely.” | They can tell you trust them to execute, not to decide. It is not the same trust. |
Why Good Leaders Turn Into the Bottleneck
It is almost always an accident of habit. You got promoted because you were an exceptional engineer, and the instincts that made you exceptional do not switch off the day the title changes. You still spot the cleaner solution. You still catch the edge case in review. So you keep doing the thing you are good at. Only now that thing sits squarely on the critical path of everyone else’s work.
There is a classic Harvard Business Review piece from Oncken and Wass called “Management Time: Who’s Got the Monkey?” that names the mechanism better than I can. Every time an engineer brings you a problem and you say “let me think about it and get back to you,” the problem, the monkey, hops off their back and onto yours. Do that forty times a week and you run out of time while your team runs out of work. They are not stuck because they are weak. They are stuck because you are holding all the monkeys.
The other driver is fear. Let me be honest about that one. Somewhere in the move from building to leading, a lot of us get quietly afraid of being fooled. If I am not in every review, how do I know it is good? That fear is real. It is also the exact instinct that, left unchecked, turns a strong engineer into a chokepoint sitting at the dead center of their own team’s flow. Staying close to the work is right. Standing in the middle of it is not. From the inside, those two feel identical. From the outside, they could not look more different.
The Real Cost of Your Approval Queue
You think your review gate is buying quality. Show me the data. Google’s DORA program looked at change approval across thousands of teams and found the thing most leaders do not want to hear. Heavyweight external approval, the change advisory board, the mandatory sign-off from on high, has a negative impact on software delivery performance. It does not lower the failure rate either. The gate does not make the work safer. It makes the batches bigger. It makes the releases rarer. And when a failure finally lands, it lands harder. Peer review and a little automation beat it on both counts.
Now sit inside that finding. When you are the approval, you are the change advisory board. A committee of one. And a committee of one with a fuller calendar than any real committee ever had. The cost is not only the days that work spends waiting on you. It is what the waiting does to the people doing the work.
I once watched three genuinely talented engineers leave a single team inside eighteen months. Not over pay. Not over the stack. They left because they spent their days executing decisions that were made for them, with no real room to own anything, and eventually a person who is good enough to have options will go use them somewhere that lets them decide. That is expensive twice. You lose the person, and you lose everyone who watched them walk and quietly updated their own math. Ownership is not a perk you hand out on good days. It is the reason strong engineers stay. At KORE1 the engineers we place hold a 92 percent retention rate at the twelve-month mark, and the placements that stick are almost always the ones where the person was hired to decide, not just to deliver.
Getting Out of the Way Without Losing Control
Stepping back is not stepping out. This is where leaders panic, because they hear “delegate” and picture abdication, standards collapsing, the whole thing they built running headfirst into a wall while they wave from a safe distance and pretend not to notice. That is not the move. The move is to replace yourself as the gate with a gate the team owns.
Start by writing down who decides what, because most teams never actually have. A staff engineer can pick the caching strategy without you. Two engineers can settle a naming argument without dragging it onto your calendar. A few years back, one of my engineers swapped out a caching layer in a way I would not have chosen, did not run it past me first, and shipped it. It was the right call. I had been wrong, and the only reason I ever found out I was wrong is that I was not standing in the way of him being right. Reversible decisions, the kind you can undo in an afternoon, should almost never reach your desk. Save yourself for the one-way doors.
Change what you do inside a review, too. Stop being the person who says yes. Be the person who set the context so clearly, so far up front, that the team already knows what yes looks like before they come find you. Define done. Write the priorities down where everyone can see them, not in some hallway conversation that never makes it into Jira. Then build an operating rhythm that catches the problems, so that you do not have to personally catch every last one of them yourself, by hand, at the worst possible moment. That is the operational discipline that protects velocity, and it is the exact opposite of you standing in the doorway.
One rule holds all of it together. Stay off the critical path. You can stay deeply technical, read the code, keep your instincts sharp, and still never be the reason a change cannot ship without you in the building. That single distinction is the whole game, and it is the same reason the strongest leaders I know stay hands-on without micromanaging. Follow the work. Judge the work. Never become the work’s single point of failure.
Sometimes the Bottleneck Is a Hiring Problem
Now the honest caveat. Sometimes you cannot get out of the way because the person on the other side genuinely cannot carry the decision yet. That happens. It is real. But it is a completely different problem than the one you have been solving, and treating a capability gap on your team as though it were a delegation habit of your own just buries the actual issue under another quarter of you doing everyone’s thinking for them.
If you are the gate because you do not actually trust the judgment on your team, you are not looking at a delegation failure. You are looking at a hiring gap, or a coaching gap, and parking yourself in the middle of the work just hides it for another few months. The leaders who escape the bottleneck almost always did two things at the same time. They built the system that lets decisions live at the right level, and they made sure the people at that level could genuinely be trusted with the call. That second part is a hiring problem. It is one we spend our days on. Some teams need engineers who show up ready to own a decision instead of waiting around for one. That is the profile our engineering staffing practice screens for. It holds whether the seat is a direct hire or a senior software engineer on a team that needs judgment far more than it needs another set of hands.
Straight Answers for the Leader Who Suspects It Is Them
How do I know if I am the bottleneck or just doing my job?
Run the calendar test. If most of last week’s meetings existed so someone could get an answer that only you had, you are the bottleneck, not the manager.
Doing your job looks like setting direction and clearing obstacles. Being the bottleneck looks like being the obstacle you keep clearing. The difference shows up in the data, not in how hard you feel like you are working, and the bottleneck almost always feels like very hard work from where you are sitting.
How do I step back without watching quality fall apart?
Replace yourself as the gate with a gate the team owns. Peer review, a written definition of done, and clear decision rights catch more than one tired leader ever will.
The research backs this up. DORA found that peer review paired with automation beats heavyweight sign-off on both speed and stability. Your eyes were never the thing keeping quality high. The system around the work was, on the days you actually built one.
I work in a regulated industry. Does not compliance require my sign-off?
Compliance requires a control, not a person. Write the control down, automate what you can, and make it traceable for an auditor. Your calendar is not a control.
I have spent most of my career in mortgage tech and fintech, so I am not waving away the audit. In a regulated environment the gate has to exist. It just does not have to be you, personally, reading every change at midnight. A documented, enforced, automated control satisfies an auditor far better than a busy human who is the single approver and, conveniently, also the single point of failure.
What happens when I delegate and someone makes a call I would not have made?
Ask for the reasoning before you judge the result. Most of the time it holds up and you learn something. When it does not, you coach.
You do not run a postmortem on one honest miss. A decision that lands differently than yours is not automatically the wrong decision, and if it was reversible, the cost of being wrong was a few hours. The teams that move fastest are the ones where engineers make calls at their level without escalating everything upward, and that culture does not survive a leader who punishes the first independent decision they see.
Is this a management problem or a hiring problem?
Usually both, and they feed each other. If you cannot trust the team to decide, sometimes the system is broken and sometimes you hired for execution when the role needed judgment.
Fix the system first. It is cheaper and faster. If decisions still cannot live at the right level once the system is sound, you are looking at a gap in the people, and no amount of you standing in the doorway will close it. That is the point where the answer stops being process and starts being who is actually on the team.
The Test That Tells You the Truth
Take two weeks off and actually disconnect. No peeking at the review queue. No answering the “quick question” texts from the beach. Then look hard at what happened while you were gone. If the team kept shipping, you built something real. If everything stopped and waited for you, you did not build a team. You built a dependency. And the dependency is you. That is a hard sentence. Sit with it anyway.
The best thing I ever did as a leader was make myself less necessary to the daily work, deliberately, a little more every month, until the org hummed along without me anywhere near the room. It felt like losing control for about four weeks. Then it felt like the first time I had actually been leading instead of just being needed. If you want to talk through where your own bottlenecks are hiding, reach out to KORE1’s engineering hiring team or connect with me on LinkedIn. I answer the honest questions.
Related reading: The Clarity Stack: 3 Reasons Engineering Velocity Stalls, Why the Best Engineering Leaders Stay Technical, and Operational Discipline Is Not Bureaucracy.