The art of the operating intervention

The best interventions look small from the outside and feel enormous from the inside.

The diagnosis is the intervention

Most operating problems get solved twice. Once badly, with a big programme that treats the symptom. Once properly, months later, with a change so small the org barely notices it happening.

I watched a scale-up spend four months building a "performance enablement framework". New competency matrix, new review cycle, calibration workshops for every manager, a rating scale redesigned from five points to four. The underlying problem was that one VP was rubber-stamping every review his direct reports submitted without reading them. Fix the VP's habit, not the framework. Instead they rebuilt the framework and the VP kept rubber-stamping, just against new paperwork.

That is the pattern. Leaders reach for scale because scale feels like seriousness. A big rollout signals that the problem was taken seriously. But size and impact are not the same thing, and confusing them is the single most expensive mistake I see in operating design. The four-month framework cost roughly £180k in facilitator time and lost manager hours. The actual fix, a fortnightly fifteen-minute review with the VP's own manager, would have cost nothing and worked in three weeks.

Diagnosis has to come before intervention, not alongside it. If you cannot name the specific behaviour, the specific person, the specific moment where the system breaks, you are not ready to intervene. You are ready to redecorate.

Why small beats big

Small interventions are cheap to test and cheap to reverse. That is the entire argument. A big intervention, once launched, has its own momentum: sunk cost, internal comms already sent, a steering committee that now exists and needs something to steer. You cannot quietly retire a company-wide OKR rollout after six weeks even when it is obviously not working. You can absolutely retire a two-line change to a Slack channel's notification settings.

This is also why small interventions get taken more seriously by the people living inside the system. A manager who is told "stop scheduling 1:1s back to back with no gap" will actually do it, because it is a concrete instruction they can start tomorrow. A manager who is handed a forty-page "manager excellence framework" will nod, file it, and change nothing. Specificity is what makes a change executable. Scope is what makes it ignorable.

There is a sizing test I use with clients before anything gets greenlit: can you describe the change in one sentence, without a noun like "framework", "programme" or "initiative" in it? "We are removing the requirement for VP sign-off on offers under £5k." Yes. "We are launching a hiring excellence initiative." No. If the sentence needs a capitalised noun to hold it together, the intervention is probably bigger than the diagnosis warrants.

Fitting the grain

A carpenter doesn't argue with wood. They read it first.

An intervention that fits the grain uses a mechanism the organisation already trusts and just repoints it. A sales team that already does a rigorous weekly pipeline review does not need a new ritual to fix a forecasting problem. It needs one extra column added to the review they already run, and one extra question the sales lead already knows how to ask. The muscle exists. You are redirecting it, not building a new one.

An intervention that fights the grain invents a new ritual, a new owner, a new cadence, on top of a culture that has no attention left for it. I have seen three separate clients try to fix a documentation gap by mandating a new wiki. All three failed, because the org's actual habit was Slack threads and tribal memory, and a wiki fights that habit rather than using it. The fix that worked, in the one case where it did work, was pinning the three most-asked questions to the top of the existing Slack channel and updating them weekly. Same channel people already open forty times a day. No new habit required.

Testing for grain-fit before you scale means asking one question: does this intervention route through a behaviour, tool or relationship that already has trust and traffic, or does it require the organisation to build a new one from nothing? The former compounds. The latter has to fight for adoption every single day it exists, and most interventions do not survive that fight past the second month.

Where interventions go wrong

Big interventions usually fail for one of three reasons, and all three trace back to a weak diagnosis.

First, they solve the visible problem instead of the structural one. The visible problem is "managers aren't giving feedback". The structural problem is that the manager's own manager never asks about it, so there is no accountability loop above the behaviour you want to change. Training the managers harder does not fix a missing loop.

Second, they mistake the loudest complaint for the one that matters most. The loudest voice in an org design review is rarely describing the actual bottleneck. It is describing the thing that annoyed them most recently. A proper diagnosis triangulates: what does the data show, what do the quiet, competent people say when asked directly, and where does the actual work visibly stall. Loud and true are different axes.

Third, they add a layer instead of removing a constraint. Most organisational dysfunction is not a missing process, it is an existing process nobody has permission to bypass when it clearly does not apply. The fix is very often subtraction: remove the sign-off, remove the meeting, remove the form. Subtraction is unglamorous, which is exactly why it gets skipped in favour of a new framework that looks like effort.

Testing before you scale

Run the intervention in one team, one function, or one week before it touches the whole org. Not a pilot programme with a launch deck. Just do it, quietly, somewhere it is reversible, and watch what actually happens against what you predicted would happen.

Three things to watch for during that test. Does the behaviour change without anyone having to be reminded twice. Does a second-order effect show up that you did not predict, good or bad. And does the team ask for more of it unprompted, which is the closest thing to proof that it fits the grain rather than fighting it.

If all three come back clean, scale it exactly as it ran in the test. Do not "enhance" it on the way to rollout. The temptation to add scope during scaling is where most good small interventions die: someone in a steering meeting asks "should we also…" and the smallness that made it work gets diluted by the third addition.

Document the diagnosis, not just the fix

An intervention without its diagnosis attached is a trick, not a method. If you cannot explain why the fifteen-minute VP check-in worked, you cannot tell whether it will work in the next org, with a different VP, in a different market. Write the diagnosis down next to the intervention: what was actually broken, what evidence proved it, what constraint the intervention removed or rerouted. That pairing is what makes the intervention repeatable rather than a one-off story you tell in a proposal deck.

This is the actual deliverable in most of my engagements. Not the intervention itself, which is often embarrassingly small once you see it written down. The diagnosis that got us there, because that is the thing the client's own team can reuse the next time something in the system quietly breaks.