Why Playbooks Compound Faster Than Shared Code

The highest-leverage thing in my portfolio is not a shared library. It is a shelf of playbooks. A playbook is a written procedure for a recurring job: how I launch a product, how I cut over a domain, how I onboard an agent, how I close the month. Code compounds inside one stack. A playbook compounds across every stack, every tool, and every person or agent that ever runs the job. That is a wider surface, and it decays slower.

People underrate this because a playbook feels less impressive than a framework. It is a document. But the document outlives the framework. I have rewritten the same feature three times as tools changed. I have never had to rewrite the playbook for launching it.

Why code has a narrower blast radius than a playbook

Shared code only helps the products that can consume it. Wrong language, wrong runtime, wrong framework, and the library is dead weight. A playbook has no such boundary. The procedure for "verify a backup by restoring it" is true whether the box runs Postgres or MySQL, whether you deploy with one tool or another. The knowledge is portable in a way the code never is.

That portability is the compounding. Every time I face a job I have done before, I do not re-derive the steps. I open the playbook, follow it, and improve it if something changed. The cost of the tenth launch is near zero because the first nine wrote the manual. This is the same economics as the marginal cost of the next product, except the asset is prose, not a repo.

Playbooks make the work delegable, including to agents

A shared library needs an engineer to wield it. A playbook can be handed to a new hire, a contractor, or an AI agent, and the job gets done the same way every time. That is the difference between knowledge that lives in your head and knowledge that lives in the system. When I onboard an AI agent to a company, the playbooks are what it reads. The agent is only as good as the procedures I wrote down.

This is why I treat playbook-writing as real work, not admin. The moment I do something twice, I write down how. The write-up costs twenty minutes. The payoff is that the job is now transferable forever. Compare that to the self-serve docs for an internal platform: same principle, applied to the shared code instead of the operating procedure. Both turn tacit knowledge into an asset.

What makes a playbook compound instead of rot

Not every document is a playbook. A good one has three properties.

• It is a procedure, not an essay. Numbered steps you can follow at 2am. Commands, not vibes. If it needs interpretation, it will be interpreted wrong.
• It has a trigger. "Run this when a domain needs to move." A playbook without a clear when-to-use is a document nobody opens.
• It gets updated at the point of use. The person running the job fixes the doc when a step is stale. A playbook that is only edited in dedicated "documentation time" is already dead.

That last one is the whole game. Playbooks decay if they are write-once. They compound if every run is also an edit. I bake the update step into the procedure itself: the final line of every playbook is "if any step was wrong, fix it now."

Where playbooks beat a shared foundation outright

Shared code is the right tool when correctness must be identical across products, which I argued in copy-paste vs a shared dependency. Playbooks are the right tool when the job spans systems that will never share code: infra, billing, legal, launch, incident response. You cannot put "how to handle a customer data request" in a library. You can put it in a playbook, and then every product handles it the same way regardless of stack.

This is also why playbooks survive the thing that kills shared code: model and tool churn. Every model upgrade erases a capability edge, and every framework migration erases some of your shared library. The playbook that describes your judgment survives both, because it encodes what you decided, not which tool executed it.

Start the shelf today

You do not need a documentation system. You need a folder and a habit. The next time you do something you will do again, write the steps as you go. Give it a trigger line. Fix it the next time you run it. In a year you will have a shelf that lets one person, or one agent, run work that used to require remembering everything.

I keep my playbooks in the same project memory the build platform reads at Bootspring, so the procedure and the code that executes it sit side by side and an agent can follow both. Shared code is worth building. But if you only had time for one compounding asset, write the playbook. It reaches further and it lasts longer.