Response 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.

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.