We're getting used to things happening instantly.
We expect faster answers, faster transactions, faster reports, faster decisions. Information is available almost immediately, and technology keeps giving us more ways to eliminate waiting.
So when a process feels slow or painful, our instinct is often: How do we make this faster?
That's where automation becomes particularly attractive. But what if we're asking the wrong question?
Faster doesn't always mean better.
Sometimes, the fastest way to improve a process is to slow down first.
We have a tendency to see a process that's taking too much time and immediately look for something to automate.
People are spending hours doing repetitive work. There are too many spreadsheets. Too many handoffs. Step after step after step.
So the natural response is to automate them.
While automation can definitely make a process faster, it doesn't necessarily make the process better.
If we automate a process before understanding why it works the way it does, we may simply end up doing the wrong thing faster.
A person performing a process can stop and ask:
“Why are we doing this?"
Traditional automation generally won't. It executes the rules it's given.
That's both the strength and the danger of automation.
If we've carefully designed the process, automation can make it faster, more consistent, and more scalable.
AI can even make it go further, allowing some automated systems to adapt to new information, evaluate their outputs, and adjust how they respond.
But even a system that can learn or self-correct is still operating within a purpose we have defined for it.
It can improve how the work gets done. It doesn't necessarily tell us whether we're doing the right work in the first place.
If we haven't understood the process, we're still giving the technology a problem it may be very good at solving without knowing whether it's the problem we should be solving.
This becomes particularly relevant when organizations introduce a new system.
After years of working with an existing system, people develop processes around it. Some of those processes may be deliberate. Others may be workarounds that were introduced because the old system couldn't do something properly.
Eventually, questioning the process can feel like it takes more time than simply following it.
So someone says:
“That's just how we did it.”
And the process continues—not necessarily because it's still the best way, but because changing it seems slower than leaving it alone.
Then a new system comes along.
And one of the first questions is often:
“How do we make the new system work the way the old one did?”
Sometimes that's the right question.
But sometimes it isn't.
A new system is an opportunity to ask something more uncomfortable:
Why were we doing it that way in the first place?
There's a difference between digitizing a process and transforming a process.
Digitizing says:
“We used to do it this way manually. Now the system does it.”
Transformation asks:
“Do we still need to do it this way?”
That distinction matters.
Because if we simply reproduce every old workaround in a new system, we may have changed the technology without changing the organization.
One of my personal pet peeves is standing in a long queue.
If you've ever found yourself at the end of a line that barely seems to move, you probably don't need much convincing that waiting can be frustrating.
So if someone offered to make that queue move faster, I'd probably say yes.
But even here, there's a better question to ask:
Why is there a queue in the first place?
Maybe the process is unnecessarily manual.
Maybe there's only one person serving everyone.
Maybe everyone has to go through the same steps, even when their needs are different.
Maybe there's a better way to organize the flow.
Adding more people to process the queue might make it move faster. But redesigning the process might reduce the queue altogether.
And sometimes, the queue exists for a reason. A quality check, an approval, a compliance requirement, or another control may be necessary even if it slows things down.
So the goal isn't necessarily to eliminate every delay.
It's to understand what is causing the delay and whether that friction is actually serving a purpose.
The same thing happens inside organizations.
When something is manual, inefficiency tends to be visible.
Someone notices that a report takes three days to prepare.
Someone complains that they have to enter the same information twice.
Someone spends an afternoon reconciling two spreadsheets.
The friction is annoying, but the friction is also a signal:
Something isn't working particularly well here.
Automation can remove that friction.
That's usually a good thing.
But it can also remove the warning signal.
A bad process that takes three days manually might be annoying enough for someone to question it.
A bad process that runs automatically every night might go unnoticed for months.
And if the process is wrong, automation doesn't just repeat the mistake.
It can scale it.
That's why I don't think the question should simply be:
“How much time can we save?”
We should also ask:
“What are we actually making more efficient?”
Because efficiency and effectiveness aren't the same thing.
Doing something with less effort doesn't necessarily mean we're achieving a better outcome.
There's another trap here.
We often associate automation with consistency.
And that's generally true. A system will perform the same instructions the same way, assuming the conditions are the same.
But consistency isn't the same as correctness.
If we give automation the wrong rule, it can consistently produce the wrong result.
If we give it bad data, it can consistently process bad data.
If we automate an unnecessary step, it can consistently perform something nobody really needed in the first place.
AI complicates this picture a little.
A sufficiently capable AI system may be able to recognize patterns, evaluate its own output, use feedback, and change how it approaches a task. That's useful, but being able to improve its execution isn't the same as knowing whether the objective itself is worthwhile.
So there's a slightly uncomfortable question worth asking:
Are we making the right thing consistent, or simply making the existing thing consistent?
That distinction can get lost when the focus is on efficiency.
This is where I think slowing down can actually be the faster approach.
Take the time to understand the process. Question the assumptions.
Remove unnecessary steps. Fix the underlying problems.
Clarify who owns what. Make sure the data is reliable.
Then automate what remains.
That can feel slower at the beginning.
The alternative, however, is often more expensive: automate first, discover the problems later, and then spend even more time fixing what was just automated.
Sometimes the fastest way forward is to slow down long enough to make sure we're going in the right direction.
I'm not arguing against automation as it can be incredibly useful. It can remove repetitive work, reduce errors, improve consistency, and allow people to spend more time on things that actually require judgment.
AI can expand that capability even further, but I think automation works best when we treat it as the result of understanding the process, rather than as a substitute for understanding it.
Before automating, I'd want to ask:
What are we actually trying to achieve?
Why does the process work this way?
Which steps genuinely add value?
Which steps exist because of an old system or workaround?
Where does human judgment matter?
Is the underlying data reliable?
Who owns the process?
What happens when something goes wrong?
Only then does the automation conversation become much more useful.
Instead of asking:
“How do we automate this?”
we can ask:
“What is the simplest, most reliable way to achieve the outcome we want—and where can technology help?”
That's the question I'd rather be asking.
In my last article, I wrote about starting with the impact rather than the technology. The same principle applies here.
If we start with technology, we can easily end up automating whatever happens to exist.
If we start with the desired outcome, we can first determine what actually needs to change.
Then technology can do what it's good at: helping make a good process faster, more consistent, and more scalable.
The goal isn't to automate everything.
The goal is to make the organization better.
And sometimes, the best way to make something faster is to slow down first.