The one idea
Automation is an investment with a maintenance cost, not a free upgrade.
You pay to build it. You keep paying to keep it working. The task has to be frequent enough and stable enough for those payments to be worth it.
Most bad automations are not badly built. They are correctly built for tasks that never justified them.
Work out how much time it really saves in a year, and how long it takes to build. If those numbers are close, do it by hand.
Annual saving is frequency times time saved. Cost is build time plus expected maintenance. Maintenance is the term people forget and it is rarely zero.
Payback period equals build cost divided by recurring saving. Add expected failure cost — probability of silent failure times the cost of a wrong result going unnoticed.
The arithmetic
Yearly saving = times per year × minutes saved each time
Total cost = hours to build + hours per year keeping it working
Run it on the Monday spreadsheet task:
- 52 times a year × 9 minutes = 468 minutes, about 8 hours saved.
- Building it took 6 hours. Fixing it when formats change, maybe 2 hours a year.
First year: 8 saved, 8 spent. Break-even. Second year onwards: 6 hours saved a year. Worth doing — but only just, and only because it happens weekly.
Now run the same numbers on a task you do twice a year and that takes 30 minutes:
- 2 × 30 = 1 hour saved a year.
- Building it: 4 hours. Maintenance: 1 hour a year, and you will have forgotten how it works between runs.
You will never break even. You lose time every year forever. This is the most common automation mistake there is, and it feels productive the entire time.
What makes a task automatable
| Automatable | Not automatable |
|---|---|
| Repetitive — same steps every time | Different each time |
| Rule-based — you can write the rule down | Requires judgement you cannot articulate |
| Stable inputs — same format, same place | Format changes, or a human decides the format |
| Clear success — you can check it worked | "It depends" or "it should feel right" |
| Failure is cheap and visible | Failure is expensive or invisible |
The test that settles it: can you write down the rule so precisely that someone who knows nothing about your job could follow it and get the same result every time?
If you find yourself writing "usually", "unless", or "use your judgement", you have found the part that cannot be automated. Sometimes you can automate everything around it and leave that one decision to a person — which is often the best design available.
"Send the weekly report to the team" splits into: pull the numbers (rule-based, automatable), format the sheet (rule-based, automatable), write the commentary on what changed and why (judgement, not automatable), send it (automatable).
Automating three of four turns a 40-minute job into a 10-minute one. Attempting to automate the commentary produces bland paragraphs that someone has to rewrite, which is slower than writing them.
Collecting sources for an assignment: finding them is judgement, formatting the citations is a rule. Automate the formatting, keep the judgement.
Automating the choosing is how people end up citing sources they have not read.
Try this
Which of these is the best automation candidate, and why is each of the others worse?
- Renaming 400 photos to a consistent format. One-off task, would take 3 hours by hand.
- Approving leave requests under 3 days when the team has cover.
- Reconciling two spreadsheets, monthly, 45 minutes, both formats fixed.
- Replying to customer complaint emails.
Deciding, in five minutes
1 of 6Time the task honestly, once.
Not your estimate. Actually time it. People overestimate boring tasks by a lot, because the tedium is more memorable than the duration. A "half-hour job" is frequently eleven minutes.
Your challenge
Level 3 · IndependentList every repetitive task you did in the last two weeks. For the three most annoying, fill in: minutes each time, times per year, annual saving, guess at build hours, and one way the input could change.
You have succeeded when you can name one task worth automating, one that is not, and — this is the valuable one — one that should be eliminated rather than automated.
Most people find at least one task on their list that nobody actually needs.
What people usually get wrong
- Automating what annoys you rather than what costs you. Annoyance and time are unrelated. The most irritating task is often three minutes a month.
- Ignoring maintenance. Every automation depends on something outside your control. Things change. Budget for it or be surprised by it.
- Automating unstable processes. If the process is still changing, you are building on sand. Stabilise it manually first, then automate.
- No failure alarm. An automation that fails silently is worse than no automation, because you have stopped checking.
- Automating something only you understand. When you leave, it becomes a black box nobody dares to touch or turn off.
- Counting the hobby as the saving. Building it was interesting. That is a fine reason to do it — just do not put it in the business case.
How someone experienced does it
Experienced people automate the checking, not just the doing. The valuable automation is often not "do the task" but "tell me when the numbers do not match". It is cheaper to build, safer when it fails, and it catches the errors a full automation would have made silently.
They also do a task manually several times before automating it. The first three runs reveal the exceptions — the client whose file has a different header, the month with five weeks. Automating after one run means encoding a version of the process that only existed once.
And they design so that failure means stopping, not continuing. An automation that halts loudly and leaves the work undone costs you nine minutes. One that continues with wrong data costs you a wrong report and the trust of everyone who read it.
When not to use this
Do not automate when:
- The process is about to change. A reorganisation, a new system, a policy under review. Wait.
- The task is how you notice problems. Some manual work is quality control in disguise. Reading the numbers as you copy them is how you spot the odd one.
- Volume is genuinely low. Twice a year is not a pattern. It is twice.
- The judgement is the job. If the hard part is deciding, automating the easy part around it saves almost nothing.
Prove it
Pick one task you decided was worth automating and one you decided was not.
Write four lines for each: annual time saved, estimated build cost, what would break it, and what happens if it fails without anyone noticing.
The second one — the task you chose not to automate — is the better proof. It shows you can resist the interesting build in favour of the correct decision.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned deciding whether a task is worth automating. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood deciding whether a task is worth automating. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at judging what should and should not be automated — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.