When to start worrying about automating the decision, not the keystroke

Somewhere between a principle and a habit sits the useful kind of rule: right most of the time, and wrong in ways you'll notice straight away. This is one of those.

Most automation projects reproduce the steps a person took, which locks in a process designed around a limitation that no longer applies. The work worth removing is the deciding, not the typing.

THE STEPS ARE AN ARTEFACT

When you watch someone do a task, what you see is the task plus the shape of the tools they had. Copy all of it and you've automated the workaround too, including the export, the reformat, and the re-import that only exist because two systems don't talk.

The question that gets past this is embarrassingly simple: what is this person deciding? Usually it's one or two judgements buried in twenty minutes of mechanical shuffling. Automate the shuffling and you've saved eighteen minutes. Understand the judgement and you can sometimes remove the whole task.

WHERE THE JUDGEMENT ACTUALLY IS

You find it by asking what would change their answer. If nothing would, if the outcome is determined entirely by the inputs, it isn't a judgement, it's a rule nobody has written down, and it belongs in code with a name.

If something would change it, that's real judgement, and it deserves to stay with a person. What you can do is bring them everything they need in one place and remove the twenty minutes of gathering. That's usually a bigger win than the automation anyone asked for.

Checked against credit operations: at around 2,500 applications a month it holds comfortably. It'd start to wobble an order of magnitude higher, where the fixed costs it ignores stop being small.

SPEEDING UP THE WRONG PROCESS

The failure mode is a faster version of a process that shouldn't exist. It's hard to spot afterwards because the metrics improve: the task takes less time, throughput's up, everyone's pleased. The unnecessary work just happens more efficiently now.

The way we avoid it is to insist on describing the outcome the task produces before designing anything. Then ask whether there's a shorter route from the inputs to that outcome. Sometimes there is, and it doesn't resemble the original steps at all.

The rule would have caught an approval was issued against a stale valuation and didn't, because nobody applied it to the integration written under deadline. That's the usual story. The heuristic is fine, the coverage isn't.

WHERE IT GOES WRONG

• Removing the person from the one step that genuinely needed judgement.
• Automating an export-and-reimport that only existed because two systems couldn't talk.
• Encoding a rule nobody had written down, so its logic is now in a script with no name.
• A faster version of a process that shouldn't exist, with metrics that look like success.

Find the decision. Automate the gathering, and leave the judgement with a person.

WHEN THE RULE FAILS

Treat it as a prompt to think, not a substitute for thinking. Its job is to stop the same conversation happening a fourth time, not to end it.