Codify
Codifying is structuring a play around its reader's situation, not its author's topic. The entry conditions come first and earn their place before the move does.
Play: situate every play
When: drafting any play.
The move: state the entry conditions first. What would a reader be seeing that tells them this play applies. Then the move, then the signals, then the conditions under which the play does not apply. Use the Play Template so the form stays consistent across the collection.
Signals: a reader in the middle of a situation can decide within a minute whether this play is for them.
When not to: never. This one is closer to a rule than a play, and I am keeping it as a play anyway because the discipline of writing its parts out is the point.
Play: name the forces
When: a play resolves a real tension, which is most of the time.
The move: say what pulls in each direction and what the play trades away. Cost before payback, dependencies on sponsorship, skills the team must already have. The forces section is the part naive playbook writers always skip, and its absence is arguably the root antipattern: a play stated without the forces it resolves is an instruction.
Signals: a reader can predict where their run of the play will hurt, before it does.
When not to: when the tension is trivial. Do not manufacture forces to fill the template.
Play: write for two readers (candidate)
When: the collection serves both people new to the practice and experienced practitioners, which is nearly always.
The move: structure every play so the expert can stop early and the novice can keep reading. The entry conditions and move at the top are the expert's version, they will know how to run it. The forces, signals, and instance below are the novice's version, showing how the principle lands in practice. Never write two documents, write one with a stopping point.
Signals: experienced readers describe plays as quick references, newer readers describe the same plays as teaching material.
When not to: when the play is genuinely expert-only, with entry conditions a novice could not recognise. Then say so at the top instead of diluting it.
This play is a candidate, drawn from GDS's guidance model for the Service Manual ("expose the why" with progressive disclosure), grounded in their user research rather than my runs.
Antipattern: the context-free recipe
Plays with no entry conditions, so readers cannot tell when they apply. The recipe gets run in the wrong situation, fails, and the failure gets blamed on the reader or the play rather than the mismatch.
This antipattern is not only an author failure. Readers, stakeholders, and auditors demand certainty, and the pressure to delete "it depends" is external and sustained. When the NAO criticised GDS guidance for leaving scope for interpretation, GDS's answer was the right one: there is no one-size-fits-all approach, guidance must stay open to interpretation so teams can apply it to their context, and asking teams to use their discretion is trusting them to do their job. Expect that pressure, and hold the entry conditions and when-not-to against it, because they are exactly what the pressure wants removed.
Antipattern: the everything playbook
Scope creep until the playbook is a methodology. A methodology is what a playbook becomes when the when-not-to sections are deleted and the plays are made mandatory. That is a one-way door, and commercial pressure pushes through it because certainty sells better than judgement.
The counter-discipline: a playbook earns each play. If a play cannot meet the evidence bar, it does not go in, and the gap gets a sentence admitting it rather than a padded pseudo-play.
Licensed under CC BY-SA 4.0.