Eight Days, One Change: Testing a Workflow Tweak Without Calling It a Transformation

There's a particular kind of meeting that happens in UK offices every autumn. Someone proposes a small change to how work flows — a new approval step, a different handover, a form that isn't three screens long. Everyone nods. It gets rolled out on a Friday. Three weeks later it's quietly abandoned and nobody can quite say why.

The change wasn't necessarily bad. What was missing was an agreement, made before the rollout, about what "working" would look like — and what would make you stop. Without that, every tweak becomes a personality contest judged on vibes.

The eight-day rule is an attempt to fix that. It's not a framework, it's a habit: one change, eight days, criteria written down in advance, and a decision at the end that you're allowed to make quickly.

Why workflow changes get judged on vibes

Workflow tweaks are hard to evaluate because the evidence is scattered. The people who like the change tell you it's smoother. The people who don't tell you it's slower. Both are probably right about their own bit of the process, and neither has a number.

So the discussion drifts towards the loudest voice, or towards whoever has the most seniority, or towards "let's give it another month" — which is how a two-week experiment becomes a permanent arrangement nobody chose.

The fix is boring: decide the measurement before you start. Not because numbers are magic, but because they stop the conversation being about feelings.

The shape of the eight days

The cycle has four parts, and the whole thing fits inside a fortnight.

Day 0 — Define. Write down three things on one page: the change you're testing, the single number you'll watch, and the criteria for success and failure. Circulate it. If the team can't agree on the page, that disagreement is the finding — don't roll anything out yet.

Days 1 to 6 — Run. Live with the change exactly as written. No mid-week tinkering, no "while we're here" additions. If something breaks badly enough that it can't wait, that's a kill, and you log why.

Day 7 — Review. Look at the number. Ask the people who did the work. Compare the week to the baseline week you recorded before Day 0. Keep this to forty-five minutes.

Day 8 — Decide. Keep it, kill it, or run a second cycle with one variable changed. Then write down the decision and who made it. That last bit matters more than it sounds.

Write the kill criteria before the comms

This is the part teams skip, and it's the part that makes the whole thing work.

Before you announce anything, finish this sentence: "We will stop if…" Good answers are specific. If more than two handovers a day get stuck for over an hour, that's a stop. If the finance team has to re-key the same data twice, that's a stop. If the error rate goes above the pre-agreed line, that's a stop.

Having an agreed stop condition does two things. It gives people permission to say "this isn't working" without it sounding like a complaint about a colleague's idea. And it means the decision at the end is a reading of the rules, not a negotiation.

Success criteria deserve the same treatment. "People seem happier" is not a criterion. "Handover time down from two days to under one, measured on the same five tickets each week" is.

Pick one number, and pick it honestly

One number. Resist the urge to build a dashboard for a six-day experiment. Choose something you can actually see without a new tool — cycle time on a sample of jobs, number of times a task bounces back, hours spent on a manual step in a diary.

And be honest about the baseline. If you didn't record how things worked before, you'll spend Day 7 arguing about what "normal" used to be. Spend an hour on Day 0 capturing last week's version of the number instead.

Small print: what eight days can't tell you

Eight days won't tell you whether a change holds up across a quarter, a Christmas shutdown or a team restructure. It won't catch rare edge cases, and it won't be statistically meaningful if your volumes are tiny.

That's fine. The eight-day cycle isn't there to prove a change is right forever. It's there to filter out the ones that are obviously wrong, cheaply, before they get embedded in a process document and a training deck.

One practical note for the calendar: November is a decent month to run a cycle, but plan the finish before the December change freeze kicks in. A decision left hanging over the holidays has a habit of becoming permanent by default.

After day eight

If the change survives, congratulations — you now have a written record of why it exists, what it was meant to do and who signed it off. That document is worth more than it looks. It's the thing you'll reach for in six months when someone asks why the process works this way.

If it doesn't survive, you've lost six days and gained a genuinely useful answer. That's a much better trade than three weeks of quiet drift and a process nobody remembers choosing.