The operating playbook

An operating playbook is the documented set of decision rights, workflows, and accountabilities that let a business run without relying on any single person’s memory or presence. It is the practical form of the operating architecture, the difference between a business that runs on its founder’s head and one that runs on its systems.

This guide covers what a playbook actually contains, how it differs from the documents most businesses already have (org charts, SOPs), and why the most common way of building one (document everything, all at once) is also the most common way to fail at it.

What a playbook actually is (and is not)

Most established businesses already have documents that look like pieces of a playbook. They are not the same thing.

Document	What it does	What it does not do
Org chart	Shows reporting lines	Does not say who owns which decisions
SOP / work instruction	Describes how a specific task is done	Does not cover non-standard situations or judgement calls
Role description	Lists responsibilities for a role	Does not map how work flows between roles
Operating playbook	Defines decision rights, end-to-end workflows, and accountability across the business	Leaves none of these gaps

The playbook sits above the other three. It answers the question a founder-dependent business cannot: when something non-standard happens, who decides, using what authority, and what happens next?

The three things a playbook must contain

1. Decision rights: who owns which decisions

This is the part most businesses are missing, and it is the most important. A decision right is the authority to make a call, within defined limits, without asking permission. A responsibility only describes what someone does.

In a founder-dependent business, decision rights are implicit and almost all route to the founder. The default operating system is “ask the founder”. The playbook makes the implicit explicit: it names the decisions, names the owner of each, and sets the limits within which they can act.

A workable decision-rights map covers, at minimum:

• Financial decisions: spending authority by amount, contract approval by value, hiring authority by role and salary band.
• Operational decisions: who handles customer escalations, supplier disputes, quality issues, and at what threshold they escalate.
• Strategic decisions: which decisions are reserved for the founder or leadership, which are delegated, and to whom.

The test of whether decision rights are real: if the founder is unreachable for two weeks, do decisions get made, or do they pile up? If they pile up, the rights are not real; they are still implicitly the founder’s.

2. Documented workflows: how work flows end to end

Most businesses document tasks (how to do X). Few document workflows (how work moves from one role to another, end to end, including the non-standard branches). The workflow is what the team needs to carry the work whether or not the founder is in the room.

A documented workflow covers:

• Trigger: what starts the workflow (a customer enquiry, a quality issue, a new hire, a renewal).
• Steps and handoffs: who does what, in what order, and what gets handed to whom.
• Decision points: where judgement is required, who applies it, and what they can decide without escalating.
• Escalation: what gets escalated, to whom, and on what timeline.

Documenting every edge case would be a waste of effort. Document the 80% of work that repeats, well enough that the team can run it on its own, and define clearly what the 20% that genuinely needs the founder looks like.

3. Accountability: who owns each outcome

Accountability is different from responsibility. Responsibility is “I will do the work.” Accountability is “I own the outcome, and I am answerable for it whether or not I did the work myself.”

In a founder-dependent business, accountability often sits implicitly with the founder: everything is, ultimately, the founder’s problem. The playbook redistributes it: each major outcome (revenue, delivery quality, cash flow, team retention) has a named owner with the authority to move it.

The redistribution is what makes the architecture hold. A team that has responsibility without authority will still route every decision upward; a team that has both will carry the weight.

How to build one (and how not to)

The most common playbook failure is trying to document everything at once. It produces a large document nobody uses, the project runs out of momentum, and the business reverts to running on the founder’s head. The pattern is so consistent it is almost a law.

The approach that actually works is the opposite: build one corner at a time.

1. Survey where the business still leans on the founder. Twenty indicators across five areas (customers, decisions, knowledge, team, and systems and authorities) show where the dependency concentrates. Each area takes the colour of its weakest indicator, and the weakest area is the starting line.
2. Build that area until the team carries it. Decision rights for that area, documented workflows for that area, named accountability for that area.
3. Prove it holds. A task counts as handed over only when a named person has run it for four weeks without the founder stepping in. A hard week, an absent founder or a key person away will show whether it holds. If it does, the area is done. If it does not, it is not done yet: the test is the point.
4. Move to the next area. Only once the previous one is proven.

The result is a partial playbook that actually works, which is infinitely more valuable than a comprehensive one that does not.

Why playbooks fail

The three patterns I see most often:

• Documenting everything before proving anything. Produces shelfware. Build incrementally, prove each part.
• Documenting tasks instead of workflows and decision rights. Produces SOPs the team already knows. The gap is almost always in who owns the judgement, not in how the task is done.
• No test under pressure. A playbook untested under absence is an assumption. The whole point is that the team carries the business whether or not the founder is in the room, and the only way to know is to test it.

What this looks like when it is done

When the work is complete, the business has a different shape. Decisions that once piled up on the founder are made well by the people who now own them. Workflows run on documented systems rather than on memory. Each major outcome has a named owner with the authority to move it. The founder can be unreachable for two weeks and the business carries its own weight.

That is what a business that runs on its system looks like in practice: an observable state, tested under absence, that removes the valuation discount and the lender caution that founder dependency imposes. You keep control. The load moves to your team.

---

Want to know which corner of the playbook to build first? Take the free Self-Check: 20 questions across five areas, about ten minutes, with a red, amber or green colour for each area and a short list of where to start. Your weakest area is the starting line.

Frequently asked questions

What is an operating playbook?

An operating playbook is the documented set of decision rights, workflows, and accountabilities that let a business run without relying on any single person's memory or presence. It is the practical form of the operating architecture, the thing that turns 'how things work here' from something the founder carries in their head into something the team can execute.

How is a playbook different from an org chart or SOPs?

An org chart shows who reports to whom; SOPs describe how specific tasks are done. A playbook sits above both: it defines who owns which decisions, how work flows end-to-end across roles, and what happens when something non-standard arises. It is the architecture that makes the org chart and the SOPs actually function.

How long does it take to build an operating playbook?

For an established business of 10 to 100 people, building a playbook one area at a time is measured in months per area, not weeks. Each part has to be documented, handed over, and tested (a named person runs it for four weeks without the founder stepping in), which is why a full arc typically runs about 12 months.

Does every business need a full playbook?

No, and trying to document everything at once is one of the main reasons playbook projects fail. The right approach is to start with the area where the business is most dependent on the founder, build that area until the team carries it, and only then move to the next. A partial playbook that actually works beats a comprehensive one that lives in a binder.