The Intervention Order Nobody Gets Right

Cycle time is rising. The first meeting produces three proposed solutions: hire a test specialist, adopt a new deployment pipeline, run daily standups. All three sound reasonable. None of them address the actual constraint.

This is not a failure of intent. It is a failure of sequence. The interventions being proposed are not necessarily wrong — they might all be useful eventually. The problem is that they are being considered simultaneously, before anyone has checked which one the system actually needs first.

The simultaneous-solutions trap

When a delivery problem is identified, the instinct is to generate options and act on several of them at once. It feels decisive. It feels thorough. It also makes it impossible to know which change produced which result — and it often means the most expensive option gets the credit for an improvement that the cheapest option would have produced on its own.

Organisations that run three concurrent interventions and see improvement tend to conclude that all three were necessary. This is almost never true. What they have lost is the ability to know what to do again the next time.

Why the order matters more than the choice

Interventions are not interchangeable. Some address root causes. Others treat symptoms. The distinction matters because applying the wrong level of intervention wastes the effort — the symptom returns when the root cause is untouched.

More specifically, interventions exist at different levels of cost, reversibility, and causal depth. A policy change costs nothing, can be reversed in a day, and sometimes resolves the problem entirely. A capacity change costs money and takes weeks to stabilise. A process redesign is disruptive, slow to produce signal, and nearly impossible to attribute with confidence.

If WIP is the constraint and cycle time is long because too many items are in flight simultaneously, hiring more testers does not solve the problem. It gives you more people watching work pile up in the same queue. The root cause is untouched. The investment is spent.

The three-level hierarchy

The correct sequence is WIP control first, capacity second, process redesign third.

Each level assumes the one below it is not the source of the problem. Capacity investment only makes sense when WIP is stable and throughput is still insufficient. Process redesign only makes sense when both WIP and capacity have been addressed and the system is still not behaving predictably.

This ordering is not arbitrary. WIP control is the fastest-acting, least costly, most reversible lever available. Process redesign is the slowest-acting, most costly, and hardest to reverse. Reversing the order is how transformation programmes spend budget on the wrong problem and then conclude that the approach doesn't work.

WIP first: the lever you already have

Reducing work in progress typically produces measurable cycle time improvement within two to four weeks. It requires no budget, no tooling, and no external dependencies. It requires only a policy: stop starting new work until existing work is finished.

The reason teams do this last rather than first is that it requires saying no — to new features, to additional tracks, to the stakeholder who wants their initiative moving. That conversation is politically uncomfortable. Starting a hiring process or launching a tooling evaluation is much easier to announce.

But the discomfort of the WIP conversation is not evidence that it is the wrong move. It is evidence that the system has been running without a constraint on new starts for long enough that the absence of one feels normal. The policy change is cheap. The courage to make it is what has been lacking.

When capacity is the real constraint

If WIP has been genuinely addressed — if the team is finishing items before starting new ones, if the board shows a manageable number of active items — and cycle time is still longer than it should be, then capacity is worth examining.

Capacity problems look different from WIP problems. In a WIP problem, items age across multiple stages. In a capacity problem, items age in one specific place: the review queue has one person, the approval gate has a single decision maker, the test environment is shared and booked out for days. The constraint has a specific identity.

Capacity interventions are targeted and reversible. They should come after WIP has been stabilised, because stabilising WIP is what makes the specific capacity constraint visible.

Process redesign as a last resort

Process changes are the most disruptive and least attributable interventions available. They take time to implement, time to stabilise, and time to produce measurable signal. They are the right move when the first two levers have been genuinely applied and a specific structural pathology has been identified — not when leadership wants something bold to announce.

Running a framework change, adopting a new methodology, or restructuring teams before WIP is controlled is almost always the wrong sequence. It is also the most common one. The framework gets the credit or the blame for an outcome that was driven by whether WIP happened to change during the same period.

How to apply the hierarchy in practice

The diagnostic sequence is straightforward. Check WIP and age first. If there are many items in progress and several have been aging for longer than typical, the intake policy is the place to start. Address it before anything else.

If WIP is controlled and age is stable but throughput is still insufficient, look for the specific capacity constraint. Find the stage where work accumulates most consistently and address that stage directly.

Only move to process redesign if both of the preceding levels are addressed and the system is still not performing predictably.

The right intervention applied in the wrong order is still the wrong intervention. Sequence is not a detail — it is the strategy.

The diagnostic question

Before your next intervention, ask two questions. Does your team have a WIP policy — an explicit limit on how many items can be in progress at once? Is that policy being enforced consistently?

If the answer to either question is no, you have not yet applied the first lever. Starting anywhere else is skipping ahead in the hierarchy and hoping to get lucky.