Don’t Automate Until You Understand
Making better calls about manual effort, automation, and systems
Early in my career, I swung back and forth between two extremes.
Sometimes I powered through manual work that I should have automated. I pulled data by hand and repeated the same steps because I hadn’t yet seen a better path.
Later, the pendulum swung the other way. I had more experience, more tools, and more confidence. Suddenly, everything looked like a candidate for automation. I spent hours building scripts and workflows for infrequent tasks and for those that didn’t warrant building into complex systems.
Both approaches felt justified at the time. Both created unnecessary work.
What I eventually learned is that automation isn’t a skill problem or a tooling problem. It’s a judgment problem.
The mistake most run into is automating before you understand the work. That understanding doesn’t require grinding through a task many times. Sometimes it comes from doing the job a few times. Sometimes it comes from stepping back and thinking through how often the task occurs, what the inputs and outputs are, and where human judgment matters.
Automation is just one option. Used well, it reduces friction and removes repeated decisions. Used poorly, it locks in assumptions and creates systems that are harder to trust and maintain than the manual work they replaced.
Before you decide to automate anything, slow down and make sure you understand the shape of the work. The rest of this article covers how to do that, how to decide when automation is worth it, and how to build it in a way you won’t regret later.
Understanding the Work Comes Before Choosing the Tool
Before you decide to automate something, you need to understand what you’re improving.
That doesn’t mean you have to do the task manually a hundred times before you can automate it. Sometimes you learn by doing it a few times. Sometimes you learn by stepping back and thinking it through. What matters is clarity.
Here’s what you need to know:
- What triggers the task?
- What do the inputs look like?
- What “correct output” means
- Where are the steps consistent, and where judgment shows up?
- What happens when something goes wrong?
If you skip this step, automation tends to lock in assumptions. It works for the happy path, then breaks the first time the real world shows up.
Poor automation can lead to a well-known trap in automation research, known as the Ironies of Automation: you don’t eliminate work; you shift it to monitoring and exception handling.
That same automation can also lead teams to throw work “over the wall.” If the definition of done isn’t clear, people move faster but still end up doing rework.
Once you understand the shape of the work, the automation decision becomes simpler. You stop asking “can I automate this?” and start asking a better question: “should I?”
Deciding When Automation Is Worth It
Once you understand the work, the decision to automate usually comes down to two factors: how often it happens and how repeatable it is.
You can think about this as a simple 2×2 matrix.
The top-right quadrant is where automation tends to pay off. Work that is both frequent and repeatable is a good candidate because it helps you avoid the same decisions over and over.
The bottom-left quadrant is where automation usually causes more harm than good. Infrequent work that varies from case to case benefits from human attention, not a brittle system.
The two mixed quadrants are where teams get tripped up.
- Frequent but not very repeatable work often benefits from partial automation. Templates, checklists, and guardrails can help without removing human judgment.
- Repeatable but infrequent work is usually fine to keep manual. Spending hours automating a task that takes 30 minutes and happens twice a year rarely pays off.
This aligns with how automation is studied outside of software teams as well. Research on process automation consistently shows that repetitive, rule-based tasks deliver the highest return, while variable workflows introduce risk and overhead.
It’s also worth calling out what not to automate. Tasks like self-assessments, performance feedback, or sensitive communication are intentionally not repeatable. The value comes from thinking, reflection, and context. Automating them may save time, but it strips out the part that actually matters.
There’s a practical cost to getting this wrong. Estimates from McKinsey suggest that while a significant portion of knowledge work can be automated, the biggest gains come from targeting narrowly defined, repeatable activities rather than broad, judgment-heavy processes.
This framing also connects to a broader pattern you see in teams. When work is unclear, people move faster and still end up redoing it. Clear criteria and repeatable outcomes are what make both estimation and automation reliable, something I’ve written about before when discussing how to lead with data.
If a task clearly falls into the “frequent and repeatable” space, automation is usually worth exploring. If it lands somewhere
The next step is to make sure that when you automate, you build something you can trust.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Building Automation That Holds Up Over Time
Once a task clearly belongs in the “automate” category, the real work is making sure the automation lasts.
Most automation doesn’t fail immediately. It fails later, when assumptions change, and no one remembers how or why it works. Resilient automation is designed with that reality in mind.
There are a few properties that consistently show up in automation you can trust:
It’s simple enough to reason about.
You should be able to understand what it does and why it exists without having to dig through layers of logic. If the automation is more difficult to follow than the manual process, it’s fragile by default.
It fails in obvious ways.
Resilient automation doesn’t pretend everything is fine when it isn’t. When something goes wrong, the failure is visible and actionable.
It’s easy to verify.
There’s a straightforward way to confirm outputs are correct, whether that’s logs, summaries, or quick spot checks. Trust comes from validation, not from blind confidence.
It’s well documented.
Not to explain every line, but to capture intent. What problem this solves, what it expects, and what to check when things change.
This is where automation and tech debt intersect. Automation that isn’t understandable or observable doesn’t disappear. Teams work around it, hesitate to change it, and eventually treat it as untouchable. It becomes tech debt wearing a different name.
Good automation reduces cognitive load over time. If it’s simple, visible, and easy to verify, it keeps paying dividends instead of demanding attention.
Good automation starts with a clear understanding of the work.
If something is frequent and repeatable, automation can remove real friction. If it’s variable or judgment-heavy, automation tends to create new problems that later surface as maintenance, exceptions, and mistrust.
When you do automate, build it to last: simple, observable, and easy to verify. When you don’t, keep the manual process lightweight and intentional.
Want me to pick one and do a final stitching pass across the whole article for flow and consistency?