Team norms examples: 30 ideas and a working agreement

Team norms are the shared expectations that shape how people work together. They include how colleagues ask for help, share information, make decisions, handle disagreement, and follow through. Some norms are explicit agreements; others develop through repeated behavior without anyone discussing them.

Useful norms describe something the team can do and recognize. “Be respectful” leaves room for different interpretations. “Let the speaker finish, then summarize their point before disagreeing” gives colleagues a behavior they can practice and review.

Use the 30 team norms examples below as starting points. Choose a few that address real problems, adapt them together, and test them before adding more. This article provides examples and a copyable agreement. The team norms worksheet gives you a separate working document.

Explicit and implicit team norms

An explicit norm is discussed and stated: “We record decisions in the project log.” An implicit norm is an expectation people learn by watching: “The important decisions happen after the meeting, so stay online.” An implicit norm can differ from the agreement written on the wall.

Ask what happens in practice. If the team says questions are welcome but routinely moves on before people can ask them, the experienced norm may be to stay quiet. Describe the pattern with concrete examples and invite different perspectives before choosing a change.

Team norms, values, and policies serve different purposes

A value names something you care about, such as openness. A norm turns that intention into a working behavior, such as recording a decision and its rationale where affected colleagues can find it. An organizational policy sets a formal requirement; a team agreement must work within applicable policies and responsibilities.

A working agreement is a short record of the norms the team chooses to try. It does not guarantee that everyone will experience them the same way. Make room to discuss exceptions, access needs, different working hours, and responsibilities outside the team.

30 team norms examples you can adapt

These are proposed agreements, not universal rules. Set response windows, channels, and review dates together. A useful norm should fit the work and be practical for the people expected to follow it.

Communication norms

1. Put a request's purpose, requested response, owner, and deadline in the shared task or message.
2. Use our agreed urgent channel for a genuine time-critical issue; explain the deadline rather than marking every message urgent.
3. Agree a response window during each person's working hours, and say when a fuller answer needs more time.
4. Share essential context in a place the affected team can access, rather than leaving it only in a private conversation.
5. Ask what a colleague meant before assuming their intent from a short message.

Meeting norms

1. State whether a meeting is for a decision, discussion, or update before inviting people.
2. Share the question and essential material early enough for the invited people to prepare; agree what that means for this team.
3. Give people a way to contribute in writing before asking for live responses.
4. End a decision meeting by naming the decision, owner, next step, and any unresolved question.
5. Cancel or shorten a recurring meeting when its purpose can be met another way.

Decision-making norms

1. Name the decision owner and the people to consult before work on a decision begins.
2. Agree which evidence and constraints matter before comparing options.
3. Invite a concern or alternative before closing a consequential team decision.
4. Record the decision and rationale where affected colleagues can find them.
5. Reopen a decision when agreed review conditions or new evidence warrant it, and explain what changed.

Accountability and handoff norms

1. Name one accountable owner for each committed next step, while making contributors visible.
2. Confirm what finished work should include before accepting a handoff.
3. Flag a blocked task or likely missed deadline early, with the support or decision needed.
4. Check capacity before agreeing a new commitment; make the trade-off visible if priorities change.
5. Review a missed commitment by discussing what happened and how the process can improve, rather than assigning a personality explanation.

Feedback and disagreement norms

1. Describe an observed behavior and its effect before suggesting a change.
2. Check that you understood a concern before responding to it.
3. Discuss disagreements about the work without making claims about a colleague's motives or character.
4. Offer a private conversation when feedback is personal, and use the organization's appropriate process for serious concerns.
5. Agree when an unresolved work disagreement needs help from the decision owner or another appropriate person.

Availability and sustainable-work norms

1. Make working hours and planned availability visible without requiring personal explanations.
2. Do not assume an out-of-hours message needs an out-of-hours response unless an agreed on-call responsibility applies.
3. Share notes and asynchronous ways to contribute when time zones prevent everyone attending.
4. Agree how the team covers planned absences and how responsibilities are handed over.
5. Review an agreement that repeatedly requires people to work beyond their available capacity.

Choose a small set of norms around real work

