Every team has communication rules. Most of them are unwritten, several of them contradict each other, and new hires learn them by violating them: the reply-all that earned a talking-to, the DM that should have been a channel post, the “urgent” message sent at 9 p.m. that wasn’t.
Written guidelines — a communication charter — replace tribal knowledge with something visible. The hard part isn’t writing it; it’s writing something short enough to be read, specific enough to be followed, and honest enough to survive contact with how the team actually works.
Why guidelines fail
- They describe an aspiration, not the team’s real behavior. A charter that says “we reply within an hour” in a team that doesn’t is a document that teaches people to ignore documents.
- They’re too long. Nobody reads page four. Every rule past the first page halves the compliance with the earlier ones.
- Nobody owns them. Guidelines written during an offsite and never revisited describe a team that no longer exists.
- They police tone instead of routing. “Be respectful” is a value, not an instruction. The useful rules are about where and when, which are actually decidable.
The rest of this guide builds the version that avoids these traps.
One page beats ten
The format that works: a single wiki page titled “How We Communicate,” with five short sections — the channel map, response expectations, escalation, writing norms, and meetings. Half a page if possible. The test for every line: could a new hire act on this tomorrow without asking anyone? If not, rewrite or cut it.
Channel purposes
The heart of the charter is the channel map — one line per channel saying what it’s for. This is also the section that does the most work, because “which channel?” is the question people ask daily:
| Channel | Purpose | What belongs elsewhere |
|---|---|---|
| ann-team | Announcements everyone must see | Discussions — take replies to a topic channel |
| proj-launch | The launch project’s working channel | General company news |
| help-it | Requests for IT support | Incidents — use the escalation path |
| social-random | Non-work community | Anything someone must read |
Write the table with real channel names — the naming pattern behind them is covered in Building Consistent Naming Conventions for Team Channels. Include the rule for what to do when a conversation outgrows its channel: start a new one, link it from the old, and note it in the map.
Response expectations
Response-time rules remove the daily guesswork of “what does silence mean?” Keep them rough and honest:
- Direct mentions during working hours: reply within a few hours.
- General channel messages: read within a day; reply only if you have something to add.
- Email: one to two business days.
- Nothing requires a response outside working hours unless you’re on call.
State the urgent-path exception next to these — see the escalation section — so that the only route to instant response is a deliberate one, not the word “urgent” in a subject line. The same expectations, from the receiving side, are covered in Managing Notifications Without Losing Important Updates.
Escalation paths
Teams need exactly one agreed way to interrupt, and it should be boring: if it’s urgent and blocking, call the on-call number / post in the incident channel / page the duty person. Three properties make it work:
- It’s always on — someone is reachable by that path every working hour, and everyone knows who.
- It’s actually faster — if the urgent path responds like everything else, people stop using it and start marking everything urgent.
- It’s used sparingly by example — leaders who reserve it for genuine urgency teach the norm better than any written rule.
Writing norms
Three writing rules cover ninety percent of chat friction:
- Ask first, then context. The first line states what you need; background follows.
- Threads over spray. Reply in the thread, not as new top-level messages — each conversation stays one scrollable unit.
- Decisions get posted, not remembered. When something is decided, one line in the channel with owner and reason — the ritual from Practical Ways to Improve Workplace Communication.
Optionally add meeting norms here or in a fifth section: agendas required, notes posted, cameras optional. Keep the total under a page even if it hurts — the cut rules were probably aspirational anyway.
Roll it out and revisit it
- Draft it with the team, not for them. Thirty minutes in a retrospective: propose the draft, let people argue the response times. Guidelines people argued for are guidelines people follow.
- Publish in the obvious places — wiki home, channel topics, onboarding checklist. New hires read it in week one, per Best Practices for Onboarding New Team Members.
- Revisit quarterly. Fold into the review from Reviewing and Improving Digital Collaboration Practices: which rules are actually followed? Which are quietly dead? Fix the document or fix the behavior — either is fine; a mismatch is not.
That’s the whole practice: one page, five sections, a rollout that involves the team, and a quarterly reality check. The guidelines aren’t bureaucracy — they’re the difference between communication habits the team chose and habits that simply accumulated.