Write Down How Your Playbook Gets Changed

This is the full playbook from “A Playbook Has to Change When the Business Does.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

This exercise builds the mechanism that decides when the rules change, and how, and it has to be specific to your team. Without it, the decision goes to whoever is loudest when something breaks.

1. List your current plays and sort each as core / immutable or situational. Include the plays your team follows but has never written down; an unwritten play is information too. For each, apply the test from “A Playbook Has to Change When the Business Does”: if someone deviated and the result was fine, would the conversation be about the situation or about the person? “The situation” means the play is situational, so write it with room to flex. “The person” means the play is core, so it changes only through a deliberate, documented decision, never through individual discretion under pressure.
2. Name your five leading indicators. Start from the five signal categories in that chapter: funding or ownership shifts, customer concentration, new regulatory exposure, incident trendlines, team composition. Write the specific, observable version of each that applies to your organization now. Don’t write “watch for regulatory changes.” Write something you can detect: “if average contract size in the pipeline crosses $200K ACV, revise the security and compliance playbook before procurement asks for evidence we don’t have.” Add a sixth indicator: evidence that something which used to differentiate you is becoming standard in your market.
3. Set the review cadence and name the stewards. Pick a fixed interval; quarterly is a reasonable default. Assign one person to own each major playbook category, and don’t assign yourself by default. Write down what someone must bring to a review: a specific incident, a specific friction report, or a specific proposed change. A vague sense that something feels wrong isn’t enough.
4. Build the three-input collection habit. Before each review, collect three kinds of evidence: cases where the team followed the playbook and the outcome was still bad, cases where someone deviated and the outcome was good, and friction reports where people routinely work around a step that gets in the way. Choose one place to capture those examples as they happen: a shared document, an issue tracker, a dedicated channel, whatever your team will actually use. The point is a running record built through the quarter, not evidence reconstructed from memory the week before the review.
5. Write the escalation rule for core changes: a core or immutable play must not change on one person’s say-so. Decide in advance who approves it: you alone, you and a peer executive, or a documented decision with the board if the play touches financial controls or compliance. Write the rule down before you have to negotiate it under deadline pressure, which is the worst possible moment to invent a governance process.
6. Pilot every change before you mandate it, including the ones you personally like. Adopt a standing rule: no playbook change moves from proposal to mandate without a two-to-four-week pilot on a limited scope. CTOs skip this step most often when they’re confident the change is correct, which is exactly why the pilot has to be a rule rather than a judgment call.

Write this down once, deliberately, so your process for changing process is never implicit. A team that has never written down how it changes its own playbook makes that decision by accident every time, usually in favor of whoever pushed hardest. That’s the ungoverned, invisible variability a real playbook exists to remove.

All of the playbooks are listed on the playbooks page.