From Instructions to Infrastructure

You handed it over. Somebody else is doing it now, and it's mostly fine — except that you're still consulted about it roughly weekly, you still catch the edge cases, and if that person left tomorrow the knowledge would go with them.

So it was handed over, and it wasn't. Which is confusing, because delegation is usually described as a single act: you do the thing, then somebody else does the thing.

It isn't a single act. It's four stages, each producing a different artifact, and most handovers stop at the second one — which is exactly the state described above.

Stage one: you do it

The baseline. The work happens because you do it, it goes well because you're good at it, and nothing about it exists outside your head.

Worth noting that this stage is correct at the start. There's no substitute for the founder doing the work early — you learn what it actually requires, where the judgment sits, and which parts carry weight. 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.

The failure isn't being here. It's staying here after the learning has been extracted.

Artifact produced: none. That's the defining property of stage one, and it's why it can't scale.

Stage two: you tell somebody

Somebody else does the work, and they do it by asking you. You explain, they execute, you check. When something unusual comes up, it comes to you.

This is where most handovers stop, and it looks enough like delegation to be mistaken for it. The task is off your desk in the sense that you're not doing it — and it's fully on your desk in the sense that it can't happen without you.

An explanation given out loud has one consumer and a lifespan of one conversation. The information exists during the sentence and then stops existing.

The reason this stage is so sticky is that the local arithmetic always favours it. Explaining takes four minutes. Writing it down takes twenty-five, and the person still needs the four-minute answer today. So at every single instance, explaining wins — not by a little, and not because anyone's lazy.

That comparison being correct every time is exactly why willpower doesn't get you to stage three. You need a rule instead.

Artifact produced: none. Same as stage one, which is the thing to notice. Two very different-looking states, identical in output.

Stage three: it's written down

The process exists as something a person can read. The stages, the order, what has to be true to move forward, who owns what, and the standard it has to meet.

This is the first stage that produces something durable, and the change it makes is out of proportion to the effort. A written process can be handed to the next person without you. It can be improved by somebody other than you. It can be checked against.

The rule that gets you here — and it's the only one I've seen survive contact with a real business:

The third time you explain something, the explanation becomes the artifact. Not later. Not when there's time. The third time.

In practice that means changing the medium rather than adding a task. Answer the question in writing, somewhere findable, and send the link. Eight minutes instead of four, rather than twenty-five instead of four — because you're not writing documentation, you're answering the question somewhere durable. That distinction is the whole trick, and it's why this survives when documentation projects don't.

Record it if it's visual or procedural. Two minutes of overhead on a four-minute explanation, and the artifact is better than a written one for anything that involves showing where something is.

Artifact produced: a document somebody can follow.

Stage four: the system carries it

The process is embedded in something that enforces it. Stages with entry and exit conditions. Triggers that fire without anybody remembering. Fields that must be filled before something can advance. A default that happens rather than a document that describes what should happen.

This is the difference between the process says and the process does.

A documented onboarding sequence is stage three. An onboarding sequence where the signed contract triggers the tasks, assigns the owners, and blocks kickoff until the handoff note exists — that's stage four. Same process. Completely different reliability under load.

Artifact produced: a mechanism.

The distinguishing test between three and four: what happens on the worst week of the quarter? A stage-three process degrades gracefully into whatever people remember. A stage-four one runs.

The business stops depending on your instructions and starts depending on your infrastructure.

Why stopping at two is the expensive one

Because from the outside it looks like progress, and from the inside it feels like relief.

You are doing less of the work. Your week genuinely improved. What hasn't changed is the dependency — and dependency is what determines whether you can take a fortnight off, hire a second person into the same function, or sell the business.

There's a second cost that's slower and worse. Everything the person learns while doing the work — the edge cases, the client-specific quirks, the thing that always goes wrong in week three — accumulates in their head rather than in the artifact. So when they leave, the business is back at stage one, minus a year, and the next person starts from your explanations again.

Stage two is a treadmill. It looks like distance covered.

Where each stage is actually right

None of this argues for taking everything to stage four. That would be its own failure — over-systemizing work that changes constantly, or that happens twice a year, costs more than it returns.

Stay at stage one for things only you can do, that happen rarely, and that you're not trying to hand over. That's a legitimate position and there should be some of it.

Stage two is fine as a transition, and only as a transition. If something has been at stage two for more than a couple of months, that's the signal.

Stage three is the right destination for most things. Written, findable, followable. The majority of what a founder-led business needs to hand over needs nothing more than this.

Stage four is for the load-bearing paths — the ones where a failure costs a client, money, or delivery. Onboarding, handoffs, follow-up, anything touching a promise you made. Those need a mechanism, because those are the ones that break precisely when everybody is too busy to remember.

The move that makes it happen

The reason handovers stall at stage two isn't disagreement about any of this. It's that stages three and four look like projects, and projects lose to delivery.

So don't do them as projects. Attach them to the work.

The next time you explain something for the third time, answer it in writing instead. The next engagement that starts, write the stages down as they actually happen rather than trying to author the process in advance. The next thing you build, build the mechanism around the process you already documented.

Build the systems as you do the work, not instead of the work. It's the only version that survives a real month, and it's the difference between a business that improves continuously and one that schedules improvement for a quieter quarter that never arrives.

That's the whole shape of the Enablement pillar: empowerment gives people ownership, education equips them for it, and environment supports it. Stage three is education. Stage four is environment. And a business stuck at stage two has neither — however much authority it has handed out.

My business will not reach its potential if I'm the one powering it. It will reach its potential when I'm the one shaping it.

The stage that gets skipped, and why it can't be

There's a shortcut that's tempting and doesn't work: going from stage two straight to stage four. Skip the writing, build the mechanism.

It fails for a specific reason. A mechanism encodes a process, and encoding a process you've never written down means encoding whichever version happens to be in the builder's head that week — usually the founder's idealized version rather than the one that actually runs.

What you get is a system that enforces a process nobody was following, at which point people route around it. And routing around a mechanism is much worse than routing around a document, because the mechanism now produces data that's confidently wrong: the record says the process ran, and what actually happened was somebody working outside it.

Stage three isn't a nice-to-have on the way to stage four. It's the specification, and it's the only opportunity to discover that the process you think runs and the process that does run are different — which they almost always are, and the difference is usually the interesting part.

The cheap version: write the stages as they happen on the next engagement, in the order they actually happen, rather than authoring the process in the abstract. You'll have a defensible one-pager by the end of it, and it'll describe reality rather than intention.

Where are you, actually?

Take the three things you've most recently handed over and place each one.

If they're all at stage two, that's the finding — and it's a common one, because stage two feels like an ending. The work from here isn't more delegation. It's producing the artifact that was never produced.