“Reply quickly” means different things to teammates in different time zones. A remote working agreement turns assumptions like that into explicit choices: which channel to use, when a response is expected, and what to do when a decision cannot wait. It is a team-owned way of working, not a policy imposed on people after the meeting.
Separate a norm from an exception. State the normal channel, expected response window and decision owner, then define what changes when an issue is urgent or a teammate is offline. Keep personal availability and sensitive details out of the shared agreement. Review the rule when the team’s working hours or responsibilities change.
A shared collaborative whiteboard gives everyone a place to propose and revise those choices. Atlassian's Working Agreements Play suggests discussing communication, availability, feedback, and escalation together. The example below shows how to make those topics specific for one distributed team.
Start with friction the team recognizes
Imagine a product team working in Berlin, Seoul, and São Paulo. A designer posts a question near the end of their day, an engineer sees it the next morning, and the product manager assumes the silence means approval. The agreement should address that specific handoff, not recite general virtues such as “communicate well.”
Ask each person to write down one interaction that repeatedly stalls and one that already works. Keep individual constraints visible: local working hours, planned leave, and whether a message can reasonably wait for the next overlap. Avoid asking people to publish private health or family details on a shared board.
Decide what each channel means
List the channels the team already uses and give each a purpose. For example, a project document holds decisions and context; team chat is for quick coordination; a scheduled call is for a disagreement that needs conversation. A message should not become urgent merely because it was sent in chat.
| Situation | Default route | Expected response | When to escalate |
|---|---|---|---|
| Question about a draft design | Comment on the shared work item | At the next working overlap | If the decision blocks an agreed delivery date |
| Decision that affects several teams | Short decision note with options | After named reviewers have context | If no owner is clear |
| Customer-facing incident | Existing incident channel | Follow the incident procedure | Use the on-call route, not the normal design thread |
These are example rules, not universal service levels. The team should set its own realistic response windows and align urgent cases with its actual incident policy. If a manager drafts the first version, invite the team to change it.
Write behaviors people can follow
Turn each concern into an observable agreement. “Respect time zones” is hard to apply. “Mark decisions needed before Thursday's overlap, and identify the decision owner” tells a teammate what to do. “No response outside working hours is assumed to be approval” closes the gap in the Berlin–Seoul–São Paulo example.
Keep the agreement short enough to use during real work. A useful first version might cover availability, decision records, feedback, meeting preparation, and escalation. For each rule, ask what happens when it fails. If nobody knows how to raise a blocker, the agreement is incomplete.
Make the agreement in Boardmix
Create one Boardmix board with three zones: friction we experience, proposed agreements, and agreed wording. Let contributors add notes before the meeting, then group duplicates without erasing different needs. Add the final text as readable cards, with the channel, owner, and exception path beside each other.
Share the board with new teammates as context, but put the agreed wording in the team's usual source of truth as well. Boardmix is the collaborative workspace for shaping the agreement; it does not automatically enforce response times or replace an incident system.
Revisit it when the work changes
Agree on a trigger for revision: a new time zone, a changed on-call arrangement, or repeated confusion about a channel. Ask which rule helped and which one was ignored because it was impractical. Edit the wording with the people affected. The goal is a working agreement that people can use, not a decorative team charter.
![[Full Guide] Cluster Diagram](https://cms.boardmix.com/images/image/article-images/cluster-diagram.png)
