Team Working Agreement

Definition

A team working agreement is a concise, team-written statement of how a team has agreed to operate: core collaboration hours, meeting norms, response expectations, review turnaround, how decisions are made, how disagreement is escalated, and how the agreement itself is changed. It is distinct from a Definition of Done, which governs the work, and from process documentation, which describes mechanics. The working agreement governs behaviour, and only the team can write it.

Why It Matters

Most persistent team friction comes from unstated, conflicting expectations rather than from bad intent. One engineer believes a message deserves an answer within the hour; another treats messages as asynchronous and answers twice a day. One person thinks a stand-up is for coordination, another for status. Both behave reasonably by their own lights, and the friction is attributed to personality. Writing the expectation down converts an interpersonal irritation into a decided rule, which is a far easier thing to enforce, revisit and onboard people into. Distributed and hybrid teams need this more, because the ambient signals that used to communicate norms — seeing someone at their desk, overhearing a decision — are gone.

What Belongs In It

1. Availability. Core overlap hours, expected response times by channel, and how urgency is signalled.
2. Meetings. Which are mandatory, cameras optional or expected, agenda requirements, and permission to decline meetings without one.
3. Code review. Target time to first review, and how blocking versus optional comments are marked.
4. Decisions. Who decides what, how consent is captured, and how long a decision waits for absent people.
5. Disagreement. When to move from comments to conversation, and who breaks a tie.
6. Focus. Protected time, interruption norms, and how support duty is shared.
7. Amendment. Reviewed at a set cadence; anyone may propose a change.

Keep it to one page. A working agreement that needs scrolling has become process documentation and will stop being read.

Real-World Example

A twelve-person team split across Auckland, Manila and Kraków ran three months of increasingly tense retrospectives. Complaints clustered around "people are unresponsive" and "decisions get made without us". Nobody was behaving badly; the Auckland group made decisions late in their afternoon when Kraków was asleep, and Kraków treated chat as fully asynchronous while Manila expected quick replies.

They wrote a one-page agreement in a 90-minute session. Three clauses did nearly all the work: a four-hour overlap window with all three regions present, a rule that any decision affecting more than one region must sit in a written proposal for 24 hours before being final, and a 24-hour target for first code review with a named daily reviewer rotation.

Two retrospectives later, both complaint categories had disappeared from the board. Median time to first review dropped from 31 hours to 9. Nothing about the people had changed and no tooling was introduced — the expectations had simply been made explicit and mutual. The team reviewed the agreement quarterly and amended it four times in the following year, mostly to tighten meeting norms.

Practical Lessons Learned

• The team must write it. A manager-authored agreement is a policy, and it will be complied with rather than believed.
• Write clauses about real friction only. Aspirational values ("we respect each other") change nothing; "we do not schedule meetings outside overlap hours" does.
• One page, plain language. Length is the main predictor of an agreement being forgotten.
• Revisit on a cadence. An unreviewed agreement is stale within two quarters, especially after team changes.
• It is an onboarding asset. New joiners learn norms in ten minutes that used to take two months to absorb.

Expert Tips

• Build the first version from the last three retrospectives. The friction list already exists; you are just converting it into commitments.
• Make each clause observable. "Respond promptly" cannot be assessed; "first review within one working day" can.
• Pin it where the team works — repository root and channel topic — not in a wiki nobody opens.
• Review it whenever a person joins or leaves. Team composition changes what the norms need to say.
• Let anyone call a clause out neutrally by referring to the agreement rather than to the person. That is the whole point of writing it down.

Common Mistakes

• Managers or coaches drafting it and asking the team to endorse it.
• Filling it with values statements instead of behavioural commitments.
• Letting it grow into a multi-page process manual.
• Writing it once at team formation and never revisiting it.
• Ignoring breaches, which teaches everyone the document is decorative.

Key Takeaways

• Working agreements make implicit expectations explicit, which is where most team friction lives.
• The team authors it; that is what gives it force.
• Keep it to one page of observable commitments.
• Draw the clauses from real, recurring friction.
• Review it on a cadence and whenever membership changes.

Related Concepts

Relates to Definition of Done, Sprint Retrospective, Cross-Functional Team, and Pull Request Review Discipline.