Engineering bottlenecks are usually not where the team thinks they are. The loudest complaints are about meetings; the actual bottlenecks are often code review latency, decision wait time, or a single overloaded engineer. Finding the real bottleneck takes about two weeks of structured measurement and produces clearer answers than any retrospective.
What looks like a bottleneck and isn't
The team will tell you: too many meetings, not enough headcount, tooling is bad. These are real, but they're symptoms, not bottlenecks. The bottleneck is the specific step in the workflow where work piles up.
To find it, follow the work, not the complaints.
Step 1: map the workflow stages
Sketch the actual stages work passes through, end to end. Common pattern: ticket → design → implementation → review → QA → deploy. For each stage, note: how long does work typically sit there, and how many items are in flight at once.
The stage where work sits longest is the bottleneck. Not the stage where work feels hardest.
Step 2: measure for two weeks, lightly
Don't build a dashboard. Just pull, manually, the last 20 tickets and time-stamp when each stage started and ended. Two hours of work; produces clearer signal than any tool.
Look for the stage with the widest distribution: meaning some items pass in hours, others sit for days. Wide distributions reveal where bottlenecks form intermittently.
Step 3: find the human bottleneck
Inside the slow stage, name the single person or role that work routes through. PR review bottlenecks often resolve to one or two senior reviewers. Decision bottlenecks often resolve to one EM. Deploy bottlenecks resolve to one ops engineer.
Naming the bottleneck is not blame. It's diagnosis. The bottleneck person is usually overloaded and underdiscussed.
Step 4: distribute the bottleneck
The fix is almost always one of:
- Train more people to handle the bottleneck step. Common for senior PR review.
- Delegate authority so the work doesn't have to route through the bottleneck. Common for decisions.
- Automate the step if it's mechanical. Common for deploys.
- Cut the step if it's not adding value. Sometimes the step exists out of habit.
See Bottlenecks in the Record
StandIn surfaces handoff gaps, decision delays, and shadow authority directly from declared state, no surveillance, just structure.
See the Workflow →Step 5: re-measure after a sprint
Pull the next 20 tickets after the change and time-stamp the stages again. The bottleneck either moved to a different stage (success: find the new one and repeat) or didn't move (the fix didn't work: try another approach).
This is the loop. Bottleneck-fixing is iterative, not one-shot.
Watch for political bottlenecks
Some bottlenecks aren't workflow. They're people unwilling to delegate, or processes nobody questions because someone senior built them. These are harder. The diagnosis is the same; the fix requires conversations, not workflow changes.
Don't pretend these aren't real. They cost the team as much as workflow bottlenecks; they're just less measurable.
Common failure modes
Failure: optimizing the wrong stage. Speeding up implementation when review is the bottleneck just produces more PRs sitting in queue. Find the bottleneck first; optimize it.
Failure: blaming the bottleneck person. They're usually responding rationally to incentives. Change the incentives: distribute the work, not the blame.
Failure: solving bottlenecks with surveillance. Tracking individual engineer output is the wrong instrument. Measure stages, not people.
What to do tomorrow
Pull the last 10 tickets your team shipped. For each, note the time spent in each stage. The variance will tell you where to look next. Two hours of work; usually finds the bottleneck. Then propose one structural change in the next sprint.
Frequently asked questions
How often should I look for bottlenecks?
Quarterly is enough. Monthly is overkill: bottlenecks don't shift that fast. Annual misses too many.
What if the bottleneck is my EM or me?
Then you've found a high-leverage fix. Delegate explicitly, define authority maps, force decisions to happen lower in the org. Most leaders are bottlenecks they didn't realize they'd become.
Can engineering bottlenecks be people problems instead of process problems?
Sometimes, when one engineer's work quality is causing rework, for instance. But the more common case is good engineers stuck in bad workflows. Diagnose process first; conclude people only after the workflow fix doesn't help.
Parker Miller
Founder, StandIn
Parker Miller founded StandIn. He writes about coverage, handoffs, and what it takes for software to answer for a team from what people actually wrote down.
More about StandInExecutives had assistants. Everyone else had an out-of-office.
Give your whole team the coverage that used to stop at the corner office.
Keep reading
- How to Know if Your Engineering Org Has a Continuity ProblemA continuity problem in engineering is invisible until someone leaves. Ten symptoms that surface it early, and what to do once you see them.
- How to Reduce Engineering Meeting Load by 60%60% meeting reduction is achievable in one quarter without losing alignment. The four moves that produce most of it — and what to replace meetings with.
- 15 Things Great Engineering Managers Do Every WeekGreat engineering managers maintain specific weekly habits. Here are 15 that distinguish the managers whose teams ship from the ones whose teams just look busy.
- From the productYour first 30 daysThirty days. No heroics. See what the first month looks like for a team like yours.