One person on my team is blocking everyone else.

What to do when one person on your team is blocking everyone else

June nineteen seventy-eight. Lois Gibbs is twenty-six. She lives on Ninety-Ninth Street in the LaSalle neighbourhood of Niagara Falls. She has no professional background in organising — she's a housewife with two children, one of whom has just started at the local elementary school.

The newspaper that lands on her doorstep that month carries a story she cannot put down. The school her son attends sits on top of twenty-one thousand eight hundred tons of toxic chemical waste, buried by Hooker Chemical and capped over with topsoil before the houses arrived.

She writes to the school board and asks for her son to be transferred. The reply is what you would expect. Transfer requires proof. The proof has to demonstrate that Love Canal is actually harming children. The burden of producing that proof is hers.

The conventional move at this point is to write a better letter, find a sympathetic doctor, hire a lawyer the family cannot afford. She does none of these things.

She picks up a clipboard. She walks out of her house. She knocks on the door of every neighbour on her street and asks the same question: is anyone in your family sick.

Within a week she has a handwritten count of miscarriages, birth defects, leukaemias and rashes that the families have been carrying privately. Within weeks the Love Canal Homeowners Association exists as a legal entity with bylaws and elected officers. By the seventh of August nineteen seventy-eight — eight weeks after the clipboard — President Carter declares a federal health emergency at Love Canal and authorises the first round of permanent relocations.

The structural move is the one worth naming. The school board did not lift its block. Gibbs did not unblock it. She built, in parallel, a second structure — a homeowners association with documented data, a public profile, an organised constituency — that made the school board's block irrelevant.

When the rest of the work stopped routing through the school board, the school board stopped being a blocker. It just became a room upstairs.

So let's go to the office and work through it.

"One person on my team is blocking everyone else."

The feeling is strangled.

You can see the work stacking up behind one person. Reviews waiting. Decisions waiting. Work that should already have shipped, sitting in a queue that has one name on it.

First tell an ego-shaped block from a real signal

Two choices. They look identical when you're staring at the queue. They need different moves.

When letting work through feels like losing control

Choice one: the bottleneck is ego-shaped. The work is stacking up because letting it through feels, to the person, like losing something — control, status, the part of the role that says this still goes through me.

If that's the trap, don't escalate. Don't accuse. Send them a short message and ask for their advice on clearing the specific bottleneck they're creating. Robert Cialdini wrote about this in Pre-Suasion in two thousand and sixteen — people find it almost impossible to argue with their own advice, and the act of giving it quietly commits them to being part of the solution rather than the problem.

When the resistance is pointing at a real fragility

Choice two: the bottleneck is pointing at something real. The resistance isn't obstruction. It's a signal that there's a fragility in the workflow this person can see and the rest of the team can't.

If that's the trap, treat it as diagnosis, not defiance. Ask them to identify the single most fragile dependency in the current process. Make them responsible for fixing that one thing. You haven't given in. You've accepted the bottleneck was telling you where the problem was, and you've rerouted their energy from blocking to solving. This is the move Eliyahu Goldratt called subordinating the rest of the system to the constraint — The Goal, nineteen eighty-four.

Ego-shaped, or signal-shaped. Same person at the same desk, two completely different first moves.

How to see the blockage before clearing it

Three tools. Make the bottleneck visible before you try to clear it.

The first is

Map where the work waits, not who does it

Workflow Optimisation.

The lineage runs through Lean. Taiichi Ohno laid the ground inside Toyota in the nineteen-fifties. Jim Womack and Daniel Jones formalised the method outside Toyota in Lean Thinking in nineteen ninety-six. Mike Rother and John Shook gave the field its visual grammar — value stream mapping — in Learning to See in nineteen ninety-nine.

The reason the tool exists is that the bottleneck you think you see and the bottleneck actually slowing things down are usually different. Blame points at one person; the map points at something else.

The unique insight is the distinction between working time and waiting time. The work isn't slow because the steps that do the work are slow. It's slow because the work waits between the steps. The bottleneck is wherever it waits longest.

What you get is a picture of the queue, depersonalised. The conversation moves from X is blocking to the work is queuing here, here, and here — which is a much easier conversation to have with the person who used to be the answer.

So. How to run it.

Map. Every step from request to completion. Every handoff visible. The team draws it together; one person mapping it alone produces the map of the team they imagine, not the team they have.

Time. Two numbers per step. How long it takes when the work is being done. How long it waits before someone picks it up.