Start with a recent coordination problem. Ask each person to describe what happened, its effect, and what would have helped. Collect written observations before discussing them so the first speaker does not define the whole problem.

Group related observations and choose three to five agreements for an initial trial. That is a suggested starting size, not a rule about the right number for every team. Prioritize an agreement that is within the team's control and would address a recurring difficulty.

For each proposal, ask: “Could we tell whether we tried this?”, “Can everyone reasonably follow it?”, and “What exception or support is missing?” Confirm who has authority over the affected decision or process. A team should not promise a change that depends on another group without involving them.

Turn a vague intention into a working agreement

Consider a fictional team whose project decisions keep being revisited. Its initial norm, “Communicate decisions clearly,” leaves several questions unanswered: who records the decision, where, how quickly, and when it can be reopened.

A more usable agreement is: “The decision owner records the choice, rationale, consulted people, and next step in our project log by the end of their next working day. A teammate who identifies new evidence links it in that log and asks the owner whether a review is needed.”

The deadline is an example to negotiate, not a universal standard. The team might need a different window for urgent operational decisions. The useful change is making the behavior, owner, location, and exception explicit.

Use the step-by-step team norms playbook for a facilitated session. The examples here can be adapted with or without an assessment.

Copy this team working agreement

Copy the outline below into the document your team already uses. Replace the prompts together and keep the first version short enough to use in a real conversation.

• Team and purpose: Which group is making this agreement, and what recurring problem do we want to address?
• Our agreements: What three to five behaviors will we try? For each, name the situation, action, responsible person or role, and shared location where relevant.
• Timing and availability: What response or preparation windows are realistic during our working hours?
• Exceptions and support: When does the agreement need a different approach, and how do we ask for it?
• When an agreement is missed: How will we raise the issue and understand what happened?
• Trial and review: When will we start, who will organize the review, and what examples will we examine?
• Review decision: Which agreements will we keep, change, or stop?

A filled example for project handoffs

• Purpose: Reduce clarification loops when a draft moves from an author to a reviewer.
• Agreement: The author puts the document link, review question, requested deadline, and next decision owner in the shared task.
• Receiver's response: The reviewer confirms whether the timing is feasible during their working hours and flags missing context before starting.
• Exception: For urgent work, the author uses the agreed urgent channel and checks capacity directly rather than assuming availability.
• Review: After two weeks, the project lead brings three handoffs for the team to discuss. We keep the useful fields and change anything that created avoidable work.

If you want a separate editable starting point, use the team agreement template and examples.

Check whether agreed norms match the team's experience

Ask for examples of the agreement being used, missed, or adapted. A norm that works for the manager may still make it harder for another colleague to contribute. Invite written feedback and discuss the effect before treating a missed agreement as an individual failure.

TeamDynamics gives you another starting point for that discussion: reported shared behaviors across Communicating, Processing, Deciding, and Executing. In Pro, participants describe how the team works; completed responses contribute to the shared team profile. Personal preferences separately inform private CoDynamics and do not determine the team profile.

The profile describes a reported working pattern, not whether the team has complied with a policy or achieved a performance target. For example, colleagues might report a Deliberate Executing pattern while a new agreement asks them to adapt plans quickly. Discuss where the existing pattern helps, where it creates friction, and what change the work actually requires.

See a sample Team Profile, then explore the Team Discussion Guide for a concrete example of turning a pattern into an agreement. If your team is also discussing individual communication preferences, the DiSC team-building workshop guide provides a separate practice agenda.

Review and update the agreement

Try the initial agreement for a defined period, such as two weeks, and book the review when you create it. Examine a few actual examples: can people find the decision, understand the handoff, or tell when a response is needed? Ask what helped and what added unnecessary work.

Decide together which agreements to keep, change, or stop. Update the shared document and explain the change to people who were absent or have recently joined. Revisit it when responsibilities, membership, working hours, or the work itself changes.

If a norm keeps being missed, check clarity, workload, access, incentives, and conflicting expectations. Another reminder will not fix an agreement people cannot reasonably follow. Keep the agreement a tool for coordination and development rather than a personality score or an individual performance rating.