Most teams start their automation journey by making existing processes faster. That's the wrong move.
The instinct is wrong
When someone says "automate this workflow," the natural response is to look at each step and ask how to speed it up. But the higher-leverage question is different: does this step need to exist at all?
Elon Musk's first principle applies here directly: make your requirements less dumb, then delete, then simplify, then accelerate, then automate. Most teams skip straight to the last step.
I've seen this pattern repeatedly. A team comes to me with a process they want automated. Twelve steps, four approvals, two handoffs. They want it faster. But when you ask why each step exists, half the answers are some version of "it's always been there" or "someone asked for it once."
That's not a requirement. That's institutional habit.
What deletion looks like
You audit every manual process before building a single automation. In one case, a 12-step approval workflow got reduced to 3 steps, not by automating the other 9, but by proving they added no value.
The team was faster before we wrote a single line of code.
The trick is that deletion feels risky in a way that optimisation doesn't. Speeding something up is safe. Removing it entirely makes people nervous. But the step that shouldn't exist in the first place is also the one most likely to cause confusion, create bottlenecks, or generate work that nobody uses.
The framework
Before you automate anything, ask three questions:
- What happens if we remove this entirely?
- Who actually uses the output of this step?
- Is this step here because of a real requirement, or because someone once asked for it?
If you can't defend the step, delete it. Then automate what remains.
The fastest process isn't the one you optimised. It's the one with the fewest steps that actually matter.
Views expressed here are my own and don't represent any other parties.