Choosing What to Automate

Teams rarely lack automation ideas. They lack an agreed way to rank them, which means the loudest engineer’s idea wins and the highest-value work sits in a backlog.

Start from toil, not from tasks link

Google’s SRE practice defines toil precisely, and the definition is worth adopting verbatim because it filters out most bad candidates on its own. Toil is work that is:

• Manual — a human runs it
• Repetitive — it has been done before and will be done again
• Automatable — a machine could do it, in principle
• Tactical — reactive and interrupt-driven, not strategic
• Devoid of enduring value — the service is in the same state afterward
• Scaling linearly with service growth — twice the traffic, twice the work

Work that fails several of these tests is usually not an automation problem. Manual work that produces enduring value is engineering. Manual work that is not repetitive is investigation. Manual work that does not scale with growth may simply not be worth the build.

The last criterion is the strongest signal. Anything that scales linearly with service growth becomes an existential constraint eventually, so it earns investment even when today’s volume looks tolerable.

The screening funnel link

flowchart TD
    A[Candidate task] --> B{Is the process<br/>itself correct?}
    B -->|No| B1[Fix the process first.<br/>Automating it entrenches the defect.]
    B -->|Yes| C{Is it deterministic?<br/>Same input, same action}
    C -->|No| C1[Automate the deterministic parts.<br/>Keep human judgement in the loop.]
    C -->|Yes| D{Stable interface?<br/>Will the API/UI survive a year?}
    D -->|No| D1[Defer. Maintenance will exceed savings.]
    D -->|Yes| E{Frequency x risk<br/>above threshold?}
    E -->|No| E1[Document it well instead.]
    E -->|Yes| F{Who owns it<br/>after you build it?}
    F -->|Nobody| F1[Do not build. Orphaned automation<br/>becomes an outage waiting to happen.]
    F -->|Named owner| G[Build it]

Two gates in this funnel reject more candidates than the rest combined.

“Is the process itself correct?” Automating a bad process produces a bad process that runs faster and is much harder to change, because now it has code, tests, and a dependency graph. If the approval step exists only because someone was burned in 2019, delete the step before you encode it.

“Who owns it after you build it?” Automation without an owner is a liability with a countdown. The person who wrote it moves teams, a dependency deprecates, and the first anyone hears about it is when it silently stops running.

Categories that reliably repay the effort link

Across organizations, the same categories keep showing positive returns:

Categories to be careful with link

• Anything requiring judgement about ambiguous input. Automating the data-gathering is nearly always right; automating the decision usually is not, at least not initially.
• Processes with a shifting external interface. If a vendor’s admin UI has no API and changes quarterly, browser automation against it will consume more maintenance than the task consumes manual time.
• One-time migrations. Scripting them is right — for repeatability and review — but productionising them is not.
• Work whose real cost is coordination, not execution. If the two-minute task takes three days because it waits on three approvals, automating the two minutes changes nothing. Automate the approval routing instead; see Automating Change Management.

Sequencing: start where feedback is fastest link

When several candidates score similarly, prefer the one with the shortest feedback loop. Automation you exercise many times a day gets debugged into reliability quickly. Automation you exercise twice a year stays fragile no matter how carefully it was written — which is exactly why the rare-but-critical category needs scheduled exercise built in, not just code.

flowchart LR
    subgraph "Exercised daily"
    A1[CI build] --> A2[Fails visibly] --> A3[Fixed within hours]
    end
    subgraph "Exercised yearly"
    B1[DR failover script] --> B2[Fails during the real event] --> B3[Discovered at worst moment]
    end
    B1 -.->|Mitigation:<br/>scheduled game days| A1

Adoption checklist link

• Candidates are screened against the six toil criteria, not just “annoying”.
• Each accepted candidate has a named owner before build starts.
• Broken processes are fixed before they are automated.
• Rarely-executed automation has a scheduled exercise on the calendar.
• Candidates whose real cost is coordination are routed to process work.
• The ranking is written down and revisited quarterly.