How should a team keep its working agreements useful as the team changes?
Quick answer
Review working agreements at a predictable interval and when a meaningful team change makes one seem outdated. Invite specific proposals, discuss their practical effect, and use a decision method the team has agreed on. Record the approved wording, date, and any trial period in one shared version, then tell the team what changed. Keep the review short and revisit trial changes before making them permanent.
The question, the details, the next step.
We wrote down team agreements when we were smaller, but the team and its work have changed. How do we stop the document becoming something nobody looks at?
Give the agreements a regular, brief review rather than waiting for someone to remember them during a disagreement. A quarterly check-in can work as a starting point; choose an interval that fits how quickly your team changes. Also reopen an agreement when a concrete change—such as a new team member, a different handoff, or a recurring meeting problem—makes it hard to follow.
Treat the document as a description of current choices, not a list of ideals. For each line, ask: Do we still use this? Is it clear enough to act on? Does it fit how the work happens now? Keep useful agreements, edit unclear ones, and remove those the team no longer wants. Put the next review date where people can find it.
What should happen between noticing a problem and changing the written agreement? I want suggestions to be easy to raise without turning every small annoyance into a meeting.
Use a small proposal process. Ask the person suggesting a change to name the current wording, give a specific example of where it did not help, and offer a replacement or a question for the team to discuss. Keep a shared change log or discussion thread so the suggestion is visible, but do not treat a proposal as approved just because it was added.
Batch non-urgent proposals for the next review. Bring forward sooner only those that are blocking work or repeatedly causing confusion, and agree as a team how to handle that exception. During discussion, focus on the effect of the wording: what behavior would it guide, and could people reasonably interpret it differently? That keeps the conversation about a workable agreement rather than about who is at fault.
How do we decide whether to adopt a change? We don't want an endless discussion, but I also don't want one person silently rewriting rules for everyone.
Agree on the decision method before a proposal is on the table. For example, the team might seek explicit consent, use a named owner to decide after hearing concerns, or vote. The right choice depends on your team; the important part is to state who decides, how concerns are handled, and what happens if no decision is reached. Do not assume that silence means agreement unless the team has explicitly chosen that rule.
If people are uncertain about a proposed change, try it for a defined period instead of debating it indefinitely. Record that it is a trial, the date to review it, and what the team will look for—for instance, whether handoffs become clearer. A trial is not proof that the change will work; it is a time-bounded way for the team to assess it.
Can you show what a useful update record looks like, including how to avoid people following an old copy?
Keep one clearly identified current version and put the update record beside it or link to it from the document. After a decision, have a named person update the wording, mark the effective date, and share a short change note in the place the team normally uses for coordination. Archive or label superseded copies so they are not mistaken for the current version.
For example, a change note might say:
“Proposed: Replace ‘send updates promptly’ with ‘post a status note in the project channel by the agreed check-in time.’ Reason: The old wording left handoff timing unclear. Decision: Adopted by [team’s agreed decision method]. Effective: [date]. Owner: [role or name]. Review: [date].”
This is a placeholder example, not a rule your team needs to adopt. Make the wording fit your work, and include only details the team has agreed to share. At the review, check whether the agreement is still useful; update or retire it if the team decides it is not.
A practical checklist
Set a recurring review date and name the situations that can trigger an earlier review.
For each agreement, decide whether to keep, clarify, revise, trial, or retire it.
Ask each proposer for the current wording, a concrete example, and a suggested change or discussion question.
State the decision method and how unresolved concerns will be handled.
Record approved wording, decision date, effective date, owner, and any trial-review date.
Maintain one clearly marked current version and tell the team where it is.
A few more useful answers
How often should we review working agreements?
Choose a regular interval that matches the pace of change in your team; a quarterly check is one possible starting point. Review sooner when a real change or recurring problem makes an agreement difficult to use.
Should every proposed change be discussed at a team meeting?
Not necessarily. Collect non-urgent proposals and discuss them together at the planned review. Agree in advance which kinds of issues merit an earlier conversation.
What if the team cannot agree on a proposed update?
Follow the decision process the team chose, rather than leaving the document in an ambiguous state. If appropriate, record the unresolved question and a time-limited trial or a date to revisit it.