Method

You can't automate a job you haven't done

When someone embeds in a business to automate how it runs, the first months look like the opposite of automation. The operator is in everything. They shadow the work, sit in on the meetings, watch how the job actually gets done rather than how the org chart says it gets done. Close to a hundred percent of their attention is inside that one business.

That looks like a bad start. It isn't. It's the mechanism.

The curve

Phase one takes all of it. During discovery, the operator has to understand everything — shadow it, see the workflows, do the work as a human. Software helps at the edges. It records the meetings. It doesn't do the job.

Eventually — and it takes longer than anyone wants it to — most of that time is no longer being spent by the person. It's being spent by the workflows they built while they were doing it manually. The attention that phase one demanded doesn't get repaid in month two. It gets repaid at the far end, and it gets repaid to a workflow, not to a person.

How long that takes isn't fixed, and anyone quoting you a number on day one is guessing. What I can tell you is what the turn looks like: the exceptions stop surprising you. New ones stop arriving faster than you can absorb them, and the work starts repeating in shapes you've already seen. Until that happens, phase one isn't finished, whatever the calendar says.

So the shape of a good engagement is front-loaded and lumpy. Heavy, then light. Anyone promising it's light on day one is either automating something trivial or hasn't started yet.

Why the manual months aren't waste

You can't write a workflow for a job you haven't watched.

Every business has two versions of its process: the one that's documented and the one that actually happens. The gap between them is where all the exceptions live — the customer who always calls instead of emailing, the approval that formally requires two people and practically requires one, the step everyone skips in the last week of the month.

Automate the documented version and you ship something that breaks on contact with the real one. The only reliable way to find the gap is to sit inside the work long enough to hit the exceptions yourself. That takes months, and it's the cost of the thing being built.

This is also the honest answer to why it can't be done faster. It's not that the tooling is slow. The tooling is fine. It's that the knowledge required to write the automation doesn't exist yet, in anyone's head, on day one.

The plumber test

The same logic decides who can do this work.

Take someone who owned a plumbing business and is technically sharp. Put them inside a plumbing company and they're useful almost immediately. They already know where the exceptions live, because they lived them. They don't need three months to learn that the documented process is fiction — they know which parts are fiction before they walk in.

Now take the reverse: someone deeply capable with the tools who has never run that kind of business. They'll build cleaner automations, eventually. But they have to serve the whole discovery sentence first, because they're starting with no map of the gap at all.

Domain depth shortens phase one. That's not a hiring preference, it's the same curve seen from a different angle.

What this implies about capacity

The useful consequence is that capacity isn't a headcount question.

My working number is five to ten engagements per operator, and ten is pushing it. But the number on its own is misleading, because it depends entirely on where each engagement sits on the curve. Three clients all early in phase one is at capacity — that's three businesses each demanding near-total attention. Eight that are well past the turn might not be, because most of that work is now running without a person in it.

Which means the longer an operator goes, the more they can carry. Not because they get faster, but because their earlier engagements have decayed into workflows. Capacity compounds backwards.

It also means the wrong time to sell the next engagement is while the current ones are still in phase one. The constraint isn't ambition or pipeline. It's how much undecayed attention is already committed.

The part that's easy to get wrong

The temptation is to shorten phase one, because it's the expensive part and it's the part that looks least like progress. Nothing is being automated. Someone is just watching.

But phase one is where the asset is produced. The automations are a byproduct of having done the work. Cut discovery in half and you don't get to the same place twice as fast — you get to a worse place, having automated a process that only exists on paper, and you find out much later, when the exceptions arrive all at once.

Front-loaded and lumpy is the correct shape. It just has to be sold honestly as that, rather than as a thing that pays off next week.

← All Runbook entries Email me

Send me one email.

Tell me which part of your week you would most like to stop doing. That is usually where the system starts.

antonio@blvckbox.ai