How does a work-in-progress limit make a hidden bottleneck visible?

## Why a bottleneck can hide in plain sight Every workflow has one stage that is slower than the others, and usually the team cannot say which one it is. That sounds surprising until you look at what an uncapped board does with the mismatch. The difference in speed does not vanish - it collects in the space between stages, as waiting work. Queues are free to create, and on a board without limits they are invisible, because a column holding twenty-three cards still just looks like a column. Meanwhile everybody reports being busy, and honestly so: the stages before the slow one keep starting new work precisely because there is always more to start. The only symptom that reaches anyone is that requests take a long time to come out the other end, for reasons nobody can locate. Asked where the delay is, each stage points somewhere else, and each of them is telling the truth about its own effort. ## What a cap changes A cap takes away the queue's ability to absorb the mismatch. Once a column cannot exceed its number, the waiting has nowhere to accumulate quietly, so it accumulates visibly and then it stops the stage in front of it. Consider a 7-person team building a legal-document review product with four working columns - analysis, build, legal check, done - where only one person holds the qualification to sign a legal check. Caps go on at analysis 3, build 4, legal check 2. Within two days the board reads: - **legal check:** 2 of 2, unchanged since the previous morning - **build:** 4 of 4, so nobody there can pull anything new - **analysis:** 3 of 3, blocked behind build - **done:** nothing added for 2 days Before the caps, the same team had 19 cards spread across the board and no idea where the delay lived. After the caps, the board is pointing at exactly one column, and it took two days rather than a study. ## The signature to read | What the board shows | What it means | | --- | --- | | One column pinned at its cap while the next column stays empty | the constraint is that column | | Every column part-full, nothing ever blocked, for weeks | the caps are too loose to bind and surface nothing | | Cards repeatedly moving backwards out of a column | the constraint is quality entering it, not capacity inside it | | Caps quietly breached with no conversation | the team has stopped treating the number as a rule | The first row is the classic one and the one worth being able to describe out loud. The interesting detail is that the constraint announces itself in three places at once - the stage itself is saturated, the stage before it is blocked, and the stage after it is starving - and that combination is what distinguishes a genuine constraint from a stage that merely had a busy morning. ## Why blocking is the feature, not the failure The reflex, when two people are blocked and cannot start anything, is to conclude that the limit is wrong. It is worth being precise about what the alternative would have been. Those two people were always going to be unable to help the constraint; without the cap they would have started a fifth and sixth card instead. That does not make the slow stage faster. It adds two items that will queue at the same place, and it makes every item already in flight finish later, because the constraint now has more work competing for it. So the blocked state is not waste being created. It is waste being **revealed** - work the team was about to do that would have delivered nothing sooner. The value of the limit is precisely that it converts an invisible, comfortable inefficiency into a visible, uncomfortable one that somebody has to talk about. ## Constraints move, and that is healthy Once the team relieves the constraint - a second person qualifies to sign checks, an approval is delegated, the stage is split - the board does not become uniformly fast. The next-slowest stage becomes the one that limits everything, and the same three-part signature appears at a different column. That surprises people, and it is worth saying out loud in an interview, because it distinguishes someone who has read about limits from someone who has run under them. A team that removes one constraint should immediately go looking for the next one rather than declare the board fixed. Practically, that means: 1. Confirm the constraint moved rather than assuming the change worked. 2. Re-read the board for a new pinned column, a new blocked stage, a new starving one. 3. Resist raising caps in the calm period - the loose cap is what let the first constraint hide. ## What an interviewer is listening for A weak answer repeats the slogan: limits make bottlenecks visible. A strong answer gives the mechanism - queues absorb mismatch, caps remove the queues' capacity to absorb it, so the mismatch surfaces as a specific blocked column - and then says what the board looks like when that happens, and what the team does next.