What Most Companies Get Wrong About Automation

The default instinct with automation is to find a painful, repetitive process and make it run on its own. Someone hates doing the thing, so you build a script or a workflow that does the thing, and now the thing happens without them. It feels like progress. Often it is the wrong move, because you have just made a process you never questioned permanent. The most valuable automation question is not “how do we make this run automatically.” It is “should this run at all.”

I have watched a lot of automation projects, built a fair number, and killed more than I shipped. The failures almost always shared a shape. They took a workflow that existed for a reason nobody remembered, wrapped it in tooling, and locked it in. Now it runs ten times faster and removing it is ten times harder, because automation has a way of turning a habit into infrastructure. So the work starts before the build.

Delete before you automate

Most processes accreted. Someone needed a report in 2019, so a manual export was born, and it survived every reorg since by sheer inertia. The first pass on anything I am asked to automate is archaeology: who actually consumes this output, what decision does it feed, and what breaks if it disappears. A surprising fraction of the time the honest answer is “nothing breaks.” The report goes to an inbox nobody reads. The step exists to satisfy a check that was removed two years ago. The cheapest automation is deletion, and it is the one nobody gets excited about because there is nothing to demo.

Automate the decision, not just the task

Here is the trap that catches good engineers. You automate a task, but the task still produces output that a human has to look at and interpret before anything happens. You did not automate the work — you relocated it. The person used to gather the data; now they read a dashboard and decide. The toil moved one step downstream and put on a nicer outfit.

Real leverage is in encoding the decision: the rule, the threshold, the routing logic. When this metric crosses this line, do this. When a ticket has these properties, send it here. That is the part that compounds, because a decision that runs in code runs the same way at 3pm and 3am, for the first case and the ten-thousandth. The honest test of an automation is whether it removed a judgment call a human was making by hand, not whether it removed some typing.

This is also where it gets uncomfortable, because encoding a decision forces you to make the decision explicit. Half-formed human judgment that “you just know” has to become a rule you can write down and defend. Often that exercise reveals the judgment was inconsistent all along — three people were routing the same case three different ways. The automation does not just save time. It makes the policy real, which is sometimes the actual deliverable.

Measure before you build

If you cannot say how often a thing happens and what each occurrence costs, you cannot say whether automating it is worth the build plus the maintenance forever. And the maintenance is forever — every automation is a small liability that needs care when an API changes or a downstream system moves. The measurement usually reveals that the loudest pain is not the most expensive one. The person yelling is yelling about a thing that happens twice a month. The expensive thing is the quiet daily tax nobody complains about because they have stopped noticing it.

Keep a human where the cost of being wrong is high

Full automation is not the goal, and the reflex toward it has burned people. The goal is a smaller surface area of work that needs a human at all — and keeping the human exactly where their judgment is worth the latency. Route the obvious 80 percent automatically. Escalate the ambiguous 20 percent to a person with the context already assembled, so the human spends their attention on the decision instead of the gathering. A good automated system is not one with no humans in it. It is one where every remaining human touch is a real judgment call and not a clerical chore a computer should have handled.

So when someone asks me to automate a process, the build is the last thing we talk about. First: can we delete it. If not: what is the decision hiding inside the task. Then: how often and how costly. Then, and only then, do we write any code. The companies that get this wrong end up with a faster version of a workflow they should have questioned. The ones that get it right end up with less work in the building, not just quicker work — which was the whole point of automating in the first place.