A working agreement is a team-made set of observable commitments about how members coordinate, communicate, decide, and respond when work goes off track. Create it from real friction and work needs, state behaviors rather than values alone, make power and policy boundaries explicit, and review whether the agreements help. It does not override organizational policy.
Who this is for: New, changing, remote, or cross-functional teams that need explicit norms for coordinating work and handling predictable friction.
- Start from recurring work situations and friction instead of copying generic values from another team.
- Write observable behaviors, exceptions, and escalation routes that team members can actually use.
- Review agreements after real events and revise them when the team's work, membership, or constraints change.
Ground agreements in the work
Map situations where coordination matters: urgent requests, focused work, decisions, handoffs, reviews, time-zone overlap, mistakes, and disagreement. Ask what currently helps and where assumptions conflict. A team does not need a slogan for every virtue. It needs guidance at moments where different reasonable habits create preventable friction.
Separate team discretion from organizational policy, role authority, and legal or safety requirements. The group can agree how to prepare a decision, but cannot vote away an accountable owner's duty. It can set communication preferences, but should not create rules that pressure people to disclose health, family, or other private information.
Write observable commitments
Translate values into behavior. 'Respect focus time' might become 'use the urgent channel only for issues that cannot wait until the next work period, include the impact, and name the decision needed.' Observable wording gives the team something to discuss when interpretations differ without claiming every situation is predictable.
Include normal behavior, exceptions, and the repair path. A response expectation should say which channel it covers and what happens when the owner is unavailable. A decision norm should state how input is gathered, who decides, and how rationale is shared. Avoid rigid rules that ignore role, accessibility, customer, or incident needs.
Reach informed agreement
Let members propose, question, and revise the language. Pay attention to hierarchy: silence from a junior employee does not prove a norm is workable. Invite concrete counterexamples and written input. Managers should state constraints openly rather than steering the group toward a preferred answer while describing the exercise as collective choice.
Choose a manageable set and identify unresolved tensions. Full enthusiasm is not required, but people should understand the commitment, the reason, and how concerns will be reviewed. If an agreement affects another team, involve them or label it as an internal request rather than imposing a unilateral service expectation.
Use and revise the agreement
Place the agreement where work happens and refer to it neutrally when friction occurs. The document should help open a conversation, not serve as a weapon. Ask what happened, whether the agreement applied, and whether an exception or system obstacle mattered before concluding that a person simply ignored the team.
Review after membership changes, significant incidents, new operating demands, or a planned interval. Use examples of where the norm helped or failed. Remove rules nobody needs, clarify ambiguous language, and retain useful flexibility. No template supplies a universal response time or meeting pattern; calibrate from team, customer, and organizational evidence.
Agree on urgent requests
A hybrid team uses direct messages for everything, causing important requests to disappear and routine questions to interrupt focused work.
- Map recent request types and identify which needed immediate attention, which needed a visible owner, and which could wait.
- Draft channel behaviors for urgent, owned, and routine requests, including the information a request needs and an unavailable-owner route.
- Invite counterexamples from different roles and time zones, then revise the wording around customer incidents and accessibility needs.
- Try the agreement, discuss real cases at a review, and adjust from the team's own operating evidence.
Working agreement canvas
Use one row for each recurring situation and keep the final agreement short enough to consult during normal work.
- Situation and need: recurring moment, people affected, current friction, and desired operating result.
- Normal behavior: observable action, channel or forum, information required, ownership, and decision authority.
- Exception and repair: urgent case, unavailable owner, policy boundary, conflict route, and how a miss is discussed.
- Review: example to observe, feedback route, date or trigger, owner of updates, and teams needing consultation.
Common mistakes
- Copying another team's values without examining the situations that create friction in this team's work.
- Writing absolute response and availability rules that ignore roles, time zones, accessibility, and genuine exceptions.
- Using the agreement to accuse an individual instead of examining whether the norm was clear and workable.
Try one
A team agreement says, 'Assume positive intent,' and a member uses it to shut down discussion of harmful impact. How should the agreement change?
A strong answer removes the phrase as a debate-ending rule and replaces it with observable behavior: clarify what occurred, hear the affected person's account, separate intent from impact, address repair, and use formal routes for serious conduct. The revision should preserve fair inquiry without requiring anyone to dismiss evidence or privately resolve matters that organizational policy must handle.
Sources
- Atlassian working agreements playA facilitated method for agreeing how a team will communicate, decide, and work together.
- Atlassian roles and responsibilities playA practical exercise for clarifying ownership, responsibilities, and gaps across a team.