
A message lands in the team chat: “Can you look at this?” One colleague hears a request for an immediate reply. Another adds it to tomorrow’s list. Both believe they are being reasonable.
Team working agreements give people a shared reference for these everyday situations. They make communication expectations visible: where requests belong, how quickly someone should acknowledge them, and what happens when something genuinely cannot wait.
For managers and People teams, the useful starting point is a conversation about how work actually happens. A short agreement should help colleagues make fewer guesses while leaving room for different schedules and needs.
What are team working agreements?
Team working agreements are shared, written expectations about how colleagues work together. Atlassian’s Working Agreements Play describes them as norms for communication and collaboration, including across locations and time zones.
For communication, an agreement might cover a handful of recurring questions: Which channel should I use? When should I expect an answer? Can I mute notifications while concentrating? How do I reach someone during an incident?
Use clear, observable language. “Communicate respectfully” leaves plenty to interpret. “Include the question, relevant link, and requested reply date in one message” gives someone a behavior they can follow.
Start with the moments that cause confusion
Before drafting rules, ask colleagues to describe recent communication friction without naming or blaming anyone. Perhaps the same request appeared in three places. A person on leave received repeated follow-ups. A deadline described as “today” meant different things to different people.
Invite written contributions before discussing them together. Ask people what makes a proposed norm difficult for their role, schedule, or access needs. Nobody should have to explain private circumstances to justify a workable communication arrangement.
Choose a few recurring situations for the first version. Managers should contribute their own needs and make space for colleagues to question assumptions, including assumptions about availability.
Agree on six communication essentials
1. Give each channel a clear purpose
Write down the preferred home for each common message type. For example:
- Team channel: questions or updates relevant to several colleagues
- Task or project record: detailed requests, files, and the conversation needed to complete that work
- Direct message: sensitive matters or a genuinely individual question
- Incident route: urgent operational issues covered by the organization’s response process
Check that the intended audience can access the chosen location. Follow company rules for confidential information.
When a conversation moves, leave a link pointing to its new home. The 37signals communication guide offers a practical example of keeping task and document discussions attached to the relevant work. Your team can use the same principle with its existing tools.
2. Define what a response window means
Separate acknowledging a request from completing it. “I’ve seen this and can review it on Thursday” gives the sender useful information even when the work needs longer.
Choose windows that reflect service commitments, staffing, and actual schedules. A team might trial acknowledging routine internal requests by the end of the recipient’s next scheduled workday. That is an example to test, not a universal benchmark.
Specify whether weekends, leave, and nonworking days count. Explain what the sender should do if the window passes. For requests needing substantial work, agree a completion date separately.
Treat an online indicator as a technical status. It does not establish that someone is available to respond.
3. Make urgency specific
Agree on examples of issues that require the urgent route, such as a live service failure covered by an existing incident process. A routine request approaching its deadline may need a conversation about timing without becoming an incident.
An urgent message should explain the impact, the action needed, and the time constraint. Name the monitored contact route, coverage hours, and backup if nobody acknowledges it. A label alone cannot provide coverage.
For teams with formal on-call arrangements, link to those arrangements. Team working agreements should fit established safety, security, and customer-response procedures.
4. Make focus time practical
Describe how colleagues signal a focus block and when they will next check routine messages. Confirm whether notifications may be paused during that period and which established urgent route remains available.
A customer-facing team may need staggered focus blocks so its shared queue stays covered. A project team may have more flexibility. Test the arrangement against the work people must do.
Managers should follow the agreement too. Chasing a routine request during a colleague’s published focus block sends a different message from the written norm.
5. Include every working schedule
Publish useful availability information: usual working hours, time zone, and planned absence. Share only what others need to coordinate.
Replace “end of day” with a date, time, and time zone when a precise deadline matters. GitLab’s communication handbook explicitly recommends this and states that its team members are not expected to respond outside planned working hours.
Before requesting input, check that each contributor has a reasonable opportunity to respond during their schedule. If a discussion continues while someone is offline, leave enough written context for them to contribute when they return.
6. Write down exceptions and review dates
Allow temporary changes for launches, absences, or unusual coverage needs. Record what changes, whom it affects, and when the exception ends. Avoid quietly turning a one-off favor into a permanent availability expectation.
Set a review date before starting. Atlassian’s play recommends revisiting agreements when team membership or working conditions change, as well as reviewing them regularly.
At the review, ask which requests got stuck, which rules were hard to follow, and whether anyone felt pressure to stay online longer. Change the wording or coverage arrangement where needed. Keep the current version easy to find.
A hypothetical team working agreement in practice
Consider a fictional implementation team spread across several time zones. Its members keep chasing routine questions because they do not know whether a message has been received.
They trial this agreement for two weeks:
- Put routine delivery questions in the project record and link to it from the team channel when attention is needed.
- Acknowledge direct requests by the end of the recipient’s next scheduled workday. Agree completion timing in the reply.
- During leave, use the coverage contact listed in the project record.
- Follow the existing incident process for live customer outages. General chat is not continuously monitored.
- Mark focus blocks in the calendar. Routine follow-ups wait until the agreed response window has passed.
At the review, the team checks a few real requests together and asks whether the acknowledgment window was realistic. The example illustrates a starting agreement; it makes no prediction about results.
Prompts to build your own agreement
Complete these sentences together:
- “For a routine request, use ___ and include ___.”
- “We acknowledge it within ___, measured during ___.”
- “If there is no reply, the next step is ___.”
- “Urgent means ___; the monitored route is ___.”
- “During focus time or absence, colleagues can expect ___.”
- “We record temporary exceptions in ___ and review this agreement on ___.”
Pin the finished version where requests arrive. Give new colleagues a chance to question it and suggest changes.
Frequently asked questions
How long should a team working agreement be?
Aim for something colleagues can consult quickly. Start with the communication situations causing the most confusion. Link to detailed policies rather than copying them into the agreement.
Who should create the agreement?
The people expected to use it should help shape it. A manager or facilitator can prepare a draft, then invite challenges and revisions before agreeing to a trial.
What if someone cannot follow an agreement?
Ask what got in the way. The wording, tools, coverage, or expectations may need adjustment. Clarify the next step together and revisit repeated difficulties without turning reply speed into a substitute for assessing the work.