Before You Automate, Decide Whether the Work Should Exist

By Matthew Andrews · October 11, 2026

Workflow Automation That Earns Trust · Part 1

The first automation decision happens before we choose a tool: is this work worth doing at all?

A process can be repetitive, frustrating, and easy to automate while producing something nobody needs. Making it faster would still leave us maintaining a system for unnecessary work.

My starting point is to understand what the process produces, who depends on it, and which parts actually contribute to that outcome.

Find the Outcome Behind the Routine

In my government technical-management work, I automated a recurring reporting process. The work included producing and organizing reports for review. The useful outcome was the information people needed to inspect and approve; much of the effort was in repeatedly preparing that information.

That distinction matters. “Automate reporting” is a broad request. “Produce the required report from its source without repeatedly rebuilding it by hand” identifies a more useful starting point.

Before choosing an automation, I would ask the person receiving the output: What do you use this for? What decision does it support? What happens if you do not receive it?

A required record may have value even when nobody opens it every day. The point is to establish its purpose and obligations, then examine the work needed to satisfy them.

Separate Necessary Work From Accumulated Work

Consider a hypothetical team preparing a weekly status pack. Someone copies information from a project system into a spreadsheet, reformats it for a presentation, and emails it to several managers.

There are several possible improvements, and only some require automation.

If two versions contain the same information and one is no longer needed, retire the duplicate after confirming that with its owner. If the recipients only need a few fields, simplify the pack. If a standard report is still needed each week, generating it from the source becomes a sensible automation candidate.

I would work through those choices in that order: remove unnecessary steps, simplify what remains, then automate the repeatable work that still serves a purpose.

Choose a Bounded First Improvement

A good starting candidate has a recognizable trigger, an identifiable source, a useful output, and someone who can judge whether the result is correct.

For the status-pack example, the first improvement might be generating a draft report from approved source fields. A person still checks the result before distribution. That gives the team a small, observable change to evaluate without redesigning every decision in the reporting process at once.

I would also look at how often the work happens, how much hands-on effort it consumes, and how frequently people have to correct it. A recurring task can justify attention without being the largest task in the organization.

If nobody can explain what a correct result looks like, I would clarify the process before automating it. Otherwise, the automation inherits the ambiguity.

Make the Selection Explicit

Before building, I would write down five things:

• Who needs the output and what it enables.
• Which steps can be removed or simplified.
• Which repeated step we intend to automate first.
• Who will check its output and own changes to the process.
• What observable improvement would make the effort worthwhile.

That is enough to begin a grounded conversation about scope. It also gives the team permission to conclude that a simpler process is the better solution.

For me, useful automation starts with choosing work that deserves to continue. Once that is clear, we can examine the exceptions that make the real process more complicated than its happy path.

Subscribe through the blog’s RSS feed for future posts in this series.

Back to Blog