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.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.