← Back to Blog
playbookdocumentationModerationprinciplescommunity operationsclarity

Three Questions Every Line in Your Community Playbook Has to Survive

How to tell a principle from a tactic, and why anything a moderator cannot act on during an incident is taking up space.

August 4, 2026

Article image
Before a line goes in your community playbook, check three things: can a moderator read it once and get it, does it hold in more than one type of server, and will anyone actually do something with it under pressure. Label what remains as a principle or a dated practice, and cut the rest.

Two in the morning

It is two in the morning. Links are appearing faster than anyone can delete them, a member who has been around for two years is escalating an argument in a public channel, and the moderator on shift has just opened the playbook for the first time in months.

Whatever happens in the next four minutes is the only real test that document will ever face. Everything before it was rehearsal.

Most playbooks fail that test, and the reason has nothing to do with effort. They were written for a reader who does not exist, a calm and curious colleague with time to appreciate the reasoning. The reader who arrives is tired, under pressure, and scanning for the one line that tells them what to do.

Three filters keep a document honest about who it serves.

Filter one: comprehension on a single read

Start with comprehension, because nothing downstream matters if a line has to be explained.

The test is blunt. Hand the line to a teammate and count the clarifying questions. One question means the line failed, and the answer you gave is the instruction that should have been in the document.

Certain patterns produce those questions reliably.

  • A term the author defined internally and never on the page.
  • Several conditions folded into one sentence.
  • A description of the outcome you want, with no mention of the action that gets there.
  • Softened phrasing that leaves a moderator guessing whether they have permission or an obligation.

Reading each line while imagining yourself exhausted catches nearly all of it. Anything that requires going back to the start of the sentence gets rewritten.

Filter two: three servers with nothing in common

The second filter is the one most documents never apply, and it separates two things that look identical on the page.

Test whether a line survives in three communities that have nothing in common. Not three of the same kind. Something like a gaming server, a product support server, a trading server, and a brand server. Survival across all of them means you have a principle. Survival in one means you have a tactic.

Put two candidate lines side by side and the difference is obvious.

  • Pin a poll in general at two on Tuesday afternoon. This depends on a particular audience, a particular timezone, and a particular weekly rhythm. Lift it out of that context and it collapses.
  • Engagement is a member spending attention they could have spent somewhere else. True in a gaming server and in a support server. True in a trading community and in a brand community. True at forty members and true at a million. Nothing about it leans on size or category, which is what qualifies it as a principle.

Why the distinction earns its keep: a principle tells a moderator how to think when the document has nothing specific to say, and the document has nothing specific to say about most of what actually happens. A tactic answers one case, and only while the conditions behind it still hold.

The label carries more weight than the line

Tactics still belong in the document. A specific instruction is often the most useful thing a new moderator can receive, and it shortens the first week considerably.

The damage comes from leaving them unmarked. An unmarked tactic gets read as policy, which is how a team ends up running a Tuesday poll to an empty room because the document said so and the reason left years ago. And when the tactic finally stops working, a moderator holding no principle underneath it will either invent something or stall.

Marking solves it.

Playbook Structure:

Article image

Owner: the person accountable during an incident Adding a line: read it aloud to a moderator who will have to use it

Filter three: does anyone behave differently

The third filter is where most surviving material finally gets cut.

A great deal of playbook content is written by ego, and not in a shameful way. Articulating something subtle about how communities behave is satisfying, and a line that lands feels like it belongs in the most important document you own. The correction arrives when you sit with the moderation team, point at the line, and ask what anybody does with it during an incident. Frequently the answer is nothing at all. They read it, they nod, and their behavior is identical either way.

No behavioral change means the line is decoration. It can be accurate. It can be genuinely perceptive. It is still taking up room.

Why the timing in the question matters

Framing the question around two in the morning does specific work, and it is worth understanding why.

At two in the morning the audience disappears. No client is listening, no peer is reading over a shoulder, nobody is going to compliment the phrasing. What remains is one person, one problem, and one document. Material that holds up in that setting is operational. Material that does not has a home elsewhere, in an article, a stakeholder deck, or a training session, and putting it there is not a demotion. Letting both kinds share one file is the actual error.

Principles compress, tactics accumulate

Here is the argument for bothering with the second filter at all, and it comes down to compression. A single well-formed principle does the work of a dozen tactics.

Hold the engagement definition in mind and an entire class of decisions resolves without further guidance. Scheduling an event while most members are asleep answers itself. A channel that produces activity while costing members nothing to skim answers itself. A giveaway that captures attention from people who were never staying answers itself.

Not one of those needs its own line, because the principle already covers all of them.

Tactics refuse to compress. Each covers one case, so a playbook built mostly from tactics expands until nobody can hold it in their head, at which point it gets ignored for being long. Length is usually the symptom. Missing principles are the cause.

The failure mode that catches strong teams

Writing that impresses a room and writing that functions during an incident come from different instincts, and the first instinct is louder. Explaining community dynamics well to a stakeholder is a real skill, and material built for that purpose has already done its job in the deck it was built for. Folding it into the operational document feels like consolidating and works like diluting.

Checking for it is simple. Read a line and ask who it was written to satisfy. Some lines exist to help a moderator choose. Others exist to prove the author understands community, and those are the lines that survive every review, because no one wants to argue with a statement that happens to be true.

Accuracy is not the bar. Usability is.

An afternoon of cutting

Auditing an existing playbook takes an afternoon. Read it aloud with the moderation team and stop after every line.

  1. Did anyone need a follow-up to understand it.
  2. Would it hold in a community with nothing in common with this one.
  3. What does a moderator do differently because it exists.

Mark the line as a principle, a practice, or a cut, and refuse to spare anything on the grounds that it was hard to write. Teams routinely remove more than they planned to. The part that stays gets read, often for the first time.

Brevity is not the real prize, though. Behavior is. Moderators read short documents and skim long ones, so every line that passes the filters raises the chance the next line gets read at all. A document people finish is the only kind that changes a decision made under pressure.

Ownership keeps the filters alive

One structural note makes the filters stick, because a test nobody owns gets skipped by the third month.

Give the document a single owner and a standing review. The owner is whoever is accountable for what happens during an incident, not whoever writes most fluently, and those are frequently different people. The review exists to catch practices that outlived their reason, which is the failure mode that produces bloated playbooks even in careful teams.

Adding a line should require passing the filters out loud, in front of at least one moderator who will have to use it. That single constraint prevents most of the drift, because it is hard to defend a decorative sentence to the person who will be holding the document while the room is on fire.

The bill arrives at handover

The delayed benefit arrives at handover, which is where a decorative playbook finally sends its bill. A new moderator receives the file without the thinking that produced it, and every ornamental line becomes something to decode while they are still learning the room. Principles hand off cleanly because they teach a way of reasoning. Decoration hands off as confusion.

Treat it as operating risk

For leadership the framing is straightforward. Playbook quality is operating risk. A community running on a document nobody opens is running on whoever happens to be awake, which makes response quality a function of the shift schedule and impossible to forecast. Passing every line through three filters converts the document into something a team can be held to, and that is the whole distance between a policy and a hope.

FilterThe questionWhat failing it means
ComprehensionUnderstood on one read, no follow-up?Rewrite it using the explanation you gave
PortabilityHolds in three unrelated servers?Keep it, but label it a dated practice
UsabilityAnyone acts on it during an incident?Cut it, or move it to a deck or an article

Write for the person at two in the morning. Anything else in the file was written for someone else.


A playbook is judged once, quietly, by somebody tired. Build it for that reader and the rest takes care of itself.

danieljeong.org

Want a properly managed community?

Get Your Free Analysis →