There is a rule I apply before building any automation that other people will depend on, and it has saved me from a lot of expensive regret. The rule is simple: run the process manually for two weeks first. Not because I enjoy manual work, but because if I cannot describe the process clearly in that time, the automation will embed the confusion in code, and code is far harder to argue with than a spreadsheet.
The Assumption That Gets Teams Into Trouble
Most automation projects start from the right place. Someone is doing something repetitive and painful. The logic flows naturally: if we automate this, we remove the pain. If we remove the pain, things get better. It sounds airtight.
The problem is the gap between "repetitive" and "sound." A lot of processes become repetitive because nobody ever stopped to ask whether they should exist in their current form. They accumulated over years of adding steps and workarounds until nobody remembered the original intent. Then somebody decided to automate them.
When you automate a sound process, you multiply its output. When you automate a broken one, you multiply the breakage. The speed gain is real. So is the damage.
What Happens When You Wire a Bad Process Into Code
When I was building out automation workflows for a large international NGO, I inherited a ticket routing setup that had been pieced together over three years. Tickets came in, got tagged, and routed to one of four teams. The tagging logic was based on an org chart that had been restructured twice since the logic was built. Roughly one in four tickets went to the wrong team. The team receiving them had been manually re-routing them for so long it had become a standard part of their workday. Nobody flagged it as a problem anymore. It was just how things worked.
The instinct from nearly everyone I consulted was: automate the routing. Add a cleaner classification layer, plug in a model to read the ticket, send it to the right place faster.
I almost did it. Then I asked a different question: why does the tagging logic exist at all? The answer turned out to be that nobody knew. It had been designed for a support structure that no longer existed.
Automating that routing would have made the wrong tickets arrive at the wrong teams faster, with less room to notice the error, because teams would have trusted the automation. We rebuilt the routing logic from scratch before writing a single workflow node.
Three Signs the Process Is Not Ready to Automate
1. The logic has more than roughly eight exceptions. Every automation has exception paths. A few are normal. But when I start mapping a process and the exception list hits eight or more, I stop. Exceptions are usually a sign that the base logic does not accurately describe what actually happens. The exceptions are the real process. Automating the stated logic while tacking each exception on as a special case builds technical debt into the foundation of the workflow.
2. Someone is currently "fixing" the process rather than running it. There is a difference between maintaining an automation and correcting it. If a human has to intervene periodically to redirect its output, not because of a new edge case but because it gets familiar inputs wrong, the underlying logic is broken. Automating something that already needs correction is automating a moving target. The automation does not remove the need for correction. It just hides where the correction is happening.
3. The outcome metric has been flat for months despite manual effort. If ticket reopen rate, escalation rate, or whatever you care about has not improved despite people working on the process manually, that is a signal. The process structure is not producing improvement even with human judgment applied to it. Automating it will not add judgment back. It will just remove the person who was partially compensating for the structural problem.
Why the Cost Compounds Once Automation Runs
Once an automation runs in production, it does something critical: it becomes the norm. Teams stop questioning the process because the process is running automatically. The person who used to manually re-route wrong tickets is no longer doing it. The institutional knowledge that something was off begins to fade.
Six months into a broken automated process, you typically find a queue of edge cases handled outside the automation with no documentation on why. Reports that look accurate because the automation completes successfully but measure the wrong thing. And strong resistance to changing the flow, because everyone who depends on it has built their own work patterns around its outputs.
Fixing a broken manual process requires changing a habit. Fixing a broken automated process requires changing a production system and also changing the habits of everyone who adapted to it.
The cost compounds. The window to catch it closes. I have seen teams spend more time unwinding a badly-designed automation than they ever saved by building it.
The Case for Automating First (And Why I Still Disagree)
I have heard the counter-argument from people I respect. The argument: automation is actually a great way to surface what is broken. When you try to write the logic explicitly, you are forced to articulate every step, every exception, every edge case. The act of automating becomes the process discovery.
There is something real in this. I have learned things about a process by trying to automate it that I would not have seen otherwise. When you have to tell a system exactly what to do, ambiguity becomes visible in ways it is not when a human is smoothing things over.
But there is a difference between prototyping to discover and deploying to run. A quick, throwaway draft you run yourself for two weeks to map the real shape of a process is one thing. Shipping that as production infrastructure, with other people's work depending on it, before you have validated the logic, is another entirely. Discover by automating. Deploy only what you have validated.
The Two-Week Rule and What Comes Before Any Workflow
Before I build any automation that other people will depend on, I do three things.
I run the process manually for at least two weeks and write down every exception I encounter. Not to be thorough for its own sake, but because two weeks of real traffic catches patterns that a design session or a kickoff call does not. The exceptions that appear in week two are almost always the ones that kill the automation in month three.
I write the process in five steps or fewer. Not a detailed standard operating procedure, just five steps. If I cannot summarize the logic in five steps, the process is either too complex or too undefined. Both states are problems to fix before the first workflow node gets created.
I look at the outcome metric before I start. If the number I care about is flat or trending wrong under manual operation, I fix that first. Automation should accelerate improvement. It is not a substitute for it.
This takes more time upfront. It has never taken more time overall, across the full life of the thing I built.
Where I Would Push Back on Myself
The strongest objection to this rule is about speed. Teams are under pressure to ship automation because stakeholders want the dashboard number. "We automated the process" is a clean, defensible answer in a quarterly review. "We spent two weeks documenting it first and found it was broken" is a harder conversation to initiate, even when it is the right one.
I do not have a clean answer to the political problem. What I can say is that the teams I have seen recover well from bad automation are the ones who held the line early. The teams I have seen spend a year unwinding a broken workflow are usually the ones who moved fast to show progress on something that was not ready.
If you have built automation first and fixed the process underneath it later, and it worked out cleanly, I want to hear how. Specifically: at what point did you discover the broken logic, and what did it cost to fix in production? That answer usually lands differently than people expect.
For the teams I work with, the rule stays: understand the process first. Automate what you have actually understood. Questions welcome at felixmaru.com/contact.
Comments