Remote Team Agreements and Protocols

You’re reading an excerpt of The Holloway Guide to Remote Work, a book by Katie Wilde, Juan Pablo Buriticá, and over 50 other contributors. It is the most comprehensive resource on building, managing, and adapting to working with distributed teams. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, 800 links and references, a library of tools for remote-friendly work, commentary and future updates, and a high-quality PDF download.

This section was written by Juan Pablo Buriticá.

For distributed teams, knowing where to share information or how and when to have discussions has become increasingly difficult thanks to the proliferation of communication and collaboration tools. To reduce the cognitive load and increase the effectiveness of how distributed teams collaborate, we suggest implementing a set of team agreements.

A team agreement (or a team contract) is a written document detailing how a team agrees to work together. Team agreements can describe procedures such as decision-making processes, how to get support, and the tools and communication methods that the team uses.

For team agreements to work, they require buy-in from everyone on the team, and as such should be written collectively, not mandated by management or leadership. Team agreements are also iterative—they are living documents that should be adjusted as the team learns how to work better together.

Ideally, team agreements codify the way the team works as specifically as possible. For example, if the team chooses to share status updates over email, then not only is this written down—clearly documenting the detail and frequency of updates—but a template for the email is also included in the agreement to make it easier for everyone to use the process.

Team agreements lead to better collaboration because they require an open discussion about how individuals want to work together. This discussion allows members to share their perspectives on good behaviors that should be encouraged, bad behaviors that shouldn’t, and personal working-style preferences that could easily become assumptions—which are breeding grounds for miscommunication and frustration if not discussed.

Creating Your Remote Team Agreement

Professors Christine M. Riordan and Kevin O’Brien underscore that social contracts emphasize a few key elements of how teams interact:

• information exchange

• reciprocity

• mutual trust and fairness

• shared values and expectations.

They write:

To turn groups of employees into great teams, a powerful first step is to form a social contract—an explicit agreement that lays out the ground rules for team members’ behaviors. A contract can cover territory such as how members will work together, make decisions, communicate, share information, and support each other. Social contracts clearly outline norms for how members will and should interact with one another.

To draft your first set of agreements, team leader(s) facilitate a series of sessions where the team gets together (most likely on a video call) to discuss different aspects of how they’ll work together. These sessions usually focus on uncovering existing team norms, both positive and negative.

Four discussion prompts that can help get a team agreement started are:

1. What expectations do team members have of each other?

2. What is working well within the team?

3. What is not working well?

4. What should the team keep doing, start doing, and just as importantly, stop doing?

Established teams can take this exercise as an opportunity to write down unspoken rules and question them in a healthy manner to evaluate if they foster collaboration or not. New teams can kick off their work by discussing how they’d like to work together, which can be a good team-building exercise.

​important​Team agreements can include positive behavior the team wants to encourage, and also outline negative behaviors. They must also explicitly establish how the team will handle violations and hold each other accountable.

Some additional questions that can help you add detail to your team agreements are:

• How often do we plan or revise our plan? Where do we document it, and who is responsible for maintaining it? Who is responsible for planning?

• What is our meeting etiquette? When is it necessary to meet? Can I leave a meeting if I don’t find it valuable? Where are notes kept? Do we record meetings?

• Where do we communicate? How should we use the different tools that we have at our disposal? How should we not use tools?

• How do we keep each other informed on status? How do we inform others? Are we “on track” by default, or do we check in daily? How do we communicate if we’re off track? What is the threshold to communicate the risk that a task or project can’t be completed in time?

• How available do we need to be on chat? How do we communicate when we’re doing focused work and shouldn’t be interrupted?

• Do we have core hours? Do we overlap? If we don’t have time overlap, how do we inform others about progress and issues, and potentially “hand off” work?

• How do we communicate vacation, sick days, or personal emergencies?

• How do we report team or company emergencies? How can we be contacted in case of emergencies? Is there someone on call?

• How do we provide feedback to each other? How should we signal to each other that we’re breaking an agreement? What do we do if someone is consistently breaching our agreements?

It’s important that your first team agreement be achievable, and refined over time as the team learns what works well and what doesn’t. This requires regularly revisiting and updating team agreements, and being sure to get feedback on them as new members are added to the team.

​caution​Agreements really can’t be mandated. All members must collectively form and share the contract, because lack of buy-in will prevent the agreement from working. It is also important that leaders model the behavior desired in the agreement, or the team will quickly realize the agreement isn’t fairly implemented and/or regarded as important.

Sample Team Agreements

• This set of collaboration guidelines from Juan Pablo Buriticá can be used as starting templates for other teams.

• Meetup’s Chief Product Officer, Giff Constable, published the team agreements from one of his past teams as a spreadsheet.

Further Reading on Team Agreements

• “Team Agreements: A Key to High-Performing, Happy Teams” (Resologics)

• “Create a Remote-Team Working Agreement” (Lucid Meetings)

Next, we examine in detail the protocols for team agreements that are particularly important for remote teams.

Time Zone Protocols

Like most factors in remote work, time zone management depends on how each company (or each department or team within it) chooses to deal with the spectrum of time zone differences, as well as the tradeoffs they want to make.

