The Finding
Research into process improvement offers a finding that runs against the usual instinct. Nelson Repenning and John Sterman, of MIT Sloan School of Management, studied why process-improvement efforts so often fail to hold, using system dynamics modelling alongside more than a dozen organisational case studies. Their central finding was that organisations under pressure default to “working harder” — adding effort, expediting, firefighting — rather than “working smarter,” and that the people who prevent problems from recurring receive no visible credit for the problems that never happen. They termed the resulting pattern the capability trap: organisations that most need to invest in fixing a recurring source of inconsistency are, because of the pressure that inconsistency itself creates, the least able to find the time to do so.
What It Means in Practice
Consider an organisation where a queue of unresolved work has hovered at roughly the same size for a year and a half, despite two dedicated efforts to clear it. Each effort worked — the queue visibly shrank — and each time, within weeks, it returned to its previous size. On the surface this looks like insufficient capacity. Looked at more closely, the arrival rate of new work and the processing rate are closely matched, and the queue length, while persistent, is stable rather than growing.
This is not a backlog waiting to be cleared. It is a buffer in equilibrium — evidence that the system is operating at its capacity limit, not evidence that it is failing. Clearing effort applied to a buffer in equilibrium treats a symptom of a structural condition as though it were the condition itself, which is why the same amount of work keeps reappearing however many times it is cleared.
The Repenning and Sterman finding explains why this particular kind of inconsistency tends to persist rather than resolve. Firefighting the visible queue produces an immediate, measurable result — the queue gets smaller, and that success is visible to everyone. Addressing the underlying capacity constraint that keeps regenerating the queue produces no equivalent visible win, and may in fact look, in the short term, like a cost with no immediate payoff. Under sustained pressure, the visible win keeps being chosen over the invisible fix, and the pattern repeats.
Why the Cost Stays Hidden
The cost of this kind of inconsistency rarely appears on any single line of a budget or a performance report. It is distributed: a bit of extra time here, a rushed decision there, effort repeatedly spent clearing the same queue rather than addressing why it exists. None of these individually look large enough to justify sustained attention. Added together across a year, they represent a substantial and recurring cost that no report is structured to capture, because the reporting structure — like the organisation itself — is generally built around discrete events rather than persistent equilibria.
A related misconception follows from this: leadership teams often interpret a stable, recurring backlog as evidence that a fix has not yet been found, rather than as a structural signal in its own right. The stability is itself informative. A backlog that grows indicates a capacity shortfall getting worse. A backlog that holds steady at the same size, despite repeated clearing effort, indicates a system running persistently at its limit — a different diagnosis, with different implications, and one that repeated clearing exercises will not resolve on their own.
There is a contextual dimension to this finding worth drawing out. The capability trap is most visible in operations where the connection between effort and result is direct and fast — a queue that visibly shrinks the moment more people are assigned to clear it. It is far less visible, and arguably more damaging, in operations where that connection is slower or less direct, because the temptation toward the visible fix is just as strong while the evidence that it isn’t working takes considerably longer to accumulate. An organisation that only examines its most visibly firefought areas may be missing an equivalent, slower-moving version of the same pattern elsewhere.
The Compounding Consequence
There is a further cost to this pattern that rarely appears in any single clearing exercise’s own accounting. Each clearing effort consumes real time and attention — often pulled from people who have other responsibilities, redirected temporarily because the backlog has become visible enough to warrant it. Because the underlying capacity constraint is never addressed, that time and attention is spent again at the next clearing effort, and the one after that, in a way that a one-off cost analysis will never capture, because each individual instance looks like a reasonable, bounded response to a visible problem. Summed across several cycles, the organisation may have spent a considerable multiple of what a single, structural response would have cost — without that comparison ever being made explicitly, because the two are never accounted for on the same ledger.
This connects to a broader tension worth naming plainly: visible effort and structural change compete for the same limited attention, and visible effort has a persistent advantage. It produces an immediate, demonstrable result. Structural change, by contrast, often requires accepting a period where the metric looks the same or even worse before it improves — a trade a team under pressure is rarely in a position to make, however clearly the underlying logic supports it in principle.
Looking for your own sector? The Other Sectors page points to the closest match.
Questions worth considering
- Is there a recurring queue, backlog, or exception list in the organisation that has been “cleared” more than once and returned to roughly the same size each time?
- What would it look like to treat that stability as information, rather than as a failure to have fixed it yet?
- Who currently gets recognised for clearing the queue, and does anyone get recognised for the queue never forming in the first place?
- Is this a backlog, or is it what this system looks like when it is working at its limit?
More on this topic: Operations.
Your team is facing similar challenges?
Subscribe to The Riddle Ledger
Perspectives are sent as they are published, with no promotional email, and you can unsubscribe at any time.