Handing Over the System

Here is the uncomfortable arithmetic of everything you have built so far: if only you can run it, you have not built a system. You have built a better cockpit for the same pilot, and the business still stops when you stop. The handover is where the operating system pays its real dividend, and it goes wrong in a predictable way, so this lesson is about the way it goes wrong.

Teach the workflow, not the tool

The instinct is to teach your office manager "how to use AI": a tour of the assistant, some prompting tips, a warning about hallucinations. Resist the instinct. It produces an anxious improviser, someone doing on hard mode what took you three courses to learn, with your customer list in the blast radius.

Teach the workflow instead. Your office manager does not need to know how to prompt; the skills hold the prompting. They need to know how to run Monday Marketing: open the runbook, paste the Brain, trigger the skill, run the named checks at the checkpoint, schedule, log. That is a procedure, and procedures are teachable in an afternoon to anyone who can follow a recipe, because you spent five chapters removing every step that needs improvisation.

This is why the architecture matters. The Brain means they never have to brief the assistant from their own knowledge. Named checkpoint checks mean review is a checklist, not a judgment call. ESCALATE means the weird cases route to you automatically. The system's whole design has quietly been a training program for a person who has not met it yet.

The pairing ladder

Hand over one workflow at a time, each through the same three rungs:

1. They watch you run it, once. Talk through the checkpoint checks aloud as you do them, especially the ones that have caught something; the story of the caught mistake teaches more than the rule.
2. You watch them run it, twice. They drive, you sit on your hands. The urge to grab the keyboard at the checkpoint is strong, and giving in teaches them the review is really yours.
3. They run it alone, with a wider yellow lane for a month. Outputs you would send unreviewed, they route to you for a light look. Not because they are less capable: because trust between them and the system has to be earned in both directions, the same way yours was in Chapter 3.

One workflow per week on this ladder is a comfortable pace. Start with the lowest-stakes calendar workflow, usually the ops batch, and end with the ones that touch money.

Permissions follow lanes

The lane list from Chapter 5 now grows a column: who may run what.

Notice the middle row: running a workflow and signing off its expensive checkpoints are separable, and separating them is how you delegate the labor months before you delegate the judgment. The office manager runs the whole lead-to-invoice line; the owner's involvement has shrunk to two named checkpoints totaling seven minutes.

Data rules transfer with extra care. The never-paste list and the anonymize habit get taught explicitly at rung one, with the reason attached, not just the rule. A rule with a reason survives your absence; a bare rule lasts until the first busy Friday.

What stays with the owner

Three things do not delegate: red-lane authorship, the Friday decision (analysis can be watched; the decisions stay yours until they very deliberately do not), and the monthly Brain refresh sign-off. The office manager can draft the refresh; the owner reads the changelog before it ships, because the Brain is the one file every workflow trusts without checking.

Try it now

Pick your lowest-stakes calendar workflow and schedule rung one for next week: they watch, you narrate. Before the session, reread that workflow's runbook as if you had never met the system, and fix every step that assumes knowledge only you have. The runbook rewrite you are about to do is the subject of the next lesson.