One change at a time

What This Is

We change one thing at a time, and we measure it for one full window before changing the next thing. When a client or their team wants to change everything at once, we sequence the work instead. Two or more changes shipped in the same window are unattributable, so we never ship them together.

Two facts matter.

First, if you change twelve things and the site improves, you cannot say which of the twelve caused it. You learned nothing, and you cannot repeat the win.

Second, if you change twelve things and the site drops, you cannot say which one to undo. You now have one unknown problem instead of twelve known variables.

Before you check

1. You have a change log with dated entries.

2. You have a baseline for the metric each change is meant to move.

3. You know the measurement window: 28 days against the previous 28 days.

Diagnostic tree

Run the checks in order. Each check ends in a resolution or the next check.

Check 1. How many changes are proposed at once?

How: list every edit the client or their team wants: content, titles, redirects, internal links, template, schema.

Why: two or more simultaneous changes mix. The result belongs to none of them, so the result teaches you nothing.

If two or more changes are proposed, go to Check 2. If exactly one is proposed, go to Resolution A.

Check 2. Is one of the changes an emergency?

How: compare the list against the emergency list. The four are: site down, tracking broken, indexing lost, losing revenue.

Why: an emergency cannot wait for a sequence. It goes alone, and the rest queue behind it.

If one change is an emergency, go to Resolution B. If none is, go to Check 3.

Check 3. Can each change be measured on its own?

How: for each change, write the metric it is meant to move and the 28-day window to measure it.

Why: a change you cannot measure alone cannot be attributed. You need one metric per change.

If each change has its own metric, go to Resolution C. If any change has no clear metric, go to Resolution D.

Resolutions

Resolution C in detail

Sequencing follows four rules.

1. Order by impact. The change most likely to move revenue goes first.

2. One per window. Ship one change, wait one full 28-day window, read the result against the baseline, then ship the next.

3. Log each. Every change gets a date, a reason, and a metric in the change log.

4. Hold the rest. Changes wait in the queue. None ship early, even if someone asks.

When to escalate

Escalate when all three are true.

• A client or their team wants to ship more than one change at once.

• We have explained the one-change rule twice.

• They still insist on shipping them together.

We then write the position in the report and do not ship the bundle.