The first thing a team should automate is not always the task that takes the most time.
That sounds wrong when automation is presented mainly as a way to save hours. Find the largest manual process, replace it with code, and collect the benefit. In practice, that approach often creates an expensive project around a workflow the team does not understand well enough.
The best first target is usually smaller. It is frequent, predictable, easy to verify, and painful enough that people already want it to disappear.
Good automation earns trust. The first project should prove that the automated path is clearer and more reliable than the manual one.
Start With Repetition and Risk
I look for two signals first: how often the task happens and what happens when it goes wrong.
A task that takes five minutes but happens fifty times a week may be a better target than a four-hour task that happens once a year. The repeated task creates a steady tax through interruptions, context switching, and inconsistent execution.
Risk changes the calculation. A short manual step that can expose data, break production, or leave access active forever deserves attention even if it is not frequent. The value of automating it comes from enforcing the rule every time, not only from saving time.
This gives teams a useful starting point:
- Frequent and low risk tasks are good candidates for full automation.
- Frequent and high risk tasks need strong controls, tests, and approval boundaries.
- Rare and low risk tasks may only need a checklist.
- Rare and high risk tasks often need a tested runbook before they need automation.
Automation is one option. Sometimes the correct improvement is better documentation, validation, or removing the task entirely.
Make Sure the Process Is Stable
Do not automate a workflow that changes every time somebody performs it.
If three engineers complete the same request in three different ways, the team has not yet found the process. Writing code at this stage only selects one person’s assumptions and makes them harder to challenge.
Before automating, write down the inputs, decisions, actions, expected result, and recovery path. Then walk through a few real examples.
Where do people make judgment calls? Which exceptions are legitimate? Which steps exist only because an old system required them? What information is usually missing? How does the operator know the work succeeded?
The answers reveal whether the task is ready. A stable process does not mean every input is identical. It means the variation is understood well enough to create rules and clear escalation points.
Prefer Work With an Observable Result
The easiest automation to trust is automation that can prove what it did.
Consider a script that creates a cloud resource. Finishing without an error is not enough. The resource may exist with the wrong network, missing tags, excessive permissions, or no monitoring.
A useful automated workflow checks the desired outcome. It verifies the resource configuration, records the change, and reports enough information for somebody to understand the result.
This is why testability should influence priority. If success can be checked automatically, the team can improve the workflow without depending on somebody to inspect every run manually.
If the only way to decide whether the automation worked is to ask an expert, the team has moved the manual step instead of removing it.
Choose a Narrow Boundary
Large automation projects often fail because they try to solve the entire workflow at once.
Imagine an onboarding process that includes account creation, hardware, access approval, team configuration, documentation, and training. Automating all of it sounds valuable, but the project immediately crosses many owners and systems.
A better first step may be to validate the request and create the standard accounts after approval. That boundary is useful on its own. It has defined inputs, a clear permission model, and an outcome that can be checked.
Once that part is reliable, the team can add access expiry, notifications, audit reporting, and more integrations.
Small boundaries create faster feedback. They also make failure easier to understand. When one workflow owns twenty systems, every problem becomes an investigation.
Do Not Automate Waste
Some manual work should be deleted, not automated.
Teams often maintain reports nobody reads, approvals nobody challenges, and data copies created only to feed another workaround. Automating these tasks reduces visible effort while preserving the underlying waste.
Before building anything, ask what decision or outcome the task supports. If the answer is unclear, stop. Find the consumer. Confirm that the work is still needed.
Removing a task is the most reliable automation possible. It has no credentials to rotate, no dependency to upgrade, and no failure mode at 03:00.
Include the Cost of Ownership
Automation is software, even when it begins as a small script.
It needs an owner. Dependencies change. APIs fail. Credentials expire. Input formats drift. The workflow needs logs, tests, documentation, and a way to run safely after the original author moves on.
This maintenance cost should be part of the priority decision.
A task that saves one hour per month may not justify a service with several integrations and a permanent operational burden. A simple command with a clear README might be enough. On the other hand, a workflow that controls production access may deserve a proper service even if it saves less time, because consistency and auditability are the main benefits.
Choose the simplest implementation that provides the required reliability.
Use a Practical Scorecard
When a team has many candidates, I use a short scorecard instead of debating based on whoever is most frustrated that week.
For each task, estimate:
- Frequency: how often does it happen?
- Effort: how much focused time does it consume?
- Risk: what is the impact of a manual mistake?
- Stability: are the inputs and decisions understood?
- Verifiability: can success be checked automatically?
- Reach: how many people or teams benefit?
- Ownership cost: how difficult will the automation be to maintain?
The score does not need to become a complicated formula. Its purpose is to make the tradeoffs visible.
I would choose a moderately painful task with stable rules and clear verification over a very painful task full of exceptions. The first one can create a dependable result. The second may need process design before it needs code.
Final Thought
Automation should reduce operational burden, not exchange visible manual work for invisible system complexity.
Start with a task people repeat, a result the system can verify, and a boundary small enough to understand. Confirm that the workflow is still valuable. Define how it fails and who owns it.
Then automate one useful part and measure whether the outcome improved.
The best first automation is not the most impressive one. It is the one that works often enough, clearly enough, and reliably enough that the team wants to build the next one.