The quiet bottleneck

There's usually one person on every engineering team who isn't officially blocking anything — and yet, somehow, nothing moves without them.

They're in every significant PR review. Their name appears on most design docs. When an incident gets thorny, someone always pings them first. They're not on any critical-path diagram. They're just... everywhere.

This is the quiet bottleneck. And by the time a team names it, the coordination tax is already substantial.

Quiet bottlenecks don't form because someone is territorial. They form because they're competent, available, and trustworthy — and teams optimize for low friction in the short run.

A junior engineer isn't sure about a database migration strategy. Rather than read the ADRs and take a swing, they ping the person most likely to give a correct answer fast. That person responds. The junior ships. Both feel good about it. Multiply this by a few months and a few more engineers, and the pattern calcifies.

The bottleneck person rarely notices until they're exhausted. The team rarely notices until the bottleneck is on vacation and everything slows down in ways that are hard to explain in a retrospective.

If you were to draw a graph of who reviews whose work, who gets mentioned in Slack threads, and who appears in incident timelines — on most teams, this graph is far less distributed than the org chart implies.

In well-functioning teams, knowledge and review authority spread across multiple nodes. In bottleneck-prone teams, one or two nodes accumulate a disproportionate number of edges. The org chart shows a flat team. The coordination graph shows a hub-and-spoke.

This asymmetry matters because it means team throughput is capped by one person's bandwidth, not by the team's collective capacity. And that person's bandwidth doesn't scale.

Tech leads often misread quiet bottlenecks as a sign of a healthy team. "Everyone trusts Maya" sounds like a positive. And it is — until Maya takes two weeks off and three PRs stall and two incidents go unresolved longer than they should.

The tell is dependency by habit rather than dependency by necessity. When an engineer pings someone not because only that person can help, but because it's faster than figuring it out themselves, the bottleneck is doing the team's learning for them.

This is different from healthy specialization. A security engineer being the default reviewer for auth changes is specialization. A backend engineer being the default reviewer for everything because people know they'll respond quickly is a bottleneck wearing the costume of collaboration.

You don't need a coordination graph tool to check for this. A 15-minute exercise works: look at the last 30 PRs merged. Count who reviewed what. Look at the last 10 incidents. Count who was in the Slack thread.

If one name appears in more than 40% of the cases, you have a quiet bottleneck. That number isn't a threshold from research — it's a prompt to ask why that person is in so many places, and whether the team's learning surface has quietly collapsed around them.

The fix isn't to tell that person to do less. It's to ask: what would need to be true for anyone on this team to confidently review this? Usually the answer points to missing documentation, undertested assumptions, or knowledge that lives only in one person's head.

Distributing review authority is slow work. But the alternative — waiting until the bottleneck burns out or leaves — is slower.

The concept of knowledge concentration risk in software teams is well-documented in research on bus factor and truck factor — the minimum number of engineers who, if suddenly unavailable, would stall a project. 1 Most codebases studied have a truck factor of one or two. Most teams already know who those people are. The coordination graph just makes the cost visible.