When Two People Do the Same Job Differently

Two people run the same process and produce different results. The instinct is to see a discipline problem and issue the correct version.

That's usually the wrong first move. Variance is information before it's a problem — and one of those two versions is quite often better than the one you'd have written.

Find it by watching, not asking

Ask someone how they do a task and you'll get the official version, or their memory of it, or what they think you want to hear. None of those is the version that happens.

Watch instead:

• Sit with each person while they run it. Write what they do, not what they say they do, and resist correcting mid-flow.
• Compare outputs. Two invoices, two onboarding folders, two reports. Differences in the artefacts point straight at differences in the process.
• Look at timing. If it takes one person twenty minutes and another an hour, something material differs.

This is the same discipline as mapping a process, applied to more than one person.

Ask why before you decide

For each divergence, one question: why do you do it that way?

The answers fall into four categories, and they need different responses.

| Answer | What it is | What to do | |---|---|---| | "It's faster and here's why" | An improvement | Adopt it | | "The official way breaks when [case]" | A gap in the standard | Fix the standard | | "I didn't know there was another way" | A training or findability gap | Fix the documentation | | "No reason, that's just how I started" | Drift | Standardise |

Only the last one is what people assume all variance is. Skipping the question and going straight to enforcement means you frequently standardise on the worse version, and you lose the improvement the person had made.

It also costs you the next one. Someone whose improvement gets overwritten without being asked about doesn't offer the next.

Standardise outputs first

The instinct is to standardise steps. Start further out.

Standardise the output — what must exist at the end, in what format, meeting what criteria. That's what the next person or the customer actually depends on.

Standardise the constraints — what must not happen, what must be checked, what needs approval, the deadline.

Then, only if it still matters, standardise the steps.

For a lot of work, output plus constraints is enough. If two people produce identical correct results by different routes in similar time, the route may not be worth legislating — and legislating it costs you the flexibility that lets each person work well.

Where the route does matter — regulatory requirements, safety, a step whose omission causes a downstream problem — standardise it explicitly and say why. A step with a stated reason survives; a step that looks arbitrary gets dropped the first busy week.

Some variance should stay

Standardising judgement-heavy work makes it worse, not better.

Client conversations, complaint handling, prioritisation calls, anything where the right answer depends on context — forcing a single script produces worse outcomes and frustrated people.

The format for that work is a playbook: principle, options, escalation point. It standardises the reasoning while leaving the response to the person in front of the situation.

A rough test: if you can write down what the output must be, standardise the output. If you can only write down what a good decision looks like, write a playbook.

Drift is feedback

You standardise, everyone agrees, and within two months people have drifted back.

The reflex is to enforce harder. Ask first — sustained drift almost always means the standard is wrong in a way that wasn't visible when it was written:

• It doesn't handle a case that occurs regularly
• It's slower with no visible benefit
• It was written by someone who doesn't run it
• The tool changed underneath it and nobody updated the document

Drift is your process telling you something. Go and watch again, and treat the third version as the honest one.

Do it with them, not to them

The practical difference between standardisation that holds and standardisation that doesn't:

• Map together. The people who run it know things you don't.
• Show the comparison. Put the two versions side by side. Differences become obvious without anyone needing to be told they're wrong.
• Let them decide where you can. Someone who chose the standard defends it. Someone who was handed it complies until they're busy.
• Say why for anything non-obvious, especially constraints.
• Give it a review date. A standard that can be revisited is one people will raise problems with rather than quietly ignore.

The mistakes

1. Enforcing before asking why. You standardise on the worse version and lose the improvement.
2. Asking rather than watching. You get the official version, not the real one.
3. Standardising steps first. Output and constraints usually carry it.
4. Flattening judgement work. Produces worse outcomes and resentment.
5. Treating drift as indiscipline. It's usually a defect in the standard.
6. Writing it alone. It won't survive contact with the people who run it.

What to do next

Take one process that two or more people run and watch each of them do it once. Write down every difference, then ask why for each. The list of "no reason, that's just how I started" items is the real standardisation work — and it's usually much shorter than expected.

The improvements you find in the other three categories are worth more than the standardisation itself.