When not to automate: the most dangerous words are "the pilot worked"
The pilot always works. The real question arrives three months later: who fixes it when it breaks at three in the morning, and will anyone even notice?
The most dangerous sentence in automation projects is not "the pilot failed". It is "the pilot worked".
Pilots always work. They are built in ideal conditions, on clean data you selected yourself, with the engineer who built it sitting in front of it. And a decision made on that success ignores the only question that matters: who fixes it eight months from now, when its author has left, and it breaks at three in the morning on a public holiday?
Five things not to automate
A task whose rules keep changing. Automation freezes a decision at a moment in time. If the rule changes every two months, you are building something you will rebuild forever.
A task that happens five times a year. Two hours a year does not justify a system that needs maintaining. The correct comparison weighs time saved against build time plus maintenance plus time lost when it breaks.
A task whose errors are not detectable. This is the dangerous one. An automation that fails loudly is annoying but safe. One that fails silently accumulates damage for months.
A task whose value is the relationship, not the output. A follow-up message to an important client is not text being delivered; it is a signal that you set aside time. Automating it succeeds technically and fails at its purpose.
A task you do not understand well. Automating a vague process produces vagueness faster. If you cannot explain the steps to a new colleague, you cannot explain them to a machine.
The hidden cost, in numbers
When weighing an automation, most people compare build time against time saved. That equation is incomplete.
Building is a quarter of the work. Anyone deciding on the build estimate alone is wrong by a factor of four.
The test before you start
That last line matters. Most tasks are not all-or-nothing: the tedious part gets automated and the sensitive part stays human.
The third way: half automation
The choice is not between fully manual and fully automatic. In most cases the best design is the machine prepares, the human decides.
| Model | Who does what | Suits |
|---|---|---|
| Fully manual | The human does everything | Rare and high impact |
| Machine suggests | Prepares a draft, human edits and sends | Most real cases |
| Machine acts with review | Executes and reports, human reviews periodically | Frequent and low risk |
| Fully automatic | No human involvement | Very frequent, cheap failure |
The second row is the one whose value is consistently underrated. Saving eighty percent of the time while keeping the decision human gives you most of the benefit at a fraction of the risk.
In closing
Good automation is measured by what it removes from your work, not by what it adds to it. A system saving two hours a week and consuming three in maintenance is not automation. It is an expensive hobby.
Start today with an audit: list every automation running for you now, and beside each one the name of whoever would fix it if it broke today. The blanks you find are your real risk.
And if you want a clear decision framework for your team, separating what to automate from what to leave alone, that is what we build in the training programmes.
Common questions
- What is the most important question before automating something?
- Who fixes it when it breaks, and how will they know it broke. If neither has a specific person's name as the answer, the automation will become a liability rather than a gain.
- How do I calculate whether an automation is worth it?
- Compare time saved against build time plus maintenance plus time handling failures. Building is usually under a third of total effort, so anyone estimating from the build alone is wrong by a multiple.
- What is the most dangerous kind of automation?
- One that fails silently. An automation that stops loudly is annoying but safe; one that produces wrong results with no notification accumulates damage for months before anyone notices.
- What is the alternative to full automation?
- Half automation: the machine prepares a draft or recommendation and a human reviews and decides. That captures most of the time saving while keeping human judgement in the loop, and it suits most real cases.
- Should I automate client communication?
- Where the value is in the output, yes. Where the value is in the relationship, no. A follow-up to an important client is valuable because you gave it time, and automating it succeeds technically while failing at its purpose.
No comments yet
Leave a comment