Mark. The places where waiting dwarfs working. Those are the bottlenecks. Mark them and stop. The map has done its job. The fix lives in the conversation that follows, not in the diagram.

The second is

Get the expertise out of one head and onto a card

Checklist.

Atul Gawande wrote The Checklist Manifesto in two thousand and nine. The lineage is older — the Boeing pre-flight Checklist arrived in nineteen thirty-five, after the Model Two Ninety-Nine prototype crashed on its demonstration flight because the test pilots had forgotten to release the gust lock. The plane had become too complicated to fly from memory. The fix wasn't smarter pilots. It was a card on the cockpit dashboard.

The reason the tool exists for this scenario is that expertise stuck inside one person's head is what makes that person a bottleneck. The work routes through them not because the work is hard but because nobody else has the procedure.

The unique insight is that a good Checklist is short. Five to nine items. The things that actually fail when they're missed. The two thousand and eight World Health Organization surgical-safety Checklist — the one Gawande studied for the book — had nineteen items and cut complications by more than a third across hospitals on four continents. And even nineteen is long compared to what you usually need.

What you get is the expertise out of one head and into a form anyone in the team can run, regardless of seniority or experience. The expert becomes the editor of the Checklist, not the gatekeeper of the work. They keep their authority over what should be checked. They lose their position as the only one who can do the checking.

So. How to run it.

Find. Look at where the work has actually gone wrong, recently. Not where it could go wrong in theory.

Write. Five to nine. Each one a thing that, if missed, leads to the failure. Verifiable in seconds.

Run. Have someone less familiar with the procedure use the Checklist. The expert watches.

Refine. Cross out the items that never get caught. Add the one that didn't make the first pass and would have prevented last week's slip.

The third is

Sort the slowness into the kind of debt it really is

Technical Debt Quadrant.

Martin Fowler published it on his website in October two thousand and nine. The metaphor is older — Ward Cunningham gave a talk in nineteen ninety-two that used the language of debt to describe code shortcuts. Cunningham gave the field the metaphor. Fowler gave it the diagnostic shape.

The reason the tool exists for this scenario is that some bottlenecks aren't behavioural. They're architectural. The architect is slow not because the architect is slow, but because the codebase is slow — and the codebase is slow because of decisions made one, two, five years ago that have compounded since.

The unique insight is that not all debt is the same problem. Two axes. Deliberate or Inadvertent. Prudent or Reckless. Four quadrants, and the conversation moves from blame to category.

What you get is a conversation about what kind of debt this is — which is a much more useful conversation than the one about who is slowing things down. The team can see whether the slowness is the consequence of decisions they made on purpose or decisions they made without knowing.

So. Walk the four quadrants.

Reckless deliberate. We don't have time to do this properly. No illusion. The team knew the right way and chose not to take it.

Reckless inadvertent. What's layering? The team didn't know. Now they do, and the system has to be patched after the fact.

Prudent deliberate. We have to ship and we'll deal with this later. Decided knowing the cost. The most defensible quadrant. The one that becomes a problem only when later never comes.

Prudent inadvertent. Now we know how we should have done it. You only learn the right shape by doing the wrong shape first.

The conversation about your bottleneck is the conversation about which quadrant the team has been writing into.

That's the toolkit. One more pattern before we close — quieter than the story we opened with, deliberately.

A precedent: when the work stops routing through the block

Steve McDougall, who works with growing engineering teams, names a pattern he says he sees consistently. Past about twenty engineers, a senior architect or tech lead with strong opinions and good judgment becomes the bottleneck for every significant decision — not because they want to be, but because decisions naturally flow through them. At small scale, that works. At scale, it's a queue.

The fix McDougall describes is to distribute decision-making authority deliberately. The architect is told that the team can make calls without going through them; their job is to intervene only when something is about to break, not to approve things in advance.

The interesting part is what happens to velocity when teams do this. It goes up, as expected. The quality doesn't drop as much as the architect feared.

The bottleneck was real. The protection it was offering was smaller than everyone in the room assumed.

So.

That's the architect-bottleneck pattern. Quiet, internal, easy to miss. The Gibbs story we opened with is the same move at a different scale — the institution in the role of the architect, refused to lift the block, so the work routed around it.

Both moves are the same recognition. The bottleneck only holds if the rest of the work routes through it.

So. Your Next Move from this playbook.

Where in your workflow does work currently sit waiting — for something, for someone?

And how much of last sprint's missed velocity was your team's effort, versus that queue?