Working agreement: writing down how a team actually operates

Every team has rules about how it operates. In most teams those rules are unwritten, which means they are learned by getting them wrong — a new joiner messages somebody at nine in the evening, or waits two days for an answer they could have had by asking louder. A working agreement is the version written down, and it mostly exists so nobody has to infer the norms from other people's reactions.

What a working agreement covers

• Response expectations by channel: what gets answered within the hour, what within the day, and what can wait.
• Out of hours — whether anyone is expected to read anything, and what genuinely warrants a call.
• Meetings: which are optional, who may decline, and what has to be circulated beforehand.
• How decisions are made and by whom, including what happens when the team disagrees.
• Where things live — which channel, which document, which register — so nobody has to ask where to put something.
• Core hours, if any, and how overlap is handled across timezones.

Write the norms you already have

The temptation is to write aspirations: deep work mornings, no meetings on Wednesdays, inbox zero. Those collapse in the first busy week and take the credibility of the document with them. Start by describing what the team actually does well — then change one thing. A working agreement that accurately describes current behaviour is useful immediately, because its first job is orientation rather than reform.

The most valuable line is usually the response expectation. Most anxiety in distributed teams comes from not knowing whether silence means "busy" or "ignored", and a stated norm — a working day, not an hour — removes it for everybody at once.

Making it stick

1. Draft it with the team in one session rather than presenting it to them. A document written for people describes somebody else's team.
2. Keep it to one page. Length is why these go unread.
3. Put it where new joiners land on day one, not in a folder they find in month three.
4. Name who may change it, and let anybody propose a change.
5. Review it when the team changes shape — a new member, a new timezone, a reorganisation.
6. Delete rules nobody follows rather than restating them. An ignored rule teaches people the whole document is decorative.

What it is not

It is not a contract, not a performance standard and not a policy. It describes how this particular group works together, which means another team may reasonably do the opposite — and a company-wide version is usually so general that it says nothing. Keep it at team level, keep it short, and let it differ.

Ettex Chat is usually where the agreement is tested first, since response norms and channel conventions are the parts people meet on day one. The agreement itself belongs in a document people can open rather than in a pinned message that scrolls out of memory within a month.