Automation has a seductive quality: once you can wire two things together, everything looks like it should be wired. The constraint is almost never the tooling. It's deciding which tasks deserve it, being honest that automation carries a maintenance cost, and refusing to automate a process you haven't simplified first.
Automate in this order
The standard sequence, and it's counterintuitive:
- Eliminate. Does this need to happen at all? A report nobody reads and a recurring meeting with no decisions are better deleted than automated.
- Simplify. Can it be done in fewer steps, or less often? Reducing a ten-step task to three is often a bigger win than automating all ten.
- Standardise. Give it consistent inputs and outputs. Automation struggles with variation long before it struggles with volume.
- Only then, automate.
Automating a messy process doesn't fix it — it makes the messy process run faster and hides it from view, where it silently fails for months.
What makes a good candidate
- High frequency. Daily or weekly beats monthly. Time saved scales with repetition.
- Rule-based and predictable. Clear triggers, clear actions, few exceptions.
- Structured data. Files, fields, records — not judgement and nuance.
- Low cost of failure. If the automation breaks, does anything bad happen? If yes, add a human check.
- Annoying rather than valuable. Automate what drains you, not what you're good at and find meaningful.
- Stable. Something you expect to still be doing in a year.
What makes a bad candidate
- Tasks that need judgement, taste or relationships
- Anything one-off — just do it manually
- Processes that change often, where maintenance exceeds savings
- Steps where an error is expensive or irreversible — sending external messages, deleting, moving money, publishing
- Work you haven't done manually enough times to understand its exceptions
Three levels of tooling
1. No-code connectors
Trigger-and-action platforms that link the services you already use — new file appears, send a notification; form submitted, create a task; calendar event ends, write a summary.
- Strengths: accessible without programming, broad service coverage, fast to build
- Limits: brittle when APIs change, per-step pricing can grow, debugging is opaque, and complex logic becomes unmanageable
2. Scripts
A short script for renaming, moving, parsing, converting or summarising files, run on demand or on a schedule.
- Strengths: free, fast, no vendor, versionable, and handles messy local tasks well
- Limits: you own the maintenance, and it only runs where you've set it up
3. AI agents and LLM steps
Using a model as a step inside a workflow — classifying incoming items, drafting a reply, extracting fields from unstructured text, summarising a thread.
- Strengths: handles the unstructured middle that defeated earlier automation, and needs no explicit rules for fuzzy tasks
- Limits: non-deterministic output, so it needs validation on anything consequential; costs scale with use; and failure modes are quiet rather than loud
Choose by failure cost, not by novelty. Deterministic steps should stay deterministic; reach for a model only where rules genuinely can't be written.
The part people forget: maintenance
Every automation is something you now own. Accounts expire, APIs change, services redesign, and the person who built it moves on. Practical guardrails:
- Keep a list. A plain note of what's automated, what it depends on, and what breaks if it stops. This is the single highest-value habit here.
- Add failure notifications. Silent failure is the default and the worst outcome — a workflow that stopped three months ago and nobody noticed is worse than no workflow.
- Log what happened for anything touching external parties or money.
- Review quarterly. Delete automations you no longer use; they're liabilities, not assets.
- Prefer fewer, better ones. Ten fragile workflows cost more than three solid ones.
Where to start
- Track one week. Note every task you do more than twice that follows a fixed pattern. Most people already know which one it is.
- Pick the one that annoys you most and is lowest risk. Not the biggest; the cheapest to learn on.
- Build the smallest version that works, then run it manually alongside the old way for a week.
- Add a check on the output before you trust it.
- Only then add the second one. Automations accumulate faster than they get maintained, and that's how people end up with a system they're afraid to touch.
Bottom line
Eliminate, simplify, standardise, then automate — in that order. Automate what is frequent, rule-based, structured and cheap to get wrong, and keep a human in the loop wherever an error is expensive. Keep an inventory of what you've built and make failures loud. The goal isn't to automate everything; it's to stop spending attention on the parts of your week that don't need you.