Team Charters and Working Agreements

Scenario

Example team: the checkout team has six engineers across two time zones. Some expect replies in minutes; others batch messages twice a day. Some merge after one approval; others wait for two. Two engineers had a heated exchange about "people not pulling their weight" on support duty.

What you see on the team

• Recurring friction about response times, reviews and meeting attendance.
• New joiners learning the rules by breaking them.
• Unclear ownership: "I thought you were handling that".
• Conflicts that look personal but are really about unspoken expectations.

The common mistake

Assuming that shared expectations exist because everyone is a professional, and only discussing them after a conflict.

Why it happens

Every engineer brings habits from previous teams. Without explicit agreements, each person follows their own defaults, and differences show up as friction. Atlassian's public Roles and Responsibilities play exists for this reason: making roles and expectations explicit removes a whole class of conflict.

The playbook

1. Team charter (once, revisit every six months) — one page:

Checkout team charter
Mission: customers can pay quickly and safely on every device.
We own: checkout UI, payment orchestration API, payment provider integrations.
We don't own: pricing (pricing team), fraud rules (risk team).
Success measures: checkout conversion, payment success rate (SLO 99.9%), p95 latency.
Stakeholders: payments product manager, finance, customer support.

2. Working agreements (90-minute workshop, revisit quarterly) — cover:

• Communication: response-time expectations per channel; core overlap hours across time zones.
• Code: review response time, approvals, definition of done.
• Meetings: which ones, who attends, cameras, agendas.
• Support and on-call: rotation, handover, what "on support" means.
• Decisions: who decides what; how disagreements are resolved.

3. Let the team write them. The lead facilitates; agreements imposed from above are followed loosely.

4. Refer to them. When friction appears, point to the agreement ("our agreement says reviews within four hours") or improve it — don't make it personal.

What to say

Opening the workshop:

"We've had some friction about reviews, response times and support. I don't think that's about anyone being lazy — I think we never agreed the rules. Let's write them down together, and review them in three months."

When an agreement is broken:

"Our agreement says support handover happens by 10:00. Today it didn't — what got in the way? Do we need to change the agreement or how we follow it?"

Trade-offs

• Too many rules feel bureaucratic; keep agreements to one page.
• Agreements age; schedule a review or they become fiction.
• Exceptions for seniors undermine everything; agreements apply to everyone, including the lead.

Signals it's working

• Fewer conflicts about "how we work"; disagreements reference the agreement.
• New joiners read the charter and agreements in their first week.
• People propose changes to the agreements instead of quietly ignoring them.
• Ownership questions get answered by pointing at the charter.

Key points

• A one-page charter states mission, ownership, non-ownership, success measures and stakeholders.
• Working agreements cover communication, code, meetings, support and decisions.
• The team writes them; the lead facilitates; review regularly.
• Use agreements to depersonalise friction — and apply them to everyone.