It is the most reasonable-sounding advice in modern business: if something is slow, automate it. Software is cheap, AI is cheaper, and every hour you hand to a machine is an hour you get back. Almost nobody argues with it. That is exactly why it deserves a second look.
Automate the slow thing. Put a bot on the repetitive thing. Let the model handle the tedious thing. The instruction is everywhere, and it is mostly right about the destination. What it quietly skips is the question that decides whether you arrive: is the thing you're automating actually any good?
Before we take the dogma apart, let's give it its due.
The grain of truth
Automation works. A task that a person repeats forty times a week, identically, is a task a machine should own. Humans are bad at monotony and machines are bad at nothing else. If you are still copying numbers between two tabs by hand, stop reading and go fix that. We have written about automating the boring parts for exactly that reason, and we stand by every word.
For a one-person business, it is not even optional. You cannot out-hustle a team of ten with two hands. The only way to compete is to let tools carry the load. So no, this is not an argument against automation. It is an argument about order.
The part the slogan leaves out
The sharpest version of the warning predates the current AI wave by decades. A line widely attributed to Bill Gates, from his 1999 book Business @ the Speed of Thought, puts it plainly: automation applied to an efficient operation will magnify the efficiency; automation applied to an inefficient operation will magnify the inefficiency.
Read it again, slowly, because the machine does not read it for you. A tool has no opinion about your process. It does not notice that step three exists only because of a mistake someone made in 2019. It does not ask why the approval goes through two people when one would do. It takes whatever you hand it and does it faster, more often, and without tiring.
That is the whole trap. Automation is a multiplier, and a multiplier does not care about the sign of the number it multiplies.
Picture a small agency whose onboarding is a mess: a welcome email, a form that asks for the same details the sales call already collected, a second form for the details the first form forgot, and a manual hand-off nobody owns. Automate that, and you get the same mess, delivered instantly, to every new client, at any hour. Before, the confusion arrived at a human pace and someone could catch it. Now it arrives at machine speed, and nobody is watching.
What the evidence says about where projects go wrong
Be careful with the scary statistics. You will see dramatic failure rates for automation and AI projects repeated across the internet, and the numbers vary wildly depending on who is quoting whom. Treat any single figure with suspicion, including the ones that would flatter this article.
What is better documented is the pattern. In 2024, RAND Corporation published a study based on interviews with 65 experienced data scientists and engineers about why AI projects fall short. Its first-listed root cause was not bad technology. It was that business stakeholders often misunderstand, or miscommunicate, what problem needs to be solved. The report also noted that models are frequently optimized for the wrong metrics or fail to fit the real business workflow.
Notice what that is describing. Not a failure of the machine. A failure of the question put to it. The tool did precisely what it was told, on a process nobody had examined.
Insight
A machine can only be as good as the instruction it receives, and most bad automation is a good tool executing a bad instruction flawlessly.
Why we keep doing it anyway
Because fixing a process is uncomfortable and automating it feels like progress.
Examining your workflow means admitting parts of it are wasteful, and some of those parts are yours. It means deleting steps you built. It means a few awkward hours staring at something you have stopped seeing. Buying a tool, by contrast, is a clean, satisfying afternoon with a visible result. It scratches the itch to do something.
There is a name for the feeling, and it is rarely flattering: motion dressed up as progress. It is cousin to the reflex we described in Busy Is a Choice You Blame on Everyone Else. Activity is easy to measure and easy to feel good about. Whether the activity should exist at all is a harder, quieter question, so we skip it.
There is a second reason, specific to this moment. AI has made automation so frictionless that the cost of starting has collapsed. You can wire up a workflow in an evening with free tools and no code. That is wonderful. It also removes the natural pause that used to force a plan. When building was expensive, you had to think first. Now you can build first and think never.
Mark the line before you start the machine. The cut will follow whatever you drew.
The truer rule: fix the line, then power it
The useful version of the advice is only three words longer. Not "automate it," but understand it, simplify it, then automate it.
The middle step is the one that pays. Before you automate anything, ask whether it should exist. Deleting a step costs nothing to run and never breaks. Many tasks that feel like candidates for automation are really candidates for removal: the report no one reads, the approval that never says no, the meeting that exists because the last meeting did.
Then simplify what survives. Cut the hand-offs. Collapse the duplicate forms. Make one person responsible for each outcome. A process that a new hire could run from a one-page description is a process ready to automate. One that needs a veteran to explain the exceptions is not.
Only then bring in the machine. And here the order matters again, because the same logic applies to how you instruct an AI. A vague, contradictory brief produces vague, contradictory work at scale. We went into this in Stop Yelling at Your AI: the quality of the output is bounded by the clarity of the instruction, and no amount of capital letters repairs a muddled idea. It is also why a great assistant spends more time understanding the situation than executing the task.
A quick test before you automate
You do not need a consultant. You need ten minutes and an honest pen.
- Walk it by hand once. Do the process yourself, start to finish, and write down every step as you actually do it, not as you remember it. The gap between the two is your first finding.
- Ask "why" three times per step. If the answer ends in "that's how we've always done it" or "I'm not sure," the step is a deletion candidate.
- Count the exceptions. If you keep saying "except when," the process is not ready. Automation handles rules, not folklore.
- Name the outcome, not the activity. "Send the invoice" is an activity. "Get paid within seven days" is an outcome. Automate the path to the second one, and you may find the first was never the point.
- Keep a human on the first run. Watch it work a few times before you trust it. When an automated process fails, it fails quietly and repeatedly, which is why someone still has to be responsible for what it does.
Where automation really earns its keep
None of this makes the machine less valuable. It makes it more valuable, because you are now pointing it at something worth multiplying.
Consider the small tasks you do for nothing that quietly eat your week. Once they are examined and simplified, handing them off is where the real leverage lives. The same is true of the structural point made in The Less a CEO Does, the More the Company Grows: you step back successfully only from work that is clear enough to hand over. That clarity is exactly what the simplification step produces.
It also changes the economics. A clean process automated well can give a solo founder the output of a small team, and it is often the quiet source of the margin you already have but cannot see. The same machine that magnifies a mess will magnify a good system just as faithfully. You are choosing which one you hand it.
This is also why the durable skill is judgment rather than tooling. We made that case in The Skill That Replaced Knowing the Syntax: operating the tool is the easy part now, and deciding what deserves to be done is the part that stays human. Even the time you spend on this thinking is well spent, as we argued in Presence Is Cheap. Timing Is Everything. The question is never how much a machine can do. It is what is worth asking it to do, and when.
What to do Monday morning
Pick one process you were about to automate. Just one.
Spend twenty minutes walking it by hand and writing down the real steps. Delete the one that makes you wince when you read it. Merge two more. Then, and only then, decide whether it still needs a machine. If you are planning something larger, a structured plan helps: the business plan generator is a fast way to see how your workflows connect before you wire anything up. And when a decision feels murky, it can help to talk it through with history's great minds before you commit.
You will probably find that the process is either much smaller than you thought, or not needed at all. If it survives, the machine will run it better than you ever could.
The dogma says speed is the goal. The truth is quieter: speed is a multiplier, and the only thing worth multiplying is something that already works.
A novel about finding the one constraint that actually limits a process before you spend a dollar speeding anything up. Exactly the habit this article is arguing for.
View on Amazon
