What to Check Before You Automate Anything

The automation isn't broken. It fires correctly, it saves the step it was built to save, and if you measured that step in isolation it would show a real improvement.

And the week feels exactly the same. The person it was built for isn't less busy. The bottleneck hasn't moved. When you ask what changed, you get a slightly awkward answer about how it's nice not to have to do that bit anymore.

That's happened three or four times now, with three or four different builds, and the aggregate effect on how the business feels is close to zero. Which starts to look less like a run of bad luck and more like something systematic about which steps get chosen.

Why the chosen step is reliably the wrong one

Here's the mechanism, and once you see it you can't unsee it.

For a step to be automated, somebody has to be able to specify it. When this happens, do that, with these inputs. Steps that survive that specification are steps that have already been reduced to a rule by a human being at some point.

But a step that's been reduced to a rule is, by that very fact, already cheap. It's fast, because there's no thinking in it. It's delegable, because it can be explained. It's low-stress, because it can't really go wrong.

Everything that makes a step easy to automate is the same property that made it inexpensive in the first place.

Now look at where your week actually goes. Deciding which category this thing is. Judging whether a draft is good enough to send. Working out what a client meant by a two-line email. Handling the exception that doesn't fit the process. Every one of those is judgment — and judgment is expensive precisely because nobody has managed to reduce it to a rule.

So the selection mechanism and the cost distribution point in opposite directions. Nobody makes an error at any point; each choice is the most tractable one available. It's only in aggregate that the pattern shows.

Five questions, in order

Run these before building anything. The first three frequently mean you shouldn't.

1. Have I timed this by hand?

Not estimated — recorded. Two weeks, step by step, with actual minutes.

Almost every founder is wrong about where their process spends time, and wrong in a consistent direction: the visible mechanical steps feel larger than they are because they're annoying, and the judgment steps feel smaller than they are because they don't feel like work.

Most people who do this discover that the step they were about to automate accounts for under a tenth of the total. That's a fortnight of mild discipline and it's the single highest-value item on this list.

2. Can this step be eliminated instead?

A surprising amount of judgment exists because an earlier step is ambiguous. Somebody has to decide which category this is because the intake form doesn't ask. Somebody has to work out what the client meant because nobody captured it at the time.

Fix the input and the decision disappears entirely — which is strictly better than automating it, costs less, and removes a maintenance liability rather than adding one.

3. Can this be decided once instead of every time?

That's what a policy is. We discount when the account is over this size and the relationship is over a year. One decision, written down, replacing a hundred instances of the same deliberation.

Most recurring judgment calls in a small business are the same three or four questions with different nouns. Writing the rule is free and it's usually more durable than any workflow.

4. Can the options be narrowed?

Choosing among three options costs a fraction of deciding freely. If a step genuinely requires a person, reducing the decision space is often more valuable than any automation — and it's what makes the step delegable, which is the outcome you actually wanted.

5. What's the shell around the judgment?

Now, finally, the automation question — and the answer is almost always partial.

Most expensive steps decompose into a judgment core and a mechanical shell. The shell is assembling the context, presenting the options, executing the decision once it's made, recording what happened. That's where nearly all the time goes, and it's fully automatable.

That's the shape that actually moves a week: not replacing the decision, but removing everything around it so the decision takes ninety seconds instead of twenty minutes.

Efficiency gives you time, but leverage gives you freedom. Automating the describable step is the purest possible way to buy efficiency and call it leverage.

The failure that's worse than not building

There's a version of this that goes wrong from the opposite direction, and it's worth naming because it's more expensive.

Sometimes the judgment step does get automated — badly. A judgment call replaced by a crude rule, which then produces wrong answers that a human has to catch and correct.

That's worse than not automating it, because now the work is checking rather than doing, and checking is the more tiring of the two. It's also the version that quietly damages trust: once a team has been burned by an automation producing plausible wrong output, they start manually verifying everything it does, which removes the entire benefit while keeping the cost.

Automation should handle movement, not meaning. Robots can prep the ingredients, but only you can taste the sauce — and most failed automations in founder-led businesses are attempts to taste the sauce.

The manual fortnight

If you take one thing from this: do it manually first, deliberately, and pay attention while you do.

Not because manual work is virtuous. Because it's the only reliable way to learn which part of the process is actually expensive and which parts of it carry something that shouldn't be removed.

When you do something manually first, you feel its texture. You notice the friction points, the moments that matter, and the little places where care hides. That nuance is the data that makes automation good — and it's also what tells you where the line is, because the moments where care hides are exactly the ones you'd otherwise optimize away without noticing.

Founders who've never done the thing personally cannot tell which part of it is load-bearing. That's the actual source of most bad automation decisions, and it's not a knowledge gap you can close by thinking harder.

The order that makes the fortnight cheap

The obvious objection to timing a process by hand for two weeks is that it's two weeks of overhead before anything gets built. It isn't, if you do it in the right order.

You're already doing the process. The measurement isn't extra work — it's a note next to work that's happening anyway. Start time, stop time, one line about what the step was. Two minutes a day of overhead, and most of that is remembering.

The thing that makes it feel expensive is treating it as a study. It isn't a study. It's a record of five or six instances, which is enough to see where the mass is, because the distribution in a founder-led process is rarely subtle — one step is usually four or five times the next one.

And run it on the process you're most confident about, not the one that's most obviously broken. Confidence is where the surprise lives. Everybody already knows the chaotic process is chaotic; the useful finding is that the well-run one spends most of its time on a step nobody had thought about.

One more note on who records it. If somebody else does the work, they measure it, and they should be told why — because the honest answer, we want to know which part of this is worth removing, produces much better data than any framing that sounds like a productivity audit.

What good looks like afterwards

A build that passes all five questions has a recognizable shape.

It removes something from the week, not from a step — you can point at a block of time that no longer exists. It leaves the judgment with a person, and that person spends less time reaching the decision. It replaced or eliminated an input problem rather than papering over one. And somebody could explain, in one sentence, what would break if it stopped.

That last one matters more than it sounds, because it's the difference between an addition to your architecture and an addition to your estate. Every automation is a permanent maintenance liability, and a build that saves a genuinely cheap step means you took on that liability in exchange for a rounding error.

This is the whole of the Automation pillar applied to a single decision. Efficiency asks how can I do this faster. Leverage asks whether you should be the one doing it at all. Five questions is just a way of making sure you asked the second one before you spent a week answering the first.