How to Write Team Communication Norms for Async Work: A Short Working Agreement
Mis à jour le Sep 25, 202610 min de lecture
A message arrives at 4:45 p.m. with “Can you take a look?” One person reads it as a request for immediate approval. Another assumes tomorrow is fine. A third reacts with a thumbs-up, which may mean “I saw this,” “I agree,” or “please stop sending notifications.”
Async work gets frustrating when teammates assign different meanings to ordinary communication. A short working agreement can remove much of that ambiguity without turning your team handbook into a constitution for Slack.
The most useful version is one shared page that stays close to the project work it governs. It should tell people how to interpret requests, where to record decisions, and when a written discussion has gone on long enough to justify a call.
Team norms are explicit, agreed expectations for behavior and for how work gets done. The broad category includes interpersonal expectations such as speaking truthfully and respectfully, avoiding talking down to others, and not interrupting, as illustrated in PCORI’s team norms activity guide.
Async communication norms cover a narrower set of situations:
These questions deserve written answers because people bring different assumptions to them. One teammate may protect two-hour focus blocks. Another may keep chat open all day. Someone several time zones away may see a “quick question” after their working day has ended.
The agreement should make ordinary messages easier to interpret. People shouldn’t have to study punctuation like an ancient manuscript to work out whether something needs attention today.
Start with situations that have already caused confusion. Think about a review that stalled because nobody knew who owned it, an “urgent” message that waited unnoticed, or a decision that vanished into a busy channel.
Turn each recurring problem into a behavior teammates can recognize and follow.
A vague norm says:
Communicate promptly and clearly.
A usable clause says:
Requests name an owner, the requested action, and a deadline. The owner acknowledges the request within our agreed working-hours window, even if the work will be completed later.
The second version defines what to do. It also gives the team something concrete to discuss when the norm isn’t followed.
Keep the agreement to one page if possible. The goal is a minimum viable process, not a rulebook covering every possible channel edge case. A 47-clause communication policy may be comprehensive, but nobody will remember clause 38 while a customer problem is unfolding.
The clauses below are patterns to adapt, not universal rules. Choose timing and channels based on your working hours, time zones, customer commitments, and actual habits.
Define an acknowledgement window separately from the time needed to resolve a request.
An acknowledgement tells the sender that the request has been seen and what happens next:
I’ve got this. I can review it by Thursday afternoon.
That response doesn’t promise a completed review immediately. It replaces uncertainty with a clear commitment.
A reasonable starting clause for some teams might be:
During stated working hours, direct requests are acknowledged within one working day. If the work will take longer, the owner gives an expected completion time.
That is an example, not a standard. Your clause should also state:
Choose a window your team can follow consistently. A customer support rotation and a product design team may need very different expectations. Copying another team’s response time without its staffing or obligations is a fine way to write a rule everyone quietly ignores.
Define “urgent” narrowly enough that it keeps its meaning. Your definition might include a same-day blocker, a customer-impacting problem that needs attention today, or a time-sensitive risk with a clear consequence.
Then name one escalation channel. Depending on the team, that could be a dedicated chat channel, a phone call, or another agreed method. An urgent message should include:
Ordinary chat remains asynchronous. The escalation channel is reserved for exceptions.
Avoid using urgency to compensate for late planning. “I forgot to ask for this last week” may create a pressing deadline, but the agreement doesn’t need to pretend it was an unforeseeable emergency.
A request should identify an owner, an action, and a deadline:
Priya, please review the launch email for factual accuracy by 2 p.m. Thursday. Reply with comments or “approved.”
Compare that with:
Launch email draft, thoughts welcome!
The second message could be an invitation, an announcement, or a request. Everyone can plausibly wait for someone else to act.
Your agreement should also distinguish acknowledgement from approval. A reaction or “seen” reply confirms receipt only. Consequential approvals should use explicit language such as “approved,” preferably before a stated deadline.
The working agreement explains how teammates interpret recurring messages. The project still needs a useful place for the brief, review, and final decision. A clear project documentation structure makes that easier to maintain.
Write this down directly. Don’t let every teammate invent a private interpretation.
| Message type | Suggested meaning of silence |
|---|---|
| Informational message | No reply is required unless the sender asks for one |
| Direct request | The request has not been accepted or completed |
| Review request | The review is still outstanding |
| Consequential approval | Approval has not been given |
Some teams use conditional rules such as, “If nobody objects by Friday, we will proceed.” That can work for low-risk, reversible choices when the deadline and consequence are explicit. It’s a poor default for consequential approvals.
If progress depends on a response, assign the reviewer and include a deadline. Silence is much easier to interpret when the original message was clear.
Chat and calls are useful for reaching a decision. Record the confirmed outcome in the project where the work lives.
A short decision note usually needs:
Assign someone to post the note after the decision. Otherwise, the project history becomes archaeology conducted through search results and half-remembered thread replies.
For a fuller method, read how to document decisions so your team can find them later. A project overview can also point people to the agreement and current decisions. See what to include in a project overview.
Async discussion works while people are making progress. Switch formats when writing starts adding delay or confusion.
Choose a threshold your team can recognize, such as:
The call should have a specific stuck point, rather than a vague instruction to “sync.” Afterward, one person writes the decision and next action back into the relevant project. The call resolves the discussion. The written note preserves the result.
Communication norms work better when the team discusses its actual problems together. Atlassian’s communication norms exercise also begins by identifying communication challenges and discussing them as a group.
A lightweight drafting session can follow this process:
New teams should set aside time for this discussion. Teams should also revisit their norms when membership changes, following University of Minnesota guidance. When someone misses an agreed norm, feedback and coaching can reinforce it before the team reaches for a longer policy.
Use this as a starting point. Replace the brackets with choices your team has discussed.
Async communication working agreement
Working hours and responses
Our usual working hours are [hours and time zones]. Direct requests are acknowledged within [window] during those hours. Acknowledgement confirms receipt and includes an expected completion time when the work can’t be finished immediately.Urgent work
Urgent means [same-day blocker, customer-impacting problem, or other agreed definition]. Use [escalation channel] and include the impact, required responder, and deadline. Ordinary messages remain async.Requests, reviews, and approvals
Every request names an owner, requested action, and deadline. Reviews ask for comments or a stated outcome. Approval requires an explicit “approved” response unless the request contains a previously agreed conditional rule.Silence
Informational messages may require no response. Silence doesn’t accept a request, complete a review, or grant approval. If the team intends to proceed without objections, the sender must state the deadline and what will happen after it.Decisions
After a decision in chat or on a call, [owner or role] records the outcome, date, context, and next action in [project location].Switching to a call
Move the discussion to a call when [chosen threshold]. The person who schedules it states the stuck point. After the call, [owner or role] posts a short written decision note.
Publish the agreement where teammates already do project work. The location matters because the document should be available when someone is making a request, reviewing work, or recording a decision. This is also why it helps to organize a team workspace that stays organized, rather than scattering important guidance across unrelated channels.
In Notework, a workspace contains projects, and all pages and collections belong to a project. A team could write the working agreement on a page in the relevant project, then keep decision notes near the work they affect. Teammates can use block-anchored comments to discuss a specific clause instead of leaving a vague comment about the whole page. The same structure supports the agreement, the project context around it, and the written record of what the team decided.
The tool stores the agreement. The team still has to make the choices, follow them, and fix the clauses that fail under real conditions.
Revisit the agreement when:
When someone misses an agreed norm, start with feedback and coaching. A missed deadline may reveal unclear wording, an unrealistic expectation, or a simple mistake. Repeated failures can then be addressed with better context than “please communicate better.”
See also how to document decisions so your team can find them later.
See also organize project documentation.
See also what to include in a project overview.
See also organize a team workspace that stays organized.
See also minimum viable process.