The blocker that was never a blocker

Picture an emergency room that never times anything. Patients check in, get triaged, wait. Some wait four minutes. Some wait four hours. Nobody at the front desk is malicious or lazy — they're just busy, and there's no clock on the wall that anyone's watching, and so the four-hour wait feels, from the inside, exactly like a slightly-longer four-minute wait. It's still a wait. It just doesn't feel like a crisis until someone finally looks up and does the math.

That's most teams' relationship with the word "blocked." A blocker gets announced in standup — "I'm blocked on the staging DB creds" — and it enters a kind of conversational limbo where it exists precisely as long as someone keeps mentioning it, and not one day longer, because nobody is timing it. The blocker that gets restated for the eleventh straight day sounds, on day eleven, exactly like the blocker on day one: a calm, matter-of-fact "still blocked." The sentence doesn't change even though everything about the situation has.

The queueing theory your standup accidentally reinvented

There is an entire, rigorous mathematics of exactly this phenomenon, and it's worth borrowing on purpose instead of stumbling into by accident. Little's Law, proven by John Little in 1961, is disarmingly simple: in any stable queueing system, the average number of items waiting (L) equals the average arrival rate of new items (λ) multiplied by the average time each item spends in the system (W). It sounds like a formula for a coffee shop. It is also, precisely, a formula for the backlog of unresolved blockers sitting in your team's collective attention at any given moment.

Donald Reinertsen spent a career translating queueing theory into product-development terms, and the version in The Principles of Product Development Flow is the one worth sitting with: work sitting in a queue doesn't just wait quietly — it accrues cost the entire time it waits, in the form of delayed feedback, context lost by the person waiting, and options that quietly close. A blocker isn't a static fact about a project. It's a queue item, accruing carrying cost every single day it sits there unresolved, whether or not anyone mentions it out loud that morning.

Reinertsen's specific contribution — the thing that separates his work from a textbook restatement of Little's Law — is insisting that this carrying cost be treated as a real, comparable number, the same way a factory treats the cost of inventory sitting in a warehouse. A part sitting unfinished on a factory floor isn't "just waiting," it's tying up capital, taking up space, and aging toward obsolescence. A blocker sitting unresolved is doing the engineering equivalent: the context the blocked engineer built up is decaying, the customer commitment attached to the blocked work is getting less achievable by the day, and the option to route around the blocker cheaply — available on day one — often isn't available by day fourteen. None of that shows up in the sentence "still blocked." All of it shows up in the clock nobody's running.

Here's the uncomfortable move Reinertsen makes that most engineering cultures resist: he argues that the actual, dominant driver of how long anything waits in a system isn't effort or difficulty — it's how much other work is in progress at the same time. High work-in-progress doesn't just slow the new thing down; by Little's Law, it mechanically, mathematically lengthens the wait time of everything already queued, blockers included. A blocker that would resolve in a day on a quiet team can sit for three weeks on a team drowning in parallel work-in-progress — not because anyone dropped the ball, but because the queue got longer and nobody re-measured what that did to W.

A blocker doesn't get old because someone forgot about it. It gets old because nobody timed it, and an untimed queue is a queue that can grow forever without ever feeling like it's growing.

What "restated" is actually hiding

Try a small thought experiment. Two blockers, both announced today in standup: "blocked on staging DB creds" and "blocked on staging DB creds." Identical sentence. One of them is new — said for the first time this morning. The other has been said, word for word, every single day for two and a half weeks. Nothing in the sentence itself distinguishes them. Nothing in the room's reaction distinguishes them either; both get the same nod, the same "okay, anyone able to help unblock that," the same move to the next person.

But these are enormously different situations. The two-and-a-half-week blocker isn't a blocker anymore in any useful sense — it's a standing failure of the system to route a known problem to someone who can fix it, restated eleven times because restating costs nothing and fixing apparently does. The latency of a blocker — the elapsed time from first mention to actual resolution — is the single number that would instantly tell you which of the two identical sentences is the emergency. And it's a number nobody's memory reliably tracks, because memory, as the last two posts in this series covered, is exactly the wrong instrument for holding a precise duration steady against a moving present.

The compounding trick nobody notices

Here's the part of Little's Law that makes untimed blockers so dangerous, and it's a little counterintuitive: a queue doesn't grow because any single item got harder. It grows because the arrival rate of new items outpaces how fast old ones leave, and once that imbalance sets in, every subsequent item — including the blocker you announced yesterday, which had nothing to do with anything already in the queue — inherits the wait time of the pile it landed on top of. This is why a team can feel like nothing individually changed and still watch blocker latency creep from two days to six to eleven over a quarter: nobody's blocker got objectively worse. The queue underneath all of them did, and every blocker announced afterward pays the compounding rent, whether or not it deserves to.

This is also why "just prioritize unblocking people" as standing advice tends to under-deliver. Prioritization inside the standup addresses one item at a time — heroically, even — while leaving the thing that actually determines average wait time, the total volume of work-in-flight, completely untouched. You can watch a team declare a blocker "top priority," resolve it in record time, and see average latency barely move, because the queue that produced the six-day wait in the first place never got shorter. Reinertsen's point isn't subtle once you see it: you don't fix queueing delay by working harder on the item in front of you. You fix it by having fewer items in front of you at once.

Three questions a timed blocker answers that a restated one can't

1. Is this actually still blocking anything? Work sometimes routes around a blocker quietly — someone finds a workaround, the urgency fades — and the blocker gets mentioned out of habit long after it stopped being load-bearing. Elapsed time against the work it was supposedly blocking answers this in a way "still blocked" never will.
2. Is our WIP the actual problem? Per Little's Law, if blocker latency is climbing across the board, not just on one unlucky ticket, the fix isn't heroics on any single blocker — it's fewer things in flight at once. A single restated sentence can't show you a trend. A latency measured across every blocker, every week, can.
3. Who actually needs to be pulled in? A blocker restated for the third time in three days is a different escalation than one restated for the eleventh day running with nobody new looped in. The first is normal friction. The second is a routing failure, and only the clock reveals which.

Measure the wait, not the mention

None of this requires a heavier process. It requires exactly one discipline: when a blocker is first named, note when — and when it's resolved (or restated, honestly, as still open), note that too. The latency is just the gap. (This is the whole of what Cadence tracks on a blocker claim: first mention to resolution, measured, not remembered — the standup module doesn't need to know why staging credentials are hard to get, only how long the wait actually was.) A team that can see "average blocker latency: 6.5 days, up from 2 this sprint" is looking at a Little's Law symptom in plain language, and can ask the right question — is this one blocker, or is this our whole queue backing up — instead of the only question an untimed system can ask, which is "anyone able to help with that?" asked, gently, for the eleventh consecutive morning.