Core Primitive
In collaborative work specific people are often the constraint.
The person everyone depends on is the person throttling the system
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.
The previous ten lessons gave you a general methodology for bottleneck analysis. That methodology works regardless of what type the bottleneck is. But different types demand different interventions — and a human bottleneck, the most common and emotionally complicated type in any collaborative system, calls for something most people resist: reducing dependence on a specific person, sometimes including yourself.
This lesson is about what happens when the constraint is not a step, a tool, or a policy, but a person. Why organizations create human bottlenecks, how to detect them, and what it takes to structurally resolve them.
The taxonomy of human bottlenecks
Human bottlenecks come in recognizable archetypes. Each emerges from a different organizational failure, and each creates its own distinctive queue.
The Approver. Every decision must pass through one person's judgment before it can proceed. The queue is a stack of pending decisions — purchase orders, project proposals, content drafts — each one blocking downstream work. The approver's inbox is a dam. Everything behind it is stagnant water.
The Expert. One person holds critical knowledge no one else possesses — a legacy codebase, a client relationship, a regulatory framework. The expert's queue is not decisions but questions. Knowledge accumulated asymmetrically, and the organization never invested in distributing it. The system's throughput is limited to the number of consultations the expert can handle per day.
The Quality Gate. One person must review every piece of output before it leaves the system. The reasoning is that only this person has the judgment to ensure quality. The effect is that the team's output rate is capped by this person's review bandwidth, regardless of how many people are producing work.
The Relationship Holder. One person "owns" the client relationship. Every question that touches the client routes through them. They become a translation layer, and their availability determines how fast the team gets answers and feedback.
The Decision Maker. Distinct from the approver — the decision maker synthesizes ambiguous information into direction. The team cannot move without it, and it can only come from one mind. Their processing time becomes the system's cycle time.
Each archetype creates the same structural problem: a serialization point in an otherwise parallelizable system. The system's throughput is not the sum of the team's capacity. It is the capacity of the serialization point.
Why organizations create human bottlenecks
Human bottlenecks are not accidents. They are the predictable outcome of four organizational dynamics.
Control. Distributed decision-making requires trust, and trust requires systems — shared values, clear frameworks, aligned incentives — that are expensive to build. Centralization is the cheap default. It works when decision volume is low. It collapses when volume grows.
Trust deficits. A manager burned by a subordinate's mistake starts reviewing everything. The trust deficit creates the bottleneck, and the bottleneck prevents others from building the track record that would resolve the deficit. It is a self-reinforcing loop.
Knowledge hoarding. The person who holds unique knowledge has job security and influence. Even when hoarding is unintentional, the absence of documentation systems means knowledge accumulates in one head by default. Organizations that do not actively invest in knowledge distribution will always produce human bottlenecks.
Absence of documentation. This is the structural root. If the expert's knowledge were documented, others could consult the documentation. If the approver's criteria were codified, others could apply the framework themselves. Human bottlenecks persist because tacit knowledge has never been made explicit.
Melvin Conway observed in 1967 that a system's structure mirrors the communication structure of the organization that built it. Conway's Law implies that human bottlenecks are not just workflow problems — they are architectural problems. If your communication structure requires everything to flow through one person, the systems you build will have the same single-point-of-failure architecture.
Brent: the canonical human bottleneck
The most vivid illustration of a human bottleneck in management literature is Brent, from Gene Kim, Kevin Behr, and George Spafford's 2013 novel The Phoenix Project. Brent is the senior engineer everyone depends on. He understands the entire technology stack. He is the only person who can fix certain production issues, configure certain systems, unblock certain escalations. Every project needs "just a little bit of Brent's time." Because everyone needs Brent, Brent is perpetually overloaded, perpetually context-switching, and perpetually the constraint.
The protagonist's breakthrough: Brent is not the solution — Brent is the bottleneck. Every task requiring Brent waits in Brent's queue, and Brent's queue is the longest in the system. The intervention is not to make Brent work harder. It is to protect Brent from unplanned work, document his knowledge so others can use it, and systematically reduce the tasks that require his involvement.
This is Goldratt's theory applied directly to a knowledge worker. The constraint is not a machine. It is a person. And the Five Focusing Steps — identify, exploit, subordinate, elevate, repeat — apply with modifications:
- Identify: Brent is the constraint. The evidence is the queue of tasks waiting on him and the number of projects blocked by his availability.
- Exploit: Ensure Brent spends 100% of his time on constraint-level work — the tasks that genuinely require his unique knowledge. Remove everything else from his plate. No meetings that someone else can attend. No tickets that someone else can resolve. No interruptions.
- Subordinate: Restructure everyone else's work around Brent's capacity. If Brent can review three items per day, do not assign him five. Batch his work. Protect his focus time. Make other teams plan around his availability rather than assuming instant access.
- Elevate: Invest in reducing the system's dependence on Brent. Document his knowledge. Train others to do what he does. Create runbooks for the procedures only he knows. Build automated checks that replicate his review judgment. This is the expensive, slow, essential step.
- Repeat: After Brent is de-bottlenecked, identify the new constraint.
Detecting if you are the bottleneck
The hardest human bottleneck to see is yourself. Being the bottleneck feels like being important, being needed, being central. The signals that indicate you are the constraint feel like signals of value. But the diagnostic questions are straightforward.
How long is the queue behind you? Count the number of items — messages, requests, tasks, decisions, reviews — currently waiting for your action. If that number is consistently growing, you are not keeping pace with demand. You are the constraint.
How often are people waiting on you? If colleagues regularly tell you "I'm blocked on your review" or "I need your sign-off before I can proceed," those are not compliments. Those are queue length reports. Each waiting person represents idle capacity in the system — capacity that is being wasted because it depends on you.
What happens when you are unavailable? If your vacation, sick day, or even your meeting schedule causes work to stop, you are a single point of failure. Richard Hackman, in his research on team effectiveness published in Leading Teams (2002), found that the most effective teams were those where no single member's absence could halt the team's core work. If your absence halts work, the team's design has a structural flaw, and you are that flaw.
What is your bus factor? The bus factor is the minimum number of team members who would need to be suddenly unavailable before the project cannot continue. If your bus factor is one, and that one is you, you are the bottleneck.
Are you doing work that others could do at 80% of your quality? This question cuts deepest. You hold onto tasks because you do them better. But "better" is not the question. The question is whether the system's throughput would increase if someone else did this task at 80% quality while you focused on tasks that genuinely require your unique capability. In most cases, 80% quality delivered on time beats 100% quality stuck in your queue.
De-bottlenecking yourself
Once you have diagnosed yourself as the constraint, the intervention has five components. They map to Goldratt's Five Focusing Steps, adapted for human systems.
Document relentlessly. Every time you answer a question, make a decision, or perform a task that someone else could not, write down how you did it. Not in a polished handbook — in a quick, rough document that captures the decision criteria, the steps, the edge cases. Daniel Pink, in Drive (2009), showed that autonomy is one of the three core motivators of knowledge workers. You cannot give others autonomy over work they do not understand. Documentation is the prerequisite to delegation.
Delegate with context, not just instructions. When you delegate a task, do not just describe what to do. Describe why — the reasoning behind the approach, the criteria for success, the failure modes to watch for. This transfers judgment, not just action. It is slower the first time and faster every subsequent time. The investment compounds.
Create decision frameworks. If you are the approver or the decision maker, distill your judgment into explicit criteria. "Approve if X, Y, and Z are met. Escalate if A or B is true. Reject if C." This does not capture 100% of your judgment. It captures 80%, and 80% is enough to unblock the queue for routine decisions while you focus on the genuinely ambiguous ones.
Accept good enough. This is the hardest step. If someone else reviews a pull request and catches 85% of what you would catch, the system is better off than if every PR waits three days in your queue. Perfectionism at the bottleneck is the enemy of throughput. You must decide what "good enough" means, communicate it explicitly, and then let go. Every task you refuse to release is a task sitting in the constraint's queue, blocking the system.
Train your replacement for each function. Not your replacement as a person — your replacement at each specific function where you are the constraint. If you are the only person who can deploy to production, train two others. If you are the only person who knows the client's history, write it down and brief a colleague. The goal is not to make yourself unnecessary. It is to ensure that no single function in the system depends exclusively on you.
The emotional resistance
De-bottlenecking yourself requires confronting an identity question. If you are no longer the person everything flows through, who are you? Ego becomes the meta-bottleneck — a constraint on the constraint-removal process itself. "I am the expert." "I am the quality gatekeeper." Removing the bottleneck feels like removing yourself.
The reframe: being the bottleneck means you spend most of your time on work others could do. De-bottlenecking frees you for work that only you can do — work at the frontier of your capability, not routine work that flows through you because no one else was trained. The bottleneck role is not the highest-value role. It is the most constrained role. Escaping it is a promotion, not a demotion.
Hackman's research confirms this. Teams where leaders focused on setting direction and coaching — rather than doing the team's work — consistently outperformed teams where the leader was a working bottleneck.
The Third Brain
AI offers a powerful lever for de-bottlenecking human constraints, because many human bottlenecks exist at the knowledge and judgment layer — exactly where AI can augment or partially substitute.
If you are the expert bottleneck, capture your knowledge in structured prompts. Create an AI assistant that can answer the first 80% of questions your team brings to you. Load it with your documentation, your decision logs, your past explanations. The team queries the AI first. Only questions that exceed the AI's training reach you. Your queue shrinks by the proportion of routine queries the AI absorbs.
If you are the quality gate bottleneck, build an AI-powered first-pass review. Define your review criteria explicitly — the same frameworks you would create for delegation — and have the AI apply them. It catches formatting issues, obvious logical errors, missing components, and standard compliance problems. You review only what passes the AI filter. Your review load drops, and your review quality increases because you are no longer fatigued by routine checks.
If you are the decision-maker bottleneck, use AI to prepare decision briefs. Instead of gathering information yourself, have the AI synthesize options, identify trade-offs, and present a structured recommendation. You still make the decision — but the time between "question arrives" and "decision is made" shrinks from days to hours because the preparation step is automated.
The pattern across all three is the same: AI does not replace the human bottleneck. It reduces the queue by handling work that does not require the person's unique judgment. This is Goldratt's "elevate" step, implemented through technology rather than hiring — an AI layer that absorbs the routine load, freeing the constrained person for work that genuinely requires them.
But tactical interventions — documentation, delegation, AI augmentation — address the symptom. The structural fix addresses architecture. Conway's Law tells you that if your communication structure has a single point of convergence, your system will too. Eliminating human bottlenecks permanently means designing teams where knowledge is distributed by default, building review processes where multiple people are qualified, and creating decision frameworks that allow decisions at the lowest competent level. The bus factor is not just a diagnostic metric. It is a design target. A bus factor of one for any critical function is a structural defect to be remediated with the same urgency as a security vulnerability.
Bridge to tool bottlenecks
Human bottlenecks are the most emotionally loaded type of constraint because they involve identity, ego, trust, and relationships. But they are not the only type. Sometimes the constraint is not a person but a tool — software, equipment, or a technology stack that limits throughput regardless of how capable the people are. The next lesson examines tool bottlenecks: how to detect when tooling is the constraint, when to optimize versus replace, and how switching costs make tool bottlenecks uniquely persistent.
Sources:
- Goldratt, E. M., & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
- Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press.
- Conway, M. E. (1968). "How Do Committees Invent?" Datamation, 14(4), 28-31.
- Pink, D. H. (2009). Drive: The Surprising Truth About What Motivates Us. Riverhead Books.
- Hackman, J. R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
- Williams, L., & Kessler, R. (2002). Pair Programming Illuminated. Addison-Wesley. (Bus factor / truck number origins in software engineering practice.)
- Goldratt, E. M. (1997). Critical Chain. North River Press. (Theory of Constraints applied to project management and knowledge work.)
Frequently Asked Questions