Skip to content

Working Agreements

A working agreement is a set of explicit norms that the team creates, owns, and commits to following.

These aren't rules imposed from above. They're agreements that the team makes with itself about how they want to work together. They make implicit expectations explicit, reducing friction and misunderstanding. They create the foundation for accountability—you can hold someone to a standard only if that standard exists and everyone knows it.

Working agreements are especially important for remote and distributed teams, where you can't rely on observation and osmosis to teach norms.

What problem this solves

Without explicit working agreements:

  • Expectations are implicit, which leads to conflict when they differ.
  • New team members have to guess how things work.
  • Accountability is arbitrary—"I didn't know that was expected."
  • Small frictions compound into resentment.
  • Remote team members are at a disadvantage; they can't observe norms.

Working agreements make the invisible visible.

When to use this

Create working agreements when:

  • A new team forms and needs to establish norms.
  • You're onboarding new team members and want to accelerate integration.
  • Conflict or friction suggests unstated expectations are misaligned.
  • The team transitions to remote or hybrid work.
  • You merge teams or reorganize significantly.

Review working agreements when:

  • Someone joins or leaves the team.
  • Retros surface repeated friction about how you work.
  • Quarterly, as part of team health practices.

Roles and ownership

Role Responsibility
The team Owns the agreements. Everyone has veto power on what's included.
Engineering Manager Facilitates creation and review. Ensures agreements are documented and accessible.
New team members Review agreements during onboarding. Ask questions. Propose changes through proper channels.

Working agreements are team property, not manager property. The manager's job is to facilitate, not dictate.

What belongs in a working agreement

A working agreement should cover:

  1. Communication norms — How do we communicate? What channels for what purposes? What are response time expectations?

  2. Availability expectations — Core hours? On-call expectations? How we handle PTO?

  3. Meeting norms — What meetings do we have? What are the expectations for participation?

  4. Decision-making — How do we make decisions? Who has authority for what? How do we handle disagreements?

  5. Code and quality standards — PR expectations? Review turnaround? Definition of done?

  6. Feedback and conflict — How do we give feedback? How do we handle disagreements?

  7. Remote work specifics — Camera expectations? Async-first principles? Time zone considerations?

A working agreement should NOT include:

  • Company policies (those belong elsewhere).
  • Technical standards (those belong in engineering docs).
  • Individual performance expectations (those belong in role descriptions).

How to create working agreements

Step 1: Prepare

Decide who participates. Usually: the whole team. Schedule 90 minutes.

Gather inputs:

  • What's working well that we want to keep?
  • What friction exists that we want to address?
  • What assumptions have caused confusion?

Step 2: Facilitate the session

Opening (10 min): Explain the purpose. A working agreement is a commitment we make to each other. We all have to be able to live with every item. Anyone can veto.

Brainstorm (20 min): Each person writes down:

  • "I expect..." statements about how we work.
  • "I commit to..." statements about their own behavior.

Use sticky notes or a digital board. No discussion yet.

Cluster and discuss (30 min): Group similar items. Discuss each cluster:

  • Is this something we all agree on?
  • Is it specific enough to be actionable?
  • Is it within our control as a team?

Decide (20 min): For each proposed norm:

  • Ask: "Can everyone commit to this?"
  • If yes, include it.
  • If someone can't commit, discuss and adjust until everyone can, or drop it.

Document (10 min): Write up the final agreements. Assign an owner to finalize and share.

Step 3: Document and share

Put the working agreement somewhere accessible:

  • Team wiki or Notion page.
  • Pinned in the team's Slack channel.
  • Referenced in onboarding docs.

Step 4: Review regularly

Working agreements aren't static. Review them:

  • When new people join.
  • When friction suggests something isn't working.
  • Every quarter, as part of retrospectives.

What good looks like

A team with healthy working agreements:

  • Can articulate how they work together without hesitation.
  • New members ramp up quickly because norms are explicit.
  • Conflict is lower because expectations are clear.
  • Accountability is easier because standards exist.
  • The team updates agreements when they stop serving.

Signals that agreements are working:

  • People reference them in conversation: "We agreed that..."
  • New members say the document was useful.
  • Agreements change over time as the team learns.

Failure modes and mitigations

Failure mode What it looks like Mitigation
Too vague "Communicate well" — what does that mean? Make every agreement specific and actionable
Too rigid No room for exceptions; feels bureaucratic Include "unless discussed" clauses; treat as guidelines, not laws
Imposed by manager Team doesn't feel ownership; agreements ignored Manager facilitates, doesn't dictate; full team must agree
Never updated Agreements don't match how team actually works Review quarterly; update when someone joins/leaves
Not enforced Agreements exist but nobody references them Reference in feedback; "We agreed that..."
Too long 30-page document nobody reads Keep to 1–2 pages; focus on what matters most

Copy-pastable artifact: Working agreement template

# [Team Name] Working Agreement

