Writing a Team Operating Agreement (And Making It Stick)

A software team at a mid-size SaaS company had a 3-page operating agreement. It covered response time expectations (replies within 2 hours), meeting norms (cameras on, no phones), and how to escalate blockers. It was well-written. The team lead had put real thought into it. And every morning at 9am, eight people attended a standup that violated four of its clauses: cameras off, no agenda, status updates that should have been async, running 40 minutes over the stated 15.

Nobody mentioned the operating agreement. When the team lead finally asked why, the answer was: "We didn't write it. We just got it in a Slack message."

That's how operating agreements fail. Not because the content is wrong. Because the process of creating them skips the people who are supposed to follow them.

Why most operating agreements don't work

A manager-authored document sent as policy is a compliance object. People read it once, maybe, and then behave according to their prior habits and the visible behavior of people around them, including the manager. If the manager's behavior matches the document, the norms gradually take hold. If the manager's behavior contradicts the document, the document is irrelevant.

The agreements that actually change team behavior share three properties. They were written by the team in a structured session, not drafted by the manager alone. They cover the specific frictions that actually affect this team, not generic best practices. And they get revisited when something changes: a new hire, a new project structure, a norm that's been consistently violated. When you're onboarding someone new into an existing operating agreement, the manager onboarding checklist has a useful section on surfacing implicit norms early.

Step 1: Choose the 8 topics that generate friction

Don't write an operating agreement about everything. Write it about the 8 things that actually cause problems. Atlassian's team playbook on working agreements offers a useful reference for how high-performing teams narrow their focus to the norms that drive the most friction. These are usually:

Working hours and availability: When are people expected to be reachable? Is there a core overlap window for distributed teams? What does "off work" mean in practice: no Slack, DND, or no monitoring at all?

Response time expectations: How fast should someone reply to a Slack message? An email? A review request? Vague expectations here create constant low-level anxiety. Explicit norms (Slack: 4 hours during working hours; email: 1 business day) remove the guessing.

Meeting norms: What makes a meeting necessary versus avoidable? Are there required elements like an agenda or pre-read? What's the default meeting length? What are the rules for recurring meetings?

Decision authority: Who can make which kinds of decisions without asking? When does something need sign-off from the manager? From another team? Clear decision rights reduce the "should I loop in so-and-so?" paralysis that delays small decisions by days. The RACI framework documented by the Project Management Institute is one structured approach teams use to codify this before it becomes friction. The strategic cost of unclear authority is well-documented — decision-making velocity looks at how org structure affects how quickly teams can move.

How we handle disagreements: What's the process when two people have genuinely different views on a direction? Escalate immediately, try to resolve async first, call a meeting? The default behavior in the absence of a norm is usually either silent capitulation or escalation to the manager, neither of which is great.

How we give feedback: Direct feedback in real time, or written feedback in async? How specific is expected? What's the norm around tone? Teams that haven't agreed on this tend to either under-communicate negative feedback or deliver it in ways that land badly.

Onboarding expectations: What does a new person need to learn in their first two weeks? Who's responsible for showing them? What does good onboarding look like in practice?

Documentation standards: What needs to be documented, and where? Who's responsible for keeping docs current? What's the threshold for "good enough" documentation on a decision or a process?

Not every team needs all eight. Some teams have strong documentation habits and zero friction there. Some teams are co-located and availability isn't a discussion. Run the session first and let the team tell you which topics matter.

Step 2: Run the 90-minute team session

This is the most important step, and it's where most managers cut corners. Don't write the operating agreement before the session and use the session to review it. Use the session to create it.

Session agenda:

  • (10 min) Warm-up: each person writes down one team norm they wish existed, something that would make their work easier or less frustrating. No discussion yet.
  • (15 min) Share and cluster: read the norms aloud, group the similar ones on a shared board (Miro, FigJam, a physical whiteboard). You'll usually see 4-6 clusters form naturally.
  • (35 min) For each cluster, decide: What's the norm we want? Write it in plain language. "We reply to Slack messages within 4 business hours during working hours" not "timely communication is expected." Push for specific, not aspirational.
  • (20 min) Remaining topics from the friction list that haven't come up organically. Bring these yourself: "We haven't talked about feedback norms. Does anyone feel like that's a pain point?"
  • (10 min) Read back everything you've agreed on. Correct any misunderstandings. Assign one person to clean it up and share it within 48 hours.

The manager's role in this session is facilitator, not presenter. Your job is to ask questions, keep the conversation moving, and prevent any single person from dominating. Gallup's research on employee engagement and manager effectiveness found that teams where managers co-create norms rather than impose them show significantly higher long-term engagement scores. If you catch yourself presenting your own positions, stop and ask the room what they think first.

The one thing not to do: don't defend your own existing behavior in this session. If the team norms they're generating imply you've been doing something wrong, write it down and change. If you use your authority to push back on norms that are inconvenient for you personally, the session is compromised.

Step 3: Write the agreement in plain language

The person who takes notes in the session should produce a clean version within 48 hours. Format rules:

  • One page maximum. If it's longer, it's not norms. It's a policy document. Cut it.
  • Use "we" throughout: "We give feedback in writing first before raising it in a meeting," not "Team members are expected to provide written feedback."
  • Use specific language: "We reply to Slack messages within 4 business hours during working hours, Monday through Friday" rather than "We respond promptly."
  • Avoid HR language. "Timely communication" and "team members shall" belong in an employee handbook, not in a working agreement your team wrote themselves.
  • Don't use this as an opportunity to cover every possible situation. If something isn't in the agreement, handle it with judgment and add it in the next revision if it becomes recurring.

A good one-page operating agreement covers 8-10 specific norms. Someone who has never worked with your team should be able to read it and understand exactly how to behave. If it requires interpretation, rewrite it.

Step 4: The signature moment

This is often skipped, and it matters. After the document is shared, ask everyone to explicitly acknowledge it. A Slack message works: "Here's the final version of our operating agreement based on last week's session. Please reply with a thumbs-up when you've read it."

This isn't about formality. It's about making the agreement public within the team. When someone violates a norm later, the norm isn't the manager's rule. It's the team's rule, written by the team, acknowledged by everyone in it. "We agreed to this together" is a fundamentally different conversation than "the manager wrote a policy that says."

The acknowledgment also surfaces disagreements that didn't surface in the session. Sometimes someone will reply saying they're not sure about a specific norm, or they want to discuss a specific item before signing off. That's good. Better to surface it now than have silent non-compliance later.

Step 5: Build in revision triggers

An operating agreement that was written six months ago and never updated is nearly always out of date. Teams change, priorities shift, new tools appear, old norms turn out to be wrong for how the team actually works.

Build revision triggers into the agreement itself:

New team member joins: The operating agreement is part of week-one onboarding. But when someone new joins, the existing team should also review whether the norms still reflect how they want to work, now that the team composition has changed. A 15-minute check is enough. No need for a full re-run of the session.

Quarterly optional review: At the end of each quarter, spend 10 minutes reviewing the agreement in a retrospective. Ask: which norms are we following well? Which have we been violating? Is there anything missing? Only revise the norms that are actually causing problems.

Visible norm violation: When a norm is consistently being violated by multiple people, that's a signal the norm might be wrong, not that the people are bad. Before enforcing it, ask: "Is this norm still right for how we're working?" If the answer is yes, enforce it. If the answer is no, update it.

Step 6: Connect the agreement to onboarding

New hires who don't know your operating norms default to their previous team's norms. This creates friction without anyone meaning to cause it. The new person isn't doing anything wrong; they just don't know what this team does differently.

Week one: new hire reads the operating agreement as part of the standard onboarding checklist. Not as an afterthought, alongside the parking pass instructions. As a primary document for understanding how this team works.

Week two: a 15-minute conversation between the new hire and their manager or onboarding buddy specifically about the operating agreement. Not a lecture. Questions. "What questions do you have? Was anything unclear or surprising? Was anything different from how you worked at your last place?" The feedback loops in the first 90 days guide has a complementary structure for catching norm mismatches before they become habits.

This conversation usually uncovers two things: gaps in the operating agreement that the team takes for granted and didn't write down, and places where the new hire has habits that will conflict with team norms. Both are better caught in week two than month two.

Step 7: What to do when someone violates the agreement

This requires a private conversation, not a public call-out. The structure is short:

"In our operating agreement, we agreed that [specific norm]. In [specific situation], I noticed that happened differently. I wanted to check in: is there something about that norm that isn't working for you, or did something just get missed?"

This approach does three things: it references the agreement specifically (not "you need to do better"), it creates space for the norm to be revised if it's genuinely wrong, and it handles the conversation before it becomes a pattern.

Don't skip the private conversation and hope the person figures it out. And don't bring it up in a team meeting as a general reminder. That reads as passive-aggressive and makes the violator defensive without solving anything.

Common pitfalls

Writing it without the team: The only way to have an operating agreement that people follow is to have the team write it. Anything else is policy, not norms. Don't shortcut the session.

Making it too long: Every item you add beyond 10 norms reduces the chance people remember and follow the rest. If you're approaching two pages, you're writing a handbook, not an operating agreement. Cut.

Treating it as a HR document: Operating agreements are team tools. They should read like something a team wrote for themselves, not something legal reviewed. If you find yourself writing "all team members are required to," stop and ask how you'd say it to a colleague.

Never updating it after the team changes: When your team goes from 5 to 9 people, or from in-person to distributed, or through a re-org, the old norms may not fit the new reality. The agreement is supposed to reflect how the team works, not how it used to work.

What to do next

Schedule the 90-minute operating agreement session before the end of the month. Not because the current situation is broken, but because the session itself tends to surface things that are mildly off that nobody has named yet. It's better to have that conversation in a structured format than to wait until something is actively going wrong.

Send the team a heads-up 48 hours before: "We're going to spend 90 minutes writing down how we want to work together. Before we meet, think about one team norm that would make your work easier. Something specific, not general. Bring it to the session."

That pre-work prompt consistently produces better sessions than walking in cold.

Learn More