Human bottlenecks in team systems

The idea

In collaborative work specific people are often the constraint.

There is a particular kind of praise that should make you nervous. "We could not do this without you." "You are the only one who really understands this." "Everything has to go through Sarah — she is the one who keeps it all together." These sound like compliments. They feel like recognition of expertise, reliability, indispensability. But translated into the language of constraint theory, they say something different: this system has a single point of failure, and it is a human being.

An example

A four-person development team ships features through a standard pipeline: build, code review, QA, deploy. Three developers finish their work in a day or two, but every pull request must be reviewed by the senior engineer — the only person the team trusts to catch architectural mistakes. She reviews carefully, averaging ninety minutes per PR. With four developers producing roughly two PRs each per day, eight requests land in her queue daily. She can review five. By Friday, fourteen PRs are waiting. Three developers sit idle for stretches of the afternoon, blocked on review. The team's throughput is not four developers times their velocity. It is one senior engineer times her review capacity. She is indispensable, respected, and the single constraint throttling the entire system.

Where it goes wrong

Treating the human bottleneck as a performance problem rather than a structural problem. When someone is the constraint, the instinct is to push them to work faster, work longer, or multitask harder. This backfires. You burn out the constrained person, degrade the quality of their output under time pressure, and ignore the architectural question: why does the system require a single person at this step? The bottleneck is not the person's speed. It is the system's dependence on one person. Asking them to be faster treats a structural constraint as a personal failing, and it guarantees the bottleneck will return — or the person will leave.

Make it stick

This week, audit one team or collaborative system you participate in for human bottlenecks. For every step in the workflow, ask: ''If this person were unavailable for two weeks, would this step stop entirely?'' Any step that answers yes is a single-point-of-failure human bottleneck. For the most critical one you find, draft a one-paragraph de-bottlenecking plan: what would need to be documented, delegated, or restructured so that the step could continue — even at reduced quality — without that person. Share it with the person in question. They will almost certainly be relieved, not offended.