Process Automation Isn't Always Progress
Automating a task makes it faster and cheaper to run — and far harder to question or change. Sometimes you automate yourself into a process you can no longer escape.
I automate processes for clients, so this is another case of arguing against my own work: process automation is not always progress. Automation is treated as self-evidently good — faster, cheaper, fewer errors, less manual labor — and sometimes it is all of those things. But automation also has a cost that almost nobody prices in: it makes a process rigid, permanent, and very hard to question. Sometimes you automate yourself into a corner you can no longer climb out of.
The trap is that automation feels like the finish line. You ship it, the manual work disappears, and the process freezes into infrastructure that everyone now builds around and nobody dares to touch.
Why the conventional wisdom is wrong
The conventional wisdom is that if a task is repetitive, you should automate it, full stop. But repetitive does not mean settled, and automating a process is a bet that the process is correct and stable enough to be worth freezing. Manual work, for all its inefficiency, stays flexible — a person can adapt, use judgment, and notice when something is off. Automate it and you trade that adaptability for speed, often before you have confirmed the process is actually right.
Automation freezes the current logic in place, so changing the process later means changing code, not just changing a habit.
Edge cases that a human handled with judgment now fail silently or require an engineer to resolve.
The automated process becomes invisible — nobody reviews it — so it keeps running long after it stops making sense.
You lose the institutional understanding of why the process works, because the machine does it and the people forget.
What is actually true
What is actually true is that automation is a commitment, not just an optimization. When you automate, you are not only speeding a process up — you are declaring it stable enough to stop thinking about, and burying it deep enough that changing it becomes expensive. That is the right move for a process that is genuinely settled and unlikely to change. It is the wrong move for one that is still evolving, still being figured out, or only occasionally run, where the flexibility of doing it by hand is worth more than the speed of doing it automatically.
The question is never just "can this be automated." It is "should this be frozen." Some processes should. Many that get automated should not have been — they were automated because automation was available, not because the process was ready.
When automation is the wrong call
Before you automate, check whether you are optimizing a process or imprisoning yourself in it.
Is this process stable, or is it still changing often enough that freezing it will cost more than the manual effort?
Does it run often enough to justify automating, or are you engineering away a task that happens twice a year?
How much does the process rely on human judgment that the automation will not be able to replicate?
If the process needs to change in six months, how painful and expensive will it be to change the automation?
What we see at TTGC
When clients ask us to automate something, the first thing we assess is not whether we can — we almost always can — but whether they should. We have seen organizations automate processes that were still in flux, then spend more time and money fighting their own automation than they ever spent doing the work by hand. The processes worth automating, in our experience, are the boring, stable, high-volume ones nobody argues about anymore. The ones that bite you are the freshly designed processes automated in a rush of optimism, frozen before anyone confirmed they were right. So we now deliberately slow clients down before automating, and sometimes recommend keeping a process manual a while longer — not because automation is hard, but because reversing it is.
The honest take
Automation is a powerful tool, but it is not the same thing as progress. Automating a process makes it faster and cheaper to run and far harder to question or change — so before you automate, make sure the process is stable enough to deserve being frozen. Automate the settled, high-volume, well-understood work, and leave the evolving, judgment-heavy, occasional work flexible until it has earned the commitment. The goal is not to automate everything that can be automated. It is to automate the things that should be — and to keep the freedom to change the rest.
Sources
McKinsey & Company — research on automation strategy and where automation creates versus destroys flexibility. mckinsey.com
TTGC — patterns across client transformation work.
