The automation lie

I know a company that spent six months and a significant budget automating their purchase order approval process. It had 47 steps. Forty-seven. The workflow involved four departments, eleven signatories, and a routing logic so convoluted that the Visio diagram looked like a subway map for a city designed by M.C. Escher. They were proud when they finished. The whole thing ran without human intervention. Requests flowed through the system like water through pipes.

Then someone asked the obvious question: why does buying a $200 monitor require 47 steps?

Nobody knew. The process had accreted over fifteen years. Each step had been added in response to some incident that nobody could remember. Layer upon layer of bureaucratic scar tissue, each one making sense at the time, none of them ever revisited. The real answer was that about six of those steps were necessary and forty-one existed because nobody had ever asked if they should.

They had automated a broken process. And now it broke faster, at scale, with no human in the loop to notice.

This is the automation lie: the belief that the hard work is making a process run without humans, when the actual hard work is figuring out whether the process should exist at all.

Speed amplifies direction

There’s a useful mental model from physics. Velocity is speed plus direction. A car going 100 miles per hour in the wrong direction doesn’t get you there faster. It gets you lost faster.

Automation is the same. It adds speed. It does not add direction. If your process is well-designed --- if it reflects how value actually flows through your organization --- then automation is a tremendous accelerator. But if your process is broken, automation is a tremendous amplifier of brokenness.

The pattern shows up everywhere. A warehouse automated its inventory tracking system. Sensors, RFID tags, real-time dashboards, the whole apparatus. Beautiful technology. But nobody addressed the fact that inventory data was still being entered manually at the receiving dock because the barcode scanner didn’t work with their supplier’s labels. The automated system dutifully tracked inaccurate data across the entire warehouse in real time. They had achieved a perfectly efficient pipeline of garbage.

Most companies don’t have automation problems. They have process problems wearing automation as a disguise.

A hospital network automated their patient intake forms. Before, patients filled out paper forms in the waiting room. After, patients filled out digital forms on a tablet in the waiting room. The data still had to be re-entered by a nurse because the tablet software didn’t integrate with the medical records system. They’d automated the medium (paper to glass) without automating the workflow. The bottleneck moved precisely zero inches.

An e-commerce company automated their customer support with a chatbot. The chatbot handled the easy questions well. But the reason customers were calling with easy questions was that the website’s FAQ was buried three clicks deep and written in corporate legalese that nobody could understand. The chatbot was an automated answer to a question that shouldn’t have needed asking in the first place.

Automating the symptom

These aren’t edge cases. They’re the norm. I’d estimate 70% of automation projects automate a symptom instead of addressing a cause. They take a process that exists because of some upstream failure --- a confusing interface, a broken handoff between teams, a policy that outlived its purpose --- and they make that process faster without ever looking upstream.

The reason is structural. The people who approve automation projects are usually not the people who understand the process deeply. They see a bottleneck, a cost center, a queue that’s too long. They want it fixed. “Automate it” sounds like fixing it. The vendor who shows up with an automation platform has a hammer and everything looks like a nail.

But the question that never gets asked --- because it’s uncomfortable and politically dangerous --- is: should this process exist?

That question threatens people. If you’ve spent five years managing a 47-step approval workflow, you don’t want to hear that 41 of those steps are waste. Your job depends on the complexity. Your expertise is in working the maze. Simplifying the maze makes your expertise irrelevant.

So organizations automate the maze instead of questioning it. They add speed to something that shouldn’t be happening. And they call it digital transformation.

The word “transformation” is doing a lot of heavy lifting in that phrase. What actually happened was digital preservation. They took a broken analog process and preserved it in digital amber, exactly as broken as before, just faster.

The diagnosis before the prescription

The companies that get automation right share one trait: they spend more time on diagnosis than on implementation. They treat the existing process as a hypothesis, not a given. They ask “why does this step exist?” for every step, and they’re willing to hear the answer “it shouldn’t.”

Toyota understood this decades ago. The Toyota Production System wasn’t primarily about automation. It was about understanding flow. Before you automate anything, you map the value stream. You identify which steps create value and which steps create waste. You eliminate the waste. Then you automate what remains.