Time zone protocols are outlined in the team agreement, clarifying how people communicate when they are not in the same time zone, and hence may not have periods of overlapping availability for synchronous communication like video calls.

In general, you have two broad options here: establishing windows of “core hours” overlap during which things like video calls or stand-up meetings can occur, or designing collaboration plans that push more collaborative communication to asynchronous mechanisms and don’t rely on overlaps that are needed for regular synchronous communication.

Establishing Core Hours

Tools like the World Clock Meeting Planner help you plug in all the locations of your distributed team to see where you have overlap (areas in green across all locations).

Figure: World Clock Time Zone Overlap

Source: World Clock Meeting Planner

This sample team is spread across four cities in four different countries, and has two hours of overlap, presuming some folks can start at 8am, and others can end at 6pm. If the team sticks to a traditional 9-to-5 schedule, there’s not even a single hour of overlap. So if team members want to have a stand-up meeting, their protocol might be to have one that alternates between an 8am start time for San Francisco on some days, and a 6pm finish for London on other days.

​important​If you maintain core hours and some team members fall outside those hours, it’s imperative that your protocol be clear about the impact in terms of early or late hours for meetings, and that it ensures anyone impacted by that is OK with it. It’s also important to revisit that protocol semi-regularly, to make sure it’s not taking a toll on anyone who enthusiastically agreed to it initially, but is finding it hard to sustain.

​caution​The above team might be just one new employee away from losing any areas of standard business hours overlap. Asking people to attend meetings at early or late hours can be very challenging for people who are caretakers, which is one of the many reasons people choose remote work in the first place. At some point, you may be forced to architect your time zone management in a way that will support business growth and individual needs.

Decreasing your dependencies on time zones can allow an organization to quickly expand to different geographic regions, to be resilient in case of emergencies, and to give increased autonomy to employees so they can deal with life as it comes.

Follow the Sun

Eliminating a dependence on time zones for synchronous communication requires some significant shifts in how your team works. For some kinds of work, this shift might be a bit easier. Customer support teams with queues that people work through can easily adapt to having team members roll into the queue as others roll out. Even for more collaborative teams, like software development, marketing, or sales, examining and breaking down the work to be done can lead to practices like software developers noting the status of where they left off so that another developer can pick it up when they begin work; or a marketing team member providing edits or feedback on written materials for someone else to revise when they’re back online.

Much like other aspects of your team agreement, this will require some introspection and iteration from the team to figure out how to break down the work so it can travel around the world. Practices that we detailed earlier, like having clearly documented goals and tools for status details, are critical in this case. It may change your team’s cadence as well, as you can’t rely on synchronous meetings to get status, resolve issues or questions, or make decisions if something needs to change.

​important​If the speed of execution and/or very tight coordination between team members is critical to your business, too much time zone spread may be a risk you’re not willing to take on (at least not at the moment). In this case, you’ll have to constrain your hiring to specific regions or time zones.

Determining whether you build an organization with core hours or one that transcends time zones is ultimately your choice. Whichever way you go, it’s best to be sure to explicitly define how you think about time with your team, and then to incorporate this into your team agreement.

Further Reading on Time Zone Management

• “How to Work in Different Time Zones” (Zapier)

• “How Our Remote Team Manages Collaboration Across 9 Time Zones” (Groove)

• “Working Remotely When Everyone Else Is In a Different Time Zone” (Buffer)

• “How Does Your Team Address Different Time Zone Challenges?” (Remote.co)

• hTime. A clock to eliminate time zone calculations for remote workers.

• Every Time Zone. Another time zone tool.

Availability Protocols

It might be good to know who’s around in a true emergency, but 1% occasions like that shouldn’t drive policy 99% of the time.Jason Fried, co-founder and CEO, Basecamp*

Availability protocols are a part of a team agreement that clarify how people communicate what times they are present and available to respond in communication tools like email, chat, and calendaring apps.

If a team is skilled at working asynchronously, presence becomes secondary to getting work done. When everyone defaults to “on track” and has thorough documentation available about best practices, they shouldn’t need to interrupt anyone to get things done. But sometimes, someone on the team will be stuck without the information they need, or something may be truly urgent. In those cases, it helps to know who is available when, the best ways to contact them, and what to do in the case of emergency.

Interruptions or Support Availability

Remote teams need to be more explicit about conveying availability, because everyone can’t just look over a wall or into a room to see if someone is in deep focus mode or a meeting.

Google Calendar allows people to define working hours and set predetermined appointment blocks. For a company with time zone overlap, this allows people to check someone’s calendar and know first if their working hours are in effect, and second if they can snag a predetermined time on their calendar for a quick question or meeting.

​important​Chats allow people to set “away” or “available” statuses, but these methods can lead to leaning on presence too much by setting the expectation that when you’re “available” you’re de facto interruptible. Tying your availability to chat reduces your ability to do asynchronous work because the presence indicator means you’re “at work” and people may send chat messages your way instead of more asynchronous methods like email or a message in the project management tool that someone can respond to when they have time.

