Working Agreement Template¶

A working agreement is a team's explicit contract about how they work together. It covers communication norms, decision-making processes, and shared expectations—the things that are often assumed but rarely discussed. When assumptions differ, friction follows. A working agreement surfaces those assumptions and turns them into shared commitments.

What problem this solves¶

Teams fail in predictable ways when norms are implicit:

People have different expectations about response times, meeting etiquette, or code review turnaround.
Conflicts arise from misaligned assumptions, not bad intentions.
New team members don't know "how things work here."
Frustrations accumulate because there's no legitimate way to raise them.

A working agreement solves this by making expectations explicit, creating a shared reference point, and providing a mechanism for the team to evolve its norms over time.

When to use this¶

Create a working agreement:

When forming a new team.
When a team is experiencing friction or misalignment.
After significant team composition changes.
When transitioning to new working patterns (e.g., remote-first).

Review the working agreement:

Quarterly, as part of a retrospective.
When team members raise concerns about norms.
When circumstances change (new tools, new processes, new constraints).

Roles and ownership¶

Role	Responsibility
Team	Creates the agreement together. Commits to following it. Raises concerns when it's not working.
Tech Lead / Manager	Facilitates creation. Ensures the agreement is documented and visible. Models adherence. Initiates reviews.

A working agreement is only valid if the team creates it together. A manager-imposed set of rules is not a working agreement—it's policy.

How to create a working agreement¶

Step 1: Set up the session (90 minutes)¶

Gather the team. Explain the purpose: "We're going to make our working norms explicit so we have shared expectations and a reference point for resolving friction."

For remote teams, use a collaborative whiteboard (Miro, FigJam, etc.).

Step 2: Brainstorm norms (30 min)¶

Prompt the team to add items in these categories:

Communication: How do we communicate? What channels for what purposes? What are response time expectations?
Meetings: When do we meet? What are our meeting norms? How do we handle async participation?
Code and delivery: What are our PR expectations? Review turnaround? Definition of done?
Collaboration: How do we make decisions? Handle disagreements? Share information?
Focus and availability: Core hours? Meeting-free blocks? How do we signal focus time?

Use silent brainstorming first, then share and discuss.

Step 3: Discuss and refine (30 min)¶

Group similar items. Discuss anything that's unclear or where the team isn't aligned. The goal is consensus—everyone should be willing to commit, even if it's not their preference.

For contentious items, try: "Can we try this for a month and revisit?"

Step 4: Document and commit (15 min)¶

Write up the final agreement. Every team member should be able to say "I commit to this."

Post the agreement somewhere visible—team wiki, Notion, top of the team channel.

Step 5: Review regularly (ongoing)¶

In quarterly retros, ask: "Is our working agreement still serving us? What should change?"

Update the agreement as needed. It's a living document.

Signals that working agreements are working¶

Team members reference the agreement when friction arises.
New team members can onboard to team norms quickly.
Conflicts are about the work, not about misaligned expectations.
The agreement evolves as the team learns what works.

Failure modes and mitigations¶

Failure mode	What it looks like	Mitigation
Agreement ignored	Created and never referenced; norms revert to implicit	Review in retros; leadership models adherence
Too detailed	50-item list that no one remembers	Keep to essentials; 10–15 items max
Manager-imposed	Manager writes it; team doesn't feel ownership	Team creates collaboratively; manager facilitates
Never updated	Agreement from 2 years ago doesn't match current team	Quarterly review; update when circumstances change
Used as a weapon	Agreement cited to win arguments rather than solve problems	Focus on intent; address underlying tensions

The template¶

Working agreement document¶

# Working Agreement: [Team Name]

**Created:** [Date]
**Last updated:** [Date]
**Team members:** [Names]

---

## Communication

### Channels

| Channel               | Use for                                      | Response expectation             |
| --------------------- | -------------------------------------------- | -------------------------------- |
| Slack #[team-channel] | Day-to-day team discussion                   | Within 4 hours during work hours |
| Slack DM              | Urgent or sensitive 1:1                      | Within 1 hour if urgent          |
| Email                 | External communication, formal documentation | Within 24 hours                  |
| [Project tool]        | Task updates, async decisions                | Check daily                      |

### Norms

- We default to public channels over DMs for team-relevant discussions.
- We use threads to keep conversations organized.
- We acknowledge messages with emoji if we've seen them but can't respond immediately.
- We don't expect responses outside working hours unless explicitly flagged as urgent.

---

## Meetings

### Standing meetings

| Meeting  | Cadence   | Duration | Purpose                            |
| -------- | --------- | -------- | ---------------------------------- |
| Standup  | Daily     | 15 min   | Sync on progress, surface blockers |
| Planning | [Cadence] | 60 min   | Plan upcoming work                 |
| Retro    | [Cadence] | 60 min   | Reflect and improve                |
| 1:1s     | Weekly    | 30 min   | Individual coaching and support    |

### Meeting norms

- Meetings start on time. If you're running late, message the channel.
- Every meeting has an agenda shared in advance.
- We record meetings and share notes for async team members.
- Camera on is encouraged but not required.
- We respect meeting-free focus blocks: [e.g., Tuesdays 9am–12pm].

---

## Code and delivery

### Pull requests

- PRs should be small enough to review in 15–30 minutes.
- Reviewers respond within [X hours / 1 business day].
- Authors address feedback within [X hours / 1 business day].
- We use conventional comments: nitpick, suggestion, question, blocker.

### Definition of done

A story is done when:

- [ ] Code is merged to main.
- [ ] Tests pass and coverage is maintained.
- [ ] Documentation is updated if applicable.
- [ ] Feature flag is configured (if applicable).
- [ ] It's been verified in staging.

---

## Decision-making

- **Day-to-day technical decisions:** Individual engineers, consulting team as needed.
- **Significant technical decisions:** Proposal + ADR, reviewed by team.
- **Team process decisions:** Discussed in retros, decided by consensus.
- **Urgent decisions:** Tech lead / manager can decide unilaterally, with follow-up explanation.

When we disagree, we aim for consensus. If we can't reach it, [decision-maker] makes the call and we commit.

---

## Focus and availability

- **Core hours:** [e.g., 10am–3pm in each person's local time zone] — When we expect overlap and availability for sync communication.
- **Focus blocks:** [e.g., No meetings Tuesday mornings] — Protected time for deep work.
- **Time off:** Notify the team at least [X days] in advance. Update calendar. No expectation of response during PTO.

---

## Conflict and disagreement

- We assume good intent.
- We address issues directly with the person involved before escalating.
- We focus on behaviors and impact, not character.
- If we can't resolve something ourselves, we involve [Tech Lead / Manager] as a mediator.

---

## How we update this agreement

- We review this agreement in our quarterly retro.
- Anyone can propose changes at any time by raising in [channel/meeting].
- Changes require team consensus.

---

## Signatures

By working on this team, we commit to this agreement.

[Team member names or acknowledgment process]

Team Ops: Working Agreements — Full playbook on creating and maintaining agreements.
Team Ops: Async Communication — Communication norms for distributed teams.
Team Ops: Meeting Standards — How to run effective meetings.
Team Ops: Conflict Resolution — Handling disagreements constructively.