Determining Your Communication Architecture

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.

In order to determine how best to communicate, you will need to inventory the tools and channels your company uses, and pair those with your own values and communication philosophy. This should apply to everyone at the company, including in-office employees in a hybrid environment.

Here’s an example of what a more traditionally co-located communication structure might look like:

Figure: Co-located Company Communication Channels and Tools

Source: Holloway

While most remote companies prefer and prioritize asynchronous, written communication, a given company’s size and philosophy dictate how extensive this may be, and if or when to deviate and choose more synchronous channels. A small startup is best positioned to know all the tools and understand what works for everyone; but as the company grows, this can and will change.

Here’s a sample communication architecture for a remote-friendly company:

Figure: Remote-Friendly Company Communication Channels and Tools

Source: Holloway

​important​Some tools are neither inherently synchronous or asynchronous, but rather a company’s cultural and explicit behaviors dictate how they are used—they are “semi-synchronous” unless otherwise clarified. A classic example of this is how, when Slack first arrived on the scene, many companies embraced it as an alternative to email, but then began to discover that it was just as painful and difficult to use as a communication channel as its use grew and messages scrolled by quickly and were hard to search. And even worse, where email didn’t necessarily interrupt people’s work as much as email, Slack became a major source of distraction for many people largely because its use was (implicitly or explicitly) expected to be synchronous.

Different teams may have very different requirements for how they want to approach semi-synchronous channels and tools. A technical support team may use GitHub Issues asynchronously, but have an expectation that the list is reviewed daily and responses won’t take more than 24 hours. Whereas a design team collaborating in Figma may share a design with the expectation the review and feedback happens (in the tool, not in email or chat) over the course of a few days to a week. (We cover this in greater detail in Remote Team Agreements and Protocols)

​caution​Failing to examine and codify how your company uses these semi-synchronous tools and channels is a serious source of risk for less productive, confusing, or outright aggravating communication practices across remote teams. This doesn’t mean “Don’t use Slack,” rather, spend some time examining which tools you use, and how, to best understand how to support remote communication at your company.

Take Stock of Your Channels and Tools

Start by writing down all the tools and channels your company uses. If you’re small, this is easy; at a larger organization, this may need to be delegated to various teams and will take some time. Taking stock includes collecting feedback on what is and isn’t working well—what are the pros and cons for the various channels presented above? You may realize that your team still relies on email for a wide variety of communication from planning to status updates, as well as more synchronous forms of decision-making. Or you may find that Slack is consuming far more time from everyone than you realized, and people are struggling to keep up with who is asking for what, and when.

​story​ “At Holloway, we realized we were overcompensating for our hybrid remote structure by having decidedly too many meetings. While we cared deeply about asynchronous communication, and writing and documenting as much as possible, we were still all spending easily a third of our days in meetings, and it wasn’t working for anyone! We shifted more planning and project tracking to tools we were already using like Notion, Trello, and GitHub Issues, and sharing weekly status and goals via written means. We still get together once a week for an all-hands meeting and have individual one-on-ones, but now that we’re getting our asynchronous communication more dialed, these meetings help us tease out nuances and talk more about collective goals and next big things on the horizon instead of detailed status reports or similar updates.” —Courtney Nash, Director of Editorial, Holloway

Here’s the catch: we can’t tell you what the right channels and tools are for your company. You can learn that only by doing the introspective work of understanding how your company is communicating now, and whether that needs to change. Then you can determine the right approach from there.

​important​We’ve compiled a comprehensive list of all the potential tools and services that remote companies might want to consider. While looking at your own inventory of tools, you can consult this to compare against other options or research new categories of tools you’ve not tried out yet.

Build An Asynchronous Base

The next step is to pick the channels you’ll use to do the bulk of your work. You’ll want to focus on shifting communication to appropriate asynchronous channels, and giving everyone context on how to use those channels properly.

Your base will likely be one or two channels and associated tools for documenting goals, project plans, and ongoing status. Ideally, a base won’t contain much more than that, or people won’t know where to look when trying to understand what they should be focusing on and how things are progressing. This may be a combination of knowledge base or wiki-like tools such as Notion (or even Google docs); project management options like Trello, GitHub Issues, or the like; and possibly a dedicated forum or channel for standup or status-like information.

From that base, it’s wise to establish clearly when, why, and how people might choose more synchronous modes of communication. For example, people will want to be having one-on-ones, ideally via video chat. Teams with enough time zone overlap might have daily (or at least regular) stand-ups, and company all-hands meetings happen synchronously as well (but may be recorded for those with big time delays and those who couldn’t attend). It’s also a good idea to include the timing of any form of team get-together or retreat, and what people can expect.

You will also want to plan for dealing with questions and the unexpected. Many questions can still be handled asynchronously, either via dedicated Slack channels (with reasonable expectations of response times), or some form of established Q&A forum that at least one assigned team member regularly checks. Even then, occasionally something might really be urgent, in which case it helps to have clarification about what really is urgent, and an agreed-upon protocol for escalating issues (which is hopefully very rarely used!).

Document Your Architecture

​important​We can’t emphasize enough how important it is for remote companies to write the right information down. A good communication architecture will establish all the channels you use, and your company’s policies for how, when, and why each one should be used. It helps to have a quick overview (or a nice diagram like Doist), but it’s critical not to neglect writing down how to use each part of your communication architecture.

It’s one thing to say “Default to asynchronous,” and another to state clearly that people shouldn’t email colleagues expecting an immediate response, and also to explain how to use scheduling tools that can send emails based on the recipient’s time zone. (If you have too many time zones, email may become largely obsolete in your company except when dealing with external people. That’s okay.) If decisions shouldn’t be made via Slack, it’s important to be clear how and where they should be made, and to ensure that’s really happening.

How you decide on and document your communication architecture is inherently tied to your company’s philosophy and values. GitLab’s communication guidelines are over 16K words (or about 50 pages long),* and include guidance on implementing MECEFU, which is “an acronym for Mutually Exclusive Collectively Exhaustive Few words Ubiquitous-language.” Basecamp’s communication guide is 30 zen-like tidbits that guide how people there should interact. Stripe makes almost all internal email available to anyone at the company. Leadership at a remote company is responsible for deeply understanding how communication needs to work, and then writing it down, and leading by example.