Some teams combat presumed availability in chat apps like Slack by having an agreed-upon protocol, such as using a specific emoji paired with the term “Focus mode” when they are technically “available” but do not want to be interrupted.

Time Off or Sick Days

Broadcasting to peers and managers should be sufficient to let people know when life intervenes, unless it’s a prolonged absence like medical leave, which would typically involve HR as well. Auto replies on email can fill the gap for people who don’t directly depend on the individual or people outside the company—Dharmarajan Ramadoss shares seven examples of email auto replies that you can use for various purposes. Whatever your team deems appropriate—a quick chat message, an email, or an update on your calendar—document this as well in your team agreement.

In Case of Emergency

It is useful to know how to reach someone in case of a true emergency. It’s best to agree ahead of time on a specific channel or method to be used for emergencies only; this can help people rapidly understand that a situation is genuinely urgent. Otherwise, a team—especially one with support or mission-critical functions like keeping the website running—may develop alert exhaustion, which makes people less likely to respond to instant message notifications or other means that are overused for non-urgent requests.

For example, the team can agree that a text or phone call signals urgency, and will be used only for such cases.

Response Frequency

Letting the team know how often someone reviews time-specific items like expense approval or responds to blocking issues helps people plan accordingly. You may wish to consider adding to your email signature a one-line response service-level agreement (SLA), like: “I review my email twice daily, at 10am and 6pm ET; and skim for emails prefixed with [important] every couple of hours during that period.”

​story​ “I set aside specific focus periods during my day to ‘Do Slack,’ and for the rest of the day I have my Slack status turned off. It’s not set to ‘away’—my presence indicator shows that I’m absent. This enables me to focus on the tasks at hand, reduces interruptions, and builds a norm that at Buffer, Slack is considered semi-asynchronous: people will respond at some point during their work day, but not immediately.” —Katie Wilde, VP of Engineering, Buffer

Response Protocols

The benefit and curse of many modern communication tools is that they can be used in a variety of ways. (See Determining Your Communication Architecture for more.) When Slack first arrived on the scene, many people were thrilled with an easy, instantaneous way to communicate with colleagues that could keep conversations out of dreaded email threads. Joy often turned to despair as the same people realized they now had an easy, instantaneous way for their colleagues to communicate with them, and suddenly everyone was drowning in Slack messages constantly screaming for their attention.

Not knowing when help will come can be a source of frustration and isolation for remote workers, and will also impact the speed and quality of their work. If there’s an established rhythm with associated protocols, then remote and office workers can structure themselves around it. Establishing the timeframe within which members of your team respond to communication across the channels you use can reduce people’s anxieties about their questions getting answered, and let people get back to work knowing that they will eventually get a reply.

For example, a software engineer may need someone’s eyes for a code review. Common requests like this needn’t be considered urgent, but rather can rely on a cadence of feedback and review, supported by appropriate tools. A software team may use a process like Pull Reminders to manage the pipeline of work moving forward, independent of time, which on top of a source-control tool like GitHub, GitLab, or Bitbucket, enables work to continue without requiring frequent interruptions. A marketing team might use Trello to move tasks through stages of work or to assign tasks to people asynchronously.

Each team then needs a response protocol that establishes when teams will reply either to questions or to a regular cadence of feedback via their chosen tools. The software team could agree that all members start or end their day by looking at pending code reviews, which sends a message that feedback will be sent within 24 hours. Knowing this helps all members organize their work in progress accordingly. If the team is larger, then there are more people who potentially can provide feedback more quickly, increasing the pace of the cycle.

These response cycles also depend on the team’s ability to escalate urgent items as needed so the organization can build healthy practices. A distributed organization can get comfortable with doing work on cycles if everyone understands that important or urgent items will be escalated and dealt with outside of the normal cycles.

Service Level Agreements

Customer support teams have developed the concept of response service-level agreements (SLAs) to set expectations with customers on when their concerns will be resolved. By defining a lightweight SLA for your team, everyone can know when they will get help, or how to escalate an issue if they’re not getting help. It’s also a useful management tool to protect the focus of teams, and to understand if teams are effective at serving the organization.

Unmet SLAs can also be used to diagnose issues—perhaps there’s too much work, the team is understaffed, or both. A reasonable manager can then expand the window and use the data to reduce workload or increase staffing.

An internal response SLA should:

• Be written down. Use simple text, such as more bullets and less prose, so it’s easy to understand.

• Be direct. Be clear about how long people can expect to wait for a response, and about which tool or channel you will use.

• Be accessible. The SLA should be easy for anyone on the team to find.

• Provide a help mechanism. You’ll need to have a way for people to request help, whether it’s a survey form or a link to a prefilled bug tracking system. This prevents people from falling back on interrupting methods that get them results, but cause other problems.

• Reduce the back and forth. Templates or forms can help streamline needed information without requiring that a person get involved.

• Allow for escalation. Describe how people can bump up their request if their question is unanswered

• Explain what is urgent. Give guidelines on what may be considered important or urgent, and clearly state what to do if there’s an urgent issue.

• Be measured and reported on. Otherwise it’s a hope and not an agreement.