The order matters enormously. If you automate first, you lock in the waste. It becomes part of the system. It gets dependencies. Other automated processes connect to it. Removing it later costs ten times what eliminating it before automation would have cost.

This is why the most impactful work in any automation project is boring. Sit in a room with the people who actually do the process. Ask them to walk through it step by step. Not the manager who designed it. Not the executive who approved it. The person who does it every day and knows exactly which parts are pointless but has never been asked.

The best automation is often subtraction. Not “how do we make this faster?” but “why are we doing this at all?”

There’s a company that ships physical products and used to have a twelve-step returns process. Before jumping to automation, they spent two weeks interviewing warehouse staff and customer service agents. They found that eight of the twelve steps existed because of a policy from 2014 that was written in response to a fraud incident that involved exactly one customer. That customer was long gone. The policy remained. Eight steps of overhead, years of wasted time, because nobody had revisited a decision made in response to a single bad actor.

They didn’t automate the returns process. They redesigned it to four steps and automated those four. The result was faster, cheaper, and better for customers than any automation of the twelve-step version could have been.

The AI acceleration of the same mistake

This matters more now than ever, because AI is the most powerful automation technology in history. It can automate processes that were previously too complex, too unstructured, or too variable for traditional automation. And that means it can automate broken processes that were previously too complex to automate.

Before AI, some processes were protected from bad automation by their own messiness. You couldn’t automate a broken process if the process involved judgment calls, unstructured data, or exceptions that didn’t fit into a flowchart. Humans absorbed the brokenness. They worked around the dysfunction. They used their judgment to navigate the gaps.

AI removes that protection. It can handle the judgment calls. It can process unstructured data. It can manage exceptions. Which means the barrier between a broken process and automated-broken-process has been demolished. The things that were too messy to automate badly can now be automated badly at incredible speed.

A company that couldn’t previously automate their chaotic procurement process because it required too much human judgment can now hand it to an AI agent. The agent will faithfully execute all 47 steps, including the 41 that are waste, with superhuman speed and consistency. It will produce a flawless record of perfectly pointless work.

This is the new frontier of the automation lie. Not just “we automated a broken process” but “we used the most sophisticated technology in human history to automate a broken process, so it must be right.”

The sophistication of the tool creates a dangerous halo effect. If a simple script automates something, people might question the process. If an AI agent with natural language understanding and adaptive reasoning automates it, the technology’s impressiveness obscures the process’s brokenness. The tool is so smart that the process seems smart by association.

What the work actually is

The real work of automation, the work that creates lasting value, isn’t technical. It’s organizational, political, and analytical. It’s the work of understanding what your organization actually does versus what it thinks it does. It’s mapping the gap between the stated process and the real process, between the org chart and how decisions actually get made, between the policy manual and what people do on a Tuesday afternoon when the policy doesn’t quite apply.

This work is hard because it requires honesty. Every organization has processes that exist for political reasons, not functional ones. Every organization has steps that exist because of a single past failure that nobody wants to revisit. Every organization has workflows that were designed for a context that no longer exists but that nobody has updated because the cost of understanding the whole system feels higher than the cost of living with the dysfunction.

Automation vendors won’t tell you this. Their incentive is to automate what exists, not to question it. They bill by the workflow automated, not by the workflow eliminated.

The right question before any automation project is not “how do we automate this?” It’s three prior questions: Does this process need to exist? If yes, does it need to exist in this form? If yes, then how do we automate it?

Skipping the first two questions and jumping to the third is how you end up with a perfectly automated system that makes your organization worse at an impressive rate.

The most expensive automation is the kind that works perfectly on a process that shouldn’t exist.

The 47-step approval process didn’t need 47 automated steps. It needed someone with the authority and the courage to say: we only need six of these. Kill the rest. Then automate the six.

That’s not an automation project. That’s a thinking project. And thinking is the part most organizations skip, because it’s hard, slow, and doesn’t come with a vendor demo.