**Last updated:** [Date]
**Participants:** [Names of everyone who agreed]

---

## Communication

### Channels

- **Slack [#team-channel]:** Day-to-day communication, questions, quick decisions.
- **Slack [#team-alerts]:** Urgent issues, on-call, incidents.
- **Email:** External communication, formal documentation.
- **[Video tool]:** Synchronous meetings, pairing.

### Response expectations

- **Urgent (alerts channel, @here):** Respond within [X hours] during working hours.
- **Normal (team channel):** Respond within [X hours/1 business day].
- **Async requests (tickets, docs):** Acknowledge within [X business days].

### Notification management

- Everyone is responsible for managing their own notifications.
- Don't expect instant responses outside working hours.
- If it's truly urgent after hours, [method: phone, PagerDuty, etc.].

---

## Availability

### Core hours

- We overlap [X hours] for synchronous work: [Time range, with timezone].
- Outside core hours, work async—don't expect immediate responses.

### Working hours visibility

- Keep calendars updated with working hours and focus time.
- Use Slack status to show availability (🏠 WFH, 🎧 Focus, 🏖️ PTO).

### Time off

- Notify the team [X days/weeks] in advance for planned PTO.
- Update the team calendar.
- Document handoffs for anything in progress.

---

## Meetings

### Defaults

- All meetings have agendas shared [X hours] in advance.
- Meetings start and end on time.
- Decisions are documented in meeting notes.
- Cameras are [on/optional/off for X meetings].

### Meeting-free time

- [Specify blocks: e.g., "No meetings on Wednesdays" or "No meetings before 10am"].

### Recordings

- Sync meetings are recorded for those who can't attend.
- Recordings are posted in [location] within [timeframe].

---

## Decision-making

### Authority

| Decision type        | Who decides             | Who's consulted           |
| -------------------- | ----------------------- | ------------------------- |
| Sprint priorities    | Product + EM            | Team                      |
| Technical approach   | Engineer doing the work | Team (via PR, RFC)        |
| Architecture changes | Tech Lead               | Team, architects          |
| Process changes      | Team (consensus)        | —                         |
| Hiring               | EM                      | Team (interview feedback) |

### Disagreements

- Disagree openly, but commit once decided.
- If consensus isn't reached: [escalation path, e.g., "Tech Lead decides technical, EM decides process"].
- Document decisions in [location: ADRs, meeting notes].

---

## Code and quality

### Pull requests

- PRs should be [size guideline: "reviewable in 30 min or less"].
- Aim for PR review within [X hours/1 business day].
- Use [approach: "Request specific reviewers" / "Team reviews round-robin"].

### Definition of done

Work is done when:

- [ ] Code is merged to main.
- [ ] Tests pass (unit, integration as appropriate).
- [ ] Documentation is updated.
- [ ] Stakeholders are notified (if applicable).

### Code standards

- Follow [style guide/linting rules].
- [Any team-specific conventions].

---

## Feedback and conflict

### Giving feedback

- Give feedback directly and promptly.
- Assume good intent.
- Focus on behavior and impact, not character.

### Handling disagreements

1. Try to resolve 1:1 first.
2. If stuck, bring in a third party (peer, EM).
3. Escalate to EM if unresolved.

### Retrospectives

- What's said in retro stays in retro.
- Focus on systems, not blame.
- Actions are tracked and followed up.

---

## Remote work

### Async-first

- Default to async communication.
- Sync meetings are for discussion, not information sharing.
- Write things down so remote/timezone-disadvantaged teammates can participate.

### Video calls

- [Camera expectations: "Cameras optional" / "Cameras on for team meetings" / etc.].
- Mute when not speaking.
- Use [tool] for screen sharing.

### Time zones

- Respect that teammates are in different time zones.
- Avoid scheduling outside [core hours] unless necessary.
- If you need to contact someone outside their hours, make it async.

---

## How we update this document

- Anyone can propose changes.
- Changes are discussed in [forum: retro, team meeting, async].
- All team members must agree for a change to be adopted.
- We review this document [frequency: quarterly, when someone joins].

---

## Signatures

By participating in this team, we commit to these agreements:

- [ ] [Name]
- [ ] [Name]
- [ ] [Name]

Example: Abbreviated working agreement

For teams that want something shorter:

# [Team Name] Working Agreement

**Our commitments to each other:**

1. **Respond to Slack within 4 working hours** — for urgent issues, use @here.
2. **Core hours are 14:00–17:00 UTC** — schedule sync meetings in this window.
3. **Review PRs within 1 business day** — keep them small enough to review in 30 min.
4. **Cameras optional** — no judgment either way.
5. **Write it down** — decisions, context, updates go in writing so everyone can access them.
6. **Direct feedback** — if something's bothering you, say it directly and kindly.
7. **Disagree and commit** — voice concerns, then support the decision.

**We review this every quarter.**

Last updated: [Date]