The 10-minute rule: how I decide what to automate

Automation has a maintenance tax nobody puts in the business case. Every workflow you ship is a thing that will break when an API version bumps, when someone renames a CRM property, or when a rate limit changes silently. If the workflow only saved four minutes a week, you are now paying more in attention than you ever bought back.

The rule

Automate a task when it costs more than ten minutes of focused human attention per run, or when it runs often enough that ten minutes of attention per week is being spent switching into it. Below that line, the honest answer is usually a better template, a saved view, or deleting the task entirely.

The unit that matters isn't clock time, it's attention. A task that takes two minutes but forces someone to stop what they're doing, open three tabs and re-establish context costs far more than two minutes. Context switching is the real expense, and it's the thing automation is genuinely good at removing.

The four questions before I build anything

1. How many times per month does this run, honestly? Not the optimistic number - the number from the last three months.
2. What breaks if it silently produces a wrong result? If the answer is 'a customer sees it', the automation needs a verification step, and that triples the build.
3. Who owns it when I'm not here? An automation with no owner is a future incident with a delay fuse.
4. Is the process stable? Automating a process that's still changing weekly is just writing code you'll delete.

What it looks like when the rule says yes

The meeting-to-CRM flow passes easily. Every rep, every call, ten to fifteen minutes of writing up notes and hunting for the right company record - and the write-up happens at the worst possible moment, right when they should be preparing for the next call. High frequency, high attention cost, stable process, and the failure mode is visible because the record either exists or it doesn't.

The 80k-company lookup passes too, but for a different reason. It wasn't frequent - it was one enormous batch. A human clicking through a UI for that dataset was days of work. Reverse-engineering the endpoint the front end was already calling turned it into a script and a coffee. Frequency of one, but the per-run cost was absurd.

What it looks like when the rule says no

I've killed more workflows than I've shipped. The pattern is almost always the same: an enthusiastic build for a task that happens twice a month, takes three minutes, and has a dozen edge cases. The automation handles nine of them. The other three generate Slack messages that someone has to read. Net negative, every time.

The best automation decision is often a deletion. Ask whether the task should exist before you ask whether a machine should do it.

The rule isn't precise and it isn't meant to be. It's a friction device - something that makes you say the frequency and the failure mode out loud before the fun part starts.