Operating Playbooks Written From Three Observed Cycles

A document that records button clicks is wrong inside about six weeks, because the platform ships a new interface and the page starts lying to whoever opens it. What holds is the decision layer: the number at which a campaign gets killed, the person who signs the extra spend, the threshold that forces an escalation. I write that layer, and only after watching three live cycles of the work: a full month of planning, one campaign from brief to close, and one monthly reporting cycle. Why I watch first: Every team documents the process it believes it runs. The gap between that and the process it actually runs is where the failures live. Sitting in the weekly meeting for three cycles, saying nothing, is how the real approval path becomes visible. At a publishing client, ad operations and the editorial desk each believed the other owned sign-off on sponsored content. Neither had ever refused anything. The backlog was five weeks long and nobody had a name to attach to it. What fixed it was one table. What the documents look like: Twelve to twenty pages, written into the wiki you already keep, whether that is Confluence, Notion or something older. Not a PDF. Not a file in my drive with your logo on it. Every page carries a named owner, a review date, and one line stating the condition under which the page should be deleted. Pages nobody owns are deleted at their review date, and that rule is written into the first page rather than left to goodwill. The decision-rights table: One table, one page. For each recurring decision: who decides, who must be consulted before, who is told after. Most disputes I get called into are two people who both believe they are the decider, or one decision nobody is willing to sign. Writing it down settles it, and the settling is the uncomfortable part, because it usually means telling a senior person that a decision they enjoy making is not theirs. What I will not write: Brand guidelines, tone of voice, or anything about how the work should sound. Tool configuration guides. Documentation for a team of one where a single person does the work and is not leaving; that is not a process problem, it is a bus-factor problem, and the answer is a hire. Documents intended for an ISO audit or a due-diligence data room, which are written to satisfy a reader outside the company while mine are written to be used inside it. Not for: Companies that want documentation to justify a restructure already decided. I will discover that during the observation cycles and stop the engagement. Teams that will not let me sit in the meetings where decisions actually get made; the observation is not negotiable, and without it I am transcribing opinions. How the handover runs: The last session is the team walking me through their own documents while I sit quietly and correct nothing. Whatever they cannot explain gets rewritten by them, not by me. A playbook the team cannot narrate is a playbook they will not open again. What it costs you in time: Roughly six hours of meetings I would be attending anyway, plus two hours each from the three people whose decisions carry the most weight. If a documentation project needs more time than that from your team, it has become a second job for them and it will not finish.