Before You Automate Anything, Ask This Question

A few years ago, I sat in a production planning meeting at a mid-sized industrial manufacturer. The operations team was pitching an automation initiative, a workflow tool that would route approval requests, trigger notifications, and generate status reports without anyone touching a spreadsheet. The presentation was clean. The ROI model looked reasonable. Everyone in the room was nodding.

Then someone asked how long the approval chain had existed. Silence. Nobody was sure. It had grown, over the years, as the company added product lines and the accountability for those lines stayed murky. Every time a decision fell through the cracks, someone built a workaround. Over time, the workarounds calcified into process. And now they were about to automate all of it. That meeting is what I think about whenever a client comes to me with an automation initiative already half-designed.

Making things faster feels like progress

There is a particular seduction to automation, and it has nothing to do with technology. It is the feeling of momentum. When you show an executive team a demo of a workflow that used to take three days running in forty-five minutes, the room changes. People lean forward. That feeling is real but it is not the same thing as value creation.

Speed is neutral. If a process is producing the right outputs, faster is better. If it is producing the wrong outputs, faster just means you find out you have a problem at a larger scale and with more consistency. A broken process that runs slowly at least gives you time to notice it is broken. A broken process automated is a broken process institutionalized.

Most organizations, when they inventory their workflows for automation candidates, are actually inventorying their operational history, every patch, every workaround, every decision that was never quite made.

The specific failure mode: automating the workaround

Operational workarounds are rational. Someone needed to get work done, the existing system did not support it cleanly, so they built a path around it. That is good problem-solving in the moment. The problem is that workarounds, over time, look exactly like processes. They have steps. They have owners. They have outputs. What they do not have is a legitimate reason to exist.

When you automate a workaround, you do two things simultaneously. You make the underlying problem harder to see because the friction that used to signal something was wrong is now gone. And you make the workaround harder to remove because now it is embedded in a system with dependencies.

This is how organizations end up with automated approval chains that no one can explain, automated reports that no one reads, and automated notifications that everyone filters into a folder they never open. The technology worked exactly as designed. The problem was never the technology.

The question worth asking

Before any automation decision, I ask one question: "If we were designing this business from scratch today, would this workflow exist?"

Not "does it exist" — it obviously does. Not "is it necessary given our current constraints" — of course it seems necessary, everything does once it is embedded. The question is whether it would survive first-principles scrutiny. If the answer is no, or even "probably not," that is a signal to stop and do organizational design work before technology work.

In the manufacturing example I described, the answer was clearly no. A company designed from scratch today, with clearly assigned product-line ownership, would not need a seven-step approval chain for a procurement decision under a certain dollar threshold. That chain existed because authority had never been formally allocated. Automating it would have locked in the ambiguity.

Map decisions before you map tasks

The practical alternative is to start not with workflow documentation but with decision mapping. Where do the decisions that actually drive business outcomes get made? Who has authority? Where does accountability sit? What decisions are being made informally, in hallways, in Slack threads, in the five minutes before a meeting starts, that should be formalized?

Once you have that picture, you can look at your automation candidates differently. Some of them will still belong on the list. Others will reveal themselves as machinery built around decisions that were never properly made. Those need leadership attention, not software.

Before your next automation conversation, ask your team this: "What would we have to believe about this company's structure for this workflow to be the right one?" If the answer requires assumptions that are not actually true, you have found something worth fixing before you spend a dollar on tools.

That question will not appear on any vendor's demo agenda. That is precisely why it is worth asking.