Team Norms Examples: Twenty Working Rules Worth Writing Down

Team norms are the working rules a team agrees to follow: how meetings run, how fast people reply, how code gets reviewed, how decisions are made and recorded, when people can focus, how remote work happens, and what AI assistants may do. Good examples share one quality: each is specific enough that two people could agree on whether it was kept. Below are twenty examples across seven areas, each with the reason behind it, followed by how a team agrees on its own and where to record them so they are actually followed.

These are examples to choose from, not a document to fill in. For the one-page agreement that collects a team’s norms, with sections for each area, use the team working agreement template.

What makes a norm worth writing down

• It settles a question that keeps coming up. If nobody has ever argued about it, leave it out.
• It can be broken, visibly. “Be respectful” cannot. “Cameras are optional in internal meetings” can.
• It carries its reason. A norm with a why survives the person who proposed it leaving; one without gets quietly dropped.

Meetings

1. Every recurring meeting has a written agenda by the end of the previous working day, or it is canceled. Why: a meeting without an agenda turns into a status update that could have been a message. GitLab’s communication handbook↗ (opens in a new tab) sets a similar standard: “Ensure that every meeting has an agenda and is available for everyone to edit.”
2. Decisions and action items are written into the meeting notes before the meeting ends, each with one owner. Why: everyone leaves with the same list, and nobody has to reconstruct it from memory. A meeting minutes template keeps it short.
3. Anyone may decline a meeting that has no clear purpose for them, and ask for the notes instead. Why: it keeps attendee lists honest without anyone feeling rude.

Response times

1. Direct messages get a reply within four working hours, even if the reply is “I will look at this tomorrow.” Why: the sender can plan around a delay; they cannot plan around silence.
2. Anything urgent goes through one named channel or a phone call, never a regular chat thread. Why: if everything can be urgent, nothing is, and people learn to watch every channel all day.
3. Nobody is expected to reply outside their own working hours. Messages sent late wait until morning, and scheduling them is encouraged. Why: across time zones, someone is always online, and that must not become the expectation.

Code review

1. A review request gets a first response within one working day. Why: waiting is the biggest cost in review. Google’s engineering practices guide↗ (opens in a new tab) says “One business day is the maximum time it should take to respond to a code review request.”
2. Changes stay small enough to review in one sitting, or they are split. Why: reviewers skim large changes, and problems get through.
3. Comments say whether they are blocking or optional. Why: the author should not have to guess which of twelve comments must be fixed before merging.

Decisions

1. Every decision that affects more than one person is written down with who decided, when and why, including the options turned down. Why: the next person to ask “why do we do it this way?” gets an answer instead of a re-run of the argument.
2. The person who owns the work decides after asking the people affected, unless the decision is hard to reverse. Hard-to-reverse decisions go to the team lead. Why: most decisions are cheap to change and should be quick; a few are not, and deserve more care. The decision-making framework post covers methods for each.
3. A decision is reopened only with new information, raised with the person who made it. Why: it stops decisions being relitigated whenever someone who missed the discussion disagrees.

Focus time

1. Two afternoons a week have no internal meetings. Why: work that needs a few hours of concentration does not happen in the gaps between calls.
2. A status marked “focusing” means messages can wait until it ends, unless something is urgent under the norm above. Why: it lets people turn off notifications without feeling they are hiding.

Remote work

1. Default to written, asynchronous updates; meet live only for discussion that writing cannot settle. Why: written updates reach people in every time zone and leave a record.
2. Core hours, when everyone is reachable, are 11 a.m. to 3 p.m. Eastern. Outside them, people set their own schedule. Why: it gives everyone overlap for live questions without dictating the rest of the day.
3. Work in progress lives on the team board, not in private notes or direct messages. Why: in a remote team, the board is the only place everyone can see what is happening.

AI assistant use

1. AI assistants may research, draft, file tasks and write plans on their own; a person approves anything a customer will see, any deploy and any spending. Why: it puts the line where mistakes become expensive. The MCP specification↗ (opens in a new tab) says “there SHOULD always be a human in the loop with the ability to deny tool invocations.”
2. Every AI assistant is connected under the name of the person responsible for it, and its changes are recorded under that name. Why: when something goes wrong, the team knows whom to ask.
3. The most important limits are enforced by settings as well as written down. Why: an instruction is a request. In Claude Code, for example, permission rules↗ (opens in a new tab) are “evaluated in order: deny, then ask, then allow,” so a deny rule holds whatever a prompt says.

The fuller policy behind that last area, covering which assistants may be connected, to which data, and who owns each one, is set out in AI agent governance for small teams.

How a team agrees on norms

Norms imposed by a manager are rules; norms a team agrees to are the ones it keeps. An hour is enough for a first set:

1. Collect the friction. Before the meeting, ask everyone for two or three moments in the last month when working together was harder than it needed to be.
2. Group them by area and pick the five that come up most. Those are the norms worth writing first.
3. Draft one norm per problem, specific enough to be broken, with its reason.
4. Check each for agreement. Anyone who cannot live with a norm says so now, and the team changes it or drops it.
5. Name an owner for the list and a date to review it.

Start with fewer norms than you think you need. Five norms people keep beat twenty nobody remembers. Add more when the same friction comes up again.

Recording norms as rules every assistant reads

People read the norms once and absorb them. An AI assistant starts each session knowing nothing, so it only follows the norms it is given every time it starts. On fenbs, norms that are decisions go on the Decisions and rules page. A rule is a decision that holds from now on, recorded with who decided it, when and why. Rules are shown in full at the top of every connected AI assistant’s AI context, before anything else, so every assistant on the board reads them first, whichever tool it runs in.

• The decider is always a person. An assistant can write a rule down for the person it works for, quoting their words, but it never decides one.
• Rules can apply to everything or to one project. A rule for one project is only given to an assistant working on that project.
• To change a norm, record a new decision that replaces the old one. The old one is kept and marked Superseded, so the history of how the team works stays on the page.
• A norm the team has not settled can sit on the page as an open decision. When a norm needs formal agreement, named board members can be asked to sign it off, and each answers Approve or Reject.

Not every norm belongs there. fenbs does not track hours, meetings or response times, so norms about those stay in your team’s agreement document. The norms that belong on the Decisions and rules page are the ones about how work is done and what assistants may do: “a person approves every deploy,” “every bug gets a repro before it is fixed,” “assistants never change tests to make them pass.”

Reviewing team norms

• Review the list every quarter, and whenever someone joins or the team changes shape.
• Look for norms people quietly stopped keeping. Either the norm was wrong and should change, or it was right and slipped, and the team should say so.
• Retire norms that no longer settle anything. A shorter list gets read.
• Ask new joiners after their first month which norms surprised them. They see the gap between the written list and the real one more clearly than anyone.