Creating Team Working Agreements

Agreements that keep your team from going into chaos

A few years back, I noticed a pattern on my team.

One engineer missed a meeting without any notice. No big deal I thought. Then another person missed a ticket on their sprint. A week later, someone forgot they were on-call. “My bad” they said.

Each time, I brushed it off as a “minor thing.” I’d make a mental note, maybe bring it up gently in a 1:1. But as these “minor things” piled up, I started asking myself:

Does my team even know what’s expected of them? Or am I just assuming they do?

That was my wake-up call. As managers, we often assume “common sense” to cover things like showing up on time and responding to messages. But what’s “common sense” to you may not be to someone else. Add a distributed team, different cultures, and new hires to the mix and suddenly, what you thought was obvious seems fuzzy at best.

That’s when an agile coach told me about Team Working Agreements.

What’s a Team Working Agreement?

Think of it as the team’s rulebook. Written by the team, for the team.

It’s a simple document where everyone agrees on how the team works together. From working hours to communication expectations to the quality standards.

The beauty of it is that once expectations are made explicit, holding each other accountable gets a lot easier. Instead of you being the “bad cop” every time, you can point back to the agreement:

“Hey, we all agreed to start standup at 9 sharp. Let’s stick to it.”

It really helped me shift the conversation from my opinion to our agreement.

Some managers or teams dismiss this as “bureaucracy.” And I know there are teams who operate without any explicit agreements. Maybe everyone on that team is a natural fit with perfectly aligned values and working styles.

But the rest of us need something like this to set some expectations and progress towards those shared values.

A good working agreement creates:

• Clarity - Everyone knows what’s expected. Fewer gray areas.

• Fairness - Expectations apply equally to everyone, regardless of seniority. That one guy who’s always on time feels valued.

• Support - When giving feedback, you can ground it in a shared agreement, not a personal preference.

• Self-regulation - Teams often start holding themselves accountable without you needing to step in.

What to Include

A working agreement doesn’t need to be a legal contract. In fact, if it’s too long, people won’t use it. Keep it practical, cover what matters most, and evolve it as your team grows.

Some topics that healthy teams include

• Working Hours
  What hours you can expect team members to be available. If you’re a hybrid team, you can decide what days you will be in the office. For distributed teams, agree on core overlap hours where everyone is available for meetings or quick syncs. Example: “We all overlap at least 3 hours daily (8–11am PST).”

• Communication Expectations
  Decide where and how communication happens. What is ok to be async and what must be sync. Example: “Urgent issues go on Slack with @here. Non-urgent items in Jira. Docs live in Confluence.”

• How we manage work

  Include how you plan work, what systems you use and how. Example: “We follow Scrum and we do 2 week sprint cycles. All tickets must be in Jira and include the definition of done. When closing ticket, attach Pull Request or document link.”

• Meetings & Ceremonies
  Which meetings are important for your team. What days and time work for everyone. Define some norms. Example: “Standup starts on time whether everyone’s there or not. Retro meetings are high priority. Recommend cameras on for sprint demos.”

• Unavailability

  How should team members communicate about planned leaves? Maybe just applying for a leave in Workday isn’t enough. Example: “Set Out of Office in the calendar and in Slack. Bring it up during sprint planning. When unexpected leaves come up, share status in the channel and recommend actions for any ongoing work.”

• Roles & Responsibilities
  If you rotate roles (scrum lead, note-taker, release manager), make it explicit who does what, and when it rotates.

  For on-call responsibilities we have a completely separate doc, but you can define some high-level agreements here.

• Coding standards

  Include what general standards the team should adhere to when shipping code. What is the expectation of peers when new code is written? Some of the standards can be automated via PR gates (e.g. code coverage, static code analysis, etc.) so focus on what can’t be. Example: “We follow PEP 8 coding style. New PR reviews must start within 12 hours.”

---

Pro Tip: If you never had a Team Working Agreement and all this is overwhelming, start where your team currently struggles. If people keep missing deadlines, make agreements around that. If there’s blame culture, create agreements about how you’ll handle mistakes.

Starting small and iterating over it is more practical than coming up with a thousand rules. Collaborate with the team. Revisit it regularly in retros, especially when something feels off. Share with new team members and seek feedback. If it no longer reflects reality, change it.

---

The Bottom Line

If you’ve ever been frustrated by small stuff repeatedly going wrong. Like late meetings, miscommunications, forgotten responsibilities, then the problem might not be the people. The problem might be the lack of clarity.

A Team Working Agreement gives your team that clarity. It makes the invisible visible, and turns unspoken assumptions into explicit commitments.

It’s one of the simplest tools you can add to your manager toolkit, yet one of the most powerful.

---