Automation does not fix a broken process. It removes the friction that was quietly slowing the damage down, which means the same mistakes now happen faster, more often, and with nobody in the loop to notice. Clients ask me to automate a workflow almost every week, and roughly a third of the time the real request, once we dig into it, is “make the bad thing worse, faster.”
Why speed makes broken processes worse, not better
A manual process has accidental brakes built in. Someone forgets to send the email for two days. Someone reads the form before forwarding it and catches the obvious typo. Someone escalates the weird case instead of processing it on autopilot, because a human noticed it looked weird. None of that is designed. It is just friction, and friction happens to catch errors as a side effect of being slow.
Automate that same process and the brakes disappear. The email goes out instantly, typo and all. The weird case gets processed identically to every normal case, because the system has no concept of weird. You have not removed the error rate, you have scaled it. If the manual process was wrong 2% of the time, the automated version is wrong 2% of the time at ten times the volume, with no one reading the output closely enough to catch it. That is the industrialisation problem: you have not solved anything, you have built a factory for the mistake.
The diagnostic question to ask before you write any code
Before automating anything, ask whether a careful human, doing this step by step with no time pressure, produces the right outcome every time. If the answer is no, you do not have an automation problem. You have a design problem, and automating around it just locks the design error in place at speed. I walk through this exact check with clients before touching a single tool, because it is the cheapest conversation in the whole engagement and it is the one most consultants skip because it does not look like billable work.
This is also where most of the workflows I build start: not with a trigger and an action, but with a whiteboard session that strips the process down to what actually has to happen, in what order, with what information. Half the time the answer involves deleting two approval steps nobody can explain, before any automation tooling enters the conversation.
What “fix the process first” actually means in practice
Map every step the process currently takes, including the informal ones nobody wrote down. The handoffs, the “I usually just check with Dave first” steps, the exception handling that lives in someone’s head. These are the steps that get lost first when you automate, and they are often the steps doing the actual quality control.
Remove steps that exist for historical reasons rather than current ones. Most processes accumulate steps the way code accumulates dead branches: added for a reason that stopped applying two reorganisations ago, never removed because nobody owns the courage to delete a step that might matter. Ask, for each step, who it protects against and whether that risk is still real.
Define what “correct” means before you automate anything. If the humans running the process by hand cannot agree on what a correct outcome looks like, automating it just means disagreeing faster and at scale, with an audit trail that makes the disagreement expensive to unwind.
Only then does automation add value, because now you are scaling a process that works rather than scaling one that happens to limp along on human attentiveness. This is the order I use in courses and client work alike, and skipping it is the single most common reason automation projects get quietly switched off six months after launch, with nobody willing to say why in the retrospective.
The honest tradeoff
Fixing the process first costs time up front, and that cost is real; it is not a rounding error you can wave away with a roadmap slide. It means slower initial delivery, more workshops with people who would rather you just “build the thing,” and a period where it looks like nothing is happening while you are actually doing the hardest part. The payoff is a system that fails less often and fails more visibly when it does, because you have designed in the checks that friction used to provide by accident.
Skip that step and you get a fast system that is confidently, consistently wrong, which is a harder problem to diagnose later because everyone assumes automation implies correctness. It does not. It implies consistency. Those are different things, and conflating them is the most expensive mistake in this entire category of work. If you are not sure which situation you are in, that is worth a conversation before the build starts, not after.