Why I never automate a broken process

The rule

Fix first, then improve. I never automate a broken process. I fix it, I understand it, and only then do I decide whether automation makes it better.

This sounds obvious written down. It is violated constantly, because automation is most tempting exactly when a process is painful — and a process is usually painful because it is broken.

What automation actually does

Automation does not improve a process. It repeats a process, faster, more often, and without anyone watching. That is the whole of it.

If the process is sound, repetition is a gift: the thing gets done at 3am on a holiday weekend without you. If the process is unsound, repetition is a machine for manufacturing the same mistake at scale, silently, until someone notices weeks later.

An example from my own systems

I once had a backup job that reported success every night. Green light, clean log, no alerts. It had been transferring nothing for days — a permissions problem meant it could not write its own lock file, so it exited cleanly having done no work.

The automation was flawless. It ran on schedule, it never crashed, and it told me it had worked. The underlying process was broken, and automating it had done nothing but make the breakage invisible and regular.

The honest test

Before you automate anything, do it by hand three times, deliberately, writing down what happens. If you find yourself improvising, guessing, or fixing something small each time — the process is not ready. Those improvisations are the process. A script cannot improvise.

The exception people ask about

“What if it is broken because it is manual?” Sometimes true — a task done inconsistently by five tired people at the end of a shift may genuinely be fixed by a machine doing it the same way every time. But notice what you are actually fixing: consistency, not the process. You still have to know what the correct steps are before you can make a machine repeat them.