Team norms and working agreements that stick

Team norms are the unwritten standards of behavior that form in any group. Working agreements are those norms made explicit: a short, negotiated set of rules a team writes down and agrees to follow. A team charter is the wider kickoff document that holds them, alongside your purpose, roles, and how you make decisions.

Here is the uncomfortable part. Your team already has norms. Someone always replies within minutes; someone else goes dark for a day. One person’s ideas get built on while another’s get talked over. Those patterns are your norms, and they formed whether you chose them or not. Working agreements are the version you pick on purpose instead of the version you inherit from whoever talks loudest.

Values, norms, working agreements, and charters: the difference

These words get thrown around as if they mean the same thing, and they don’t. Esther Derby, who co-wrote the book on agile retrospectives, draws the cleanest line between them, and it is worth getting right before you run a session.

Term	What it is
Values	What matters to the team, usually nouns like Respect or Courage. They may guide behavior, but on their own they are not actionable.
Norms	The informal, often unspoken standards that emerge from how the group actually behaves. They form whether you shape them or not.
Working agreements	Norms made deliberate. Protocols the team develops, agrees to, and writes down. The layer you can act on.
Ground rules	Expected behavior for a specific time and place, such as a retro or a planning session. Narrower than a team-level agreement.
Team charter	The broader kickoff document: purpose, goals, roles, and how you decide, with the working agreements sitting inside it.

Derby’s point, in her breakdown of the terms, is that norms are not optional: a group produces them by existing. The only choice is whether you let them congeal by accident or shape them on purpose, and shaping them on purpose is what a working agreement is.

A charter answers why we exist and how we decide, and you tend to set it once at kickoff. Working agreements answer how we behave day to day, and you revisit them constantly. Values without agreements are a poster on the wall. Norms without agreements are whatever happened to settle in during month one. The agreements are the only layer you can point at when something goes wrong. Atlassian keeps the two artifacts separate for the same reason, pairing a team charter with a lighter, more frequently revisited working agreements play.

Why working agreements are worth the hour

Google’s re:Work team studied what its strongest teams had in common in Project Aristotle. Two of the factors it surfaced are the ones working agreements speak to directly: structure and clarity, meaning people understand what is expected and how the work gets done, and psychological safety, meaning people feel able to speak up. Aristotle is correlational, so read the full re:Work guide as a description of what effective teams share, not a recipe that produces one.

Clear agreements do two things at once. They make expectations visible, so nobody has to guess whether interrupting is fine or whether a message sent at 9pm needs an answer tonight. And they give the team something to point at when a line gets crossed, which is what makes it safe to raise the problem at all. Atlassian’s Teamwork Lab reports that teams with explicit agreements run fewer and more purposeful meetings and hit fewer misunderstandings.

The safety half of that gets its own chapter in building trust and psychological safety; agreements also sit inside the bigger picture of what shapes team dynamics.

How to create team working agreements: a 10-step session

You can write a first set in a single 60-to-90-minute session. The order below is the spine; the point of every step is to end up with agreements the team owns rather than rules the facilitator imposed.

Book 60 to 90 minutes with the whole team present. Attendance is buy-in. An agreement the team did not help write is just a policy, and policies get ignored.
Set the stage. Say why you are doing this, show two or three example agreements so people know the format, and open with a light check-in question to get everyone’s voice into the room early. You can run that opener live with something like icebreaker questions.
Gather the inputs first. Ask each person to share their location, timezone, working hours, and how they like to receive feedback. As facilitator, pre-draft the channel list and an escalation path so the session refines a starting point instead of a blank page. To surface preferences fast, some teams map them on a live team spectrum: where does each person fall between “reply fast” and “protect focus time”?
Brainstorm silently, then cluster. Everyone writes proposed agreements on their own before anyone speaks, which stops the loudest voice from setting the agenda. Group the cards across the situations below: communication, meetings, decisions, remote and async work, response times, and conflict.
Rewrite every vague line into a behavior you could film. “Be respectful” is a value, not an agreement. “We don’t interrupt, and we argue with the idea rather than the person” is something you can watch happen or fail to happen.
Decide sync versus async on purpose, and name who decides. For each topic, agree whether it needs a live conversation or a written thread, and name the person who breaks a tie when consensus stalls.
Confirm commitment out loud. Use a Fist of Five or a Roman vote (thumb up or down) on each agreement. Silence is not a yes. If someone signals a two, you talk until it becomes a real agreement or you drop it.
Cap the list at five to ten. A long list is an ignored list. Thirty rules is the same as zero. Pick the few that fix your team’s real friction and add more only when a genuine problem shows up.
Post them where the work happens. Pin them in the team channel, the wiki, or the top of the board, wherever people already look. It is a living document, not a slide deck nobody reopens.
Revisit them on a cadence. This is the step teams skip. Review the agreements in a retrospective, at quarterly checkpoints, and every time someone joins or leaves. Norms die from neglect, not from disagreement.

If your team runs in sprints, Scrum.org and Swarmia both describe the same ritual in agile terms, with sprint-context examples you can borrow.

Team working agreements: 30+ examples to copy

Here is a bank of concrete agreements grouped by the situation each one covers. Do not adopt all of them; that would break rule eight. Read it as a menu: take the five or ten that match your team’s friction, and change the specifics to fit your context.

Communication

“We debate ideas in the open channel, not in DMs, so the whole team sees the reasoning.”
“We assume positive intent and ask one clarifying question before reacting to a message.”
“If a thread passes ten replies, we move it to a short call and post the summary back.”
“Written status goes up by 10:00 so nobody has to chase an update.”
“Bad news travels first and fast; we would rather hear a problem early than a surprise late.”

Meetings

“No agenda in the invite means we decline the meeting.”
“We start on time and don’t recap for latecomers.”
“Every meeting names the decision it needs to make, or it becomes a written update.”
“The organizer posts notes and actions the same day.”
“Wednesday afternoons are meeting-free for focus work.”
“Anyone can say ‘let’s take this offline’ without it being rude.”

Decisions

“Reversible, two-way-door decisions don’t need a meeting; post the plan and proceed.”
“If we can’t reach consensus in ten minutes, [role] decides and the rest of us disagree and commit.”
“Decisions made in a meeting get logged within 24 hours.”
“We name who the decider is at the start of any contested topic.”
“We reopen a logged decision only with new information, not a new mood.”

Remote and async work

“Core overlap hours are 10:00 to 13:00 [timezone]; we schedule live calls only then.”
“Everyone keeps their working hours and timezone visible on their calendar and status.”
“Async is the default; we book a call only when a written thread has stalled.”
“We write updates so they still make sense to someone reading them eight hours later.”
“Calls that some people can’t attend get recorded, so no timezone is penalized.”

Response times

“Chat gets a reply within four working hours; email within one working day.”
“Nothing is expected outside your posted working hours.”
“Anything urgent goes through a call or the on-call path, not a chat message.”
“Pull requests get a first review within one working day.”
“If you can’t answer fully, you acknowledge the message and say when you will.”

Conflict and feedback

“We disagree with the idea, never the person, and never in DMs.”
“Feedback is specific and about behavior, not about character.”
“We raise a concern with the person directly before escalating it.”
“Saying ‘I don’t agree’ in a meeting is welcome; silence is not agreement.”
“When something festers for more than a week, we escalate to [role] instead of stewing on it.”

Vague agreements are useless

There is one test for whether something belongs on the list. If a stranger watching your team could not tell whether you were following the agreement, it isn’t an agreement; it is a wish. These are the usual suspects, and what each becomes when you make it observable.

Vague (a wish)	Concrete (you could film it)
Be respectful	We don’t interrupt, and we argue with the idea, not the person
Communicate well	Written status by 10:00; chat answered within four working hours
Be transparent and honest	Decisions get logged within 24 hours
Support each other	Pull requests get a first review within one working day
Have fun	Delete it; it is a hope, not an agreement

Keeping agreements alive: the wall-art problem

Most working agreements die the same way. The team runs a good session, writes a thoughtful list, pins it somewhere, and never looks at it again. Six months later it is wall art: a brilliant set of ground rules nobody references when they are broken. That is the single most common failure on this topic.

Two things keep agreements alive. The first is teeth: when someone crosses an agreement, somebody points at it, calmly, in the moment. An agreement no one enforces teaches the team that none of them count. The second is revisiting on a schedule. Fold a quick review into your retrospectives, revisit the whole set when the team changes shape, and use a recurring team health check to surface the norm that is quietly slipping before it turns into a fight.

This is a follow-through problem at heart, and follow-through is trackable. When an agreements review becomes an action with an owner and a due date rather than a good intention, it gets done. TeamRetro’s own data across a sample of hundreds of thousands of retrospective action items found that about 73% get completed, evidence that commitments a team writes down and returns to do get honored. The agreements that stick are the ones wired into a ritual the team already repeats.

If you have read the defrosting a cold team chapter, this is the refreeze step: icebreakers thaw a group, and agreements lock the new warmth into a habit. Because agreements are a social contract the team writes for itself, they hold better than rules handed down, a framing we develop in creating social contracts with team agreements. Remote and distributed teams lean even harder on the written agreement, since the ambient office cues that carry norms are gone; the remote and distributed dynamics chapter goes deeper, and GitLab’s async handbook is the reference implementation.

Run your working-agreements session in TeamRetro

A working-agreements session maps almost exactly onto how a retrospective board works, which is why teams often run it in TeamRetro. Everyone adds proposed agreements as cards at the same time, silently, so the quieter people and the person in the awkward timezone get the same airtime as whoever usually fills the silence. You group the similar cards, vote to surface the ten that matter most, and turn the survivors into a shared document the team owns. Because it sits next to your retrospectives and health checks, the revisit step stops being a calendar reminder you ignore and becomes part of a ritual you already run.

If you are formalizing this at kickoff rather than mid-flight, the working agreements belong inside a wider team charter: purpose, goals, roles, and decision rights, with these behaviors as the how. If your team runs agile, the scrum master’s retrospective guide covers where agreements get revisited from sprint to sprint.

Frequently asked questions

What is the difference between team norms and working agreements?

Team norms are the informal, often unspoken standards that form from how a group behaves. Working agreements are those norms made deliberate: a set the team discusses, writes down, and agrees to follow. Every team has norms; not every team has working agreements. Agreements are the version you chose on purpose.

What are some examples of team working agreements?

Good agreements are concrete and observable, such as “no agenda in the invite means we decline the meeting,” “chat replies within four working hours,” “decisions get logged within 24 hours,” and “we disagree with the idea, not the person.” If a stranger couldn’t tell from watching whether you followed it, it isn’t an agreement.

How many working agreements should a team have?

Start with five to ten. A long list is an ignored list. Pick the few agreements that fix your team’s real friction, such as meetings, response times, and how decisions get made, and add more only when a genuine problem appears. You can revisit and adjust the list later.

What is the difference between a team charter and working agreements?

A team charter is the broader kickoff document: why the team exists, its goals, roles, and how it makes decisions, usually set once at the start. Working agreements are the day-to-day behavior rules inside it, and they get revisited far more often. The charter is why and who; the agreements are how.

How do you make team norms stick?

Co-write them with the whole team so they aren’t imposed, keep the list short, and post them where the work happens. The step teams skip is revisiting them, in retrospectives, at quarterly checkpoints, and whenever someone joins. An agreement nobody references when it is broken is just wall art.