I have an unusual position for someone who helps businesses implement technology: I spend a significant portion of my time convincing clients not to automate things.
Not because automation is bad. It is often transformative. But because automating the wrong thing, at the wrong time, or in the wrong way is expensive, hard to undo, and sometimes makes the underlying problem worse. And the pressure to automate, from boards, from vendors, from the general direction of the market, can make it hard to have an honest conversation about when it is actually the right answer.
The cases where automation makes things worse
When the underlying process is broken
This is the most common mistake I see. An organisation has a process that is inefficient, inconsistent, or producing poor results. The response is to automate it. But automation does not fix a broken process, it embeds it. And it makes the brokenness harder to see, because the automation creates an impression of rigour and control that the actual process does not have.
Before automating any process, the honest question is: if we ran this process perfectly, manually, would it produce the result we want? If the answer is no, the process needs to be fixed before it is automated. If the answer is yes, then automation may genuinely add value.
When the variation in the process exists for good reasons
Some processes look inconsistent but are actually adaptive. Experienced people handle the same type of situation differently because the situations are genuinely different in ways that the process description does not capture. The variation is not a problem to be eliminated, it is expertise in action.
I have seen automation projects that took a process performed consistently well by experienced people and replaced it with a rigid rule that handled 80% of cases adequately and 20% of cases badly. The 20% who experienced the bad handling were usually the most complex cases, the ones that needed the expertise most.
Before automating a variable process, the question is: does the variation represent inconsistency (a problem) or adaptability (a feature)? The answer requires talking to the people doing the work, not just looking at the output data.
When the process is changing
Automation is most valuable when a process is stable and well-understood. It is least valuable when the process is in flux, when requirements are changing, when the business is evolving rapidly, when there is genuine uncertainty about what the right approach is.
Automating a process that is changing locks in the current version of the process. It creates technical debt every time the process needs to change. And it can make the organisation slower to respond to change than if it had maintained the manual flexibility.
The better approach in periods of change is often to standardise the process carefully but keep it manual, then automate once the process has stabilised. This is slower and less exciting than full automation from the start. It is also significantly less risky.
"The question is not whether we can automate this. It is whether we should, and now, or later."
When the time and cost of automation outweigh the benefit
This sounds obvious, but it is genuinely underestimated. Automation projects regularly take longer and cost more than planned. The maintenance of automated systems requires ongoing investment. And the benefit calculations at the start of a project often assume adoption rates and efficiency gains that do not materialise.
A thorough cost-benefit analysis, one that includes realistic estimates of implementation cost, ongoing maintenance, and the cost of the process disruption during the transition, will sometimes show that the manual process is actually less expensive. Particularly for processes that are infrequent, highly variable, or performed by a small number of people.
Signals that automation is the right answer
With all of that said, there are clear signals that automation will genuinely add value.
The process is performed frequently, by many people, and requires following consistent rules. The manual steps are straightforward but time-consuming, data entry, document routing, standard calculations. The process has a well-understood happy path with limited meaningful variation. Errors in the process are common and have significant consequences. And the people currently performing the process would genuinely benefit from having that time back for more valuable work.
When these conditions are met, automation can be transformative. It reduces errors, speeds up response times, frees up skilled people for higher-value work, and creates a documented, auditable record of what happened and when.
The question I always ask
When I am asked to help automate a process, the first question I ask is: what problem are we actually trying to solve? Sometimes the answer is "we want to do this faster." Sometimes it is "we want to do this more consistently." Sometimes it is "we want to reduce our dependence on specific people." And sometimes it is "our competitor has automated this and we feel like we should."
The last one is where I push back hardest. Automation because others are automating, without a clear understanding of what problem it is solving and how it will solve it, is how organisations end up with expensive systems that nobody uses and processes that are harder to understand than the manual versions they replaced.
Automation is a tool. Like any tool, its value depends entirely on whether it is the right tool for the specific job at hand.
If any of this resonates with a challenge you are facing, I would be happy to have a direct conversation. No commitment, no agenda.