The Staff Is a Library
I finished Systemologyrecently, David Jenyns' book on removing yourself from your own business. Define one client journey. Put a name on every department. Pull the procedure out of whoever's doing the work and write it down, so someone else can run it without you.
Standard advice. Good advice, for a business with people in it.
I don't have people in it. I have myself, and a library of instructions I hand to an AI instead of a hire.
I ran the book through my practice anyway, and watched where it fit.
What Fit
Naming the one client journey fit without a seam. A client doesn't care who, or what, is doing the work behind the curtain. The trigger is still a trigger. The gap is still a gap. I mapped three live engagements against the same shape and they lined up, cleanly, on the first pass.
What Didn't
The next step didn't fit as cleanly. The book says the owner shouldn't write the procedure. Have the person doing the work talk through it, and let someone else write it down. Solo, that splits strangely: I do the work and narrate it, the AI writes it down. That part actually held.
What broke was somewhere else. Hand a person a written procedure, and partway through they'll notice the situation in front of them doesn't match the page. They'll pause. Hand a skill the same procedure and it runs straight through, situation or no situation. Noticing isn't in its job description.
There's no chapter for that. I built a layer of approval gates instead, sitting between whatever the skill produces and whatever gets treated as real. Nothing touches a client or a record without clearing one. That's the tax for hiring something that can't tell you when it's wrong.
The One Question
One question ended up doing more work than the rest of the framework combined. For every task, every hour: is this judgment, or is this production? Judgment is the read on a client, the call on what to recommend, the relationship. Production is the draft, the summary, the thing that gets typed. Judgment stays with me. It's the part clients are actually paying for.
Running that question against everything I do turned up a number I didn't expect. Somewhere around eighty percent of my own delivery process was already written down, in code instead of a binder, because a library of instructions already is a written procedure. I hadn't done that on purpose. I'd just been building tools instead of buying software for two years, and it turns out that's the same thing the book was asking of me.
The other fifth stayed unwritten, once I looked at it straight, on purpose. It's the read, the call, the relationship. Writing it down wouldn't organize it. It would sell it, and the business gets smaller the day that happens.
So here's the question the book left me with, more than any of its own:
Which fifth of what you do would be worth less the day you finally wrote it all down?