Draft One Play for One Team and Get It Right

This is the full playbook from “Write a Short Playbook That Explains Why.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Use this template, Building Your First Three Plays, to draft the first version of your engineering playbook. Choose one team and one play. Get that play right before you write the next one.

1. Choose the first play to build: version control, code review, or CI/CD. Look at the most repeated arguments, the most recent incident, and the complaint that keeps surfacing in your one-on-ones. Don’t choose the play that’s easiest to write. Choose the play whose absence costs the most today. Break ties toward the play that protects the work that makes you different.
2. Write the purpose in one sentence before you write a single rule. Ask what the play protects. Don’t write “we need code review because good teams do code review.” That’s a borrowed justification. Write something specific: “Code review exists so that no single engineer’s blind spot becomes a production incident, and so our quality standard transmits to newer engineers without a formal training program.” If you can’t state the purpose in one sentence, don’t write the rules yet. You don’t know what they have to achieve.
3. Write the specific guidance, and trace every rule back to the purpose sentence. For each instruction (review response time, branch naming, deployment gate requirements), ask one question: does this rule protect coordination, or does it replace judgment that belongs to the engineer? Keep the first kind. Delete the second, or rewrite it as guidance instead of a mandate. If you can’t trace a rule back to Step 2, either the rule doesn’t belong or the purpose sentence isn’t finished.
4. Draft the play with at least one engineer who’ll have to work under it. Make that engineer a co-author from the start, not a reviewer at the end. Ask what goes wrong today that this play has to prevent, and make sure the play addresses what they named.
5. Define one metric that will show, within a quarter, whether the play works. Pick from lead time for changes, review turnaround, deployment frequency, or change failure rate, whichever maps most directly to Step 2. If the metric doesn’t move after a quarter, rewrite the play. Don’t enforce it harder.
6. Write the second play only after the first has run for a full quarter. Build the playbook one tested play at a time, with real usage data behind each addition. That beats a complete playbook written at one offsite and never tested before it carries load.

Try this with AI.

“Here are three attempts at a one-sentence purpose for our code review play. Tell me which one a new engineer could actually act on, and which ones only restate the rule in nicer words.”

All of the playbooks are listed on the playbooks page.