editione1.0.3
Updated March 23, 2023You’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 overabundance of communication options in today’s modern workplace requires that we tend to them like a garden. The weeds of poor communication management can easily overtake distributed teams and choke their growth.
Understanding the different properties of the various communication channels available is necessary before deciding on your own communication architecture.
A communication architecture is a company’s documented set of practices, tools, and associated processes for how and when people communicate. It describes all the types of communication—such as email, meetings, phone calls, online chat—and the tools and protocols for using each one. The architecture guides each employee’s decision-making process as they communicate with other people at the company.
What works for a company of a certain size or industry won’t work for others; different teams within a company may also have their own preferred channels and scenarios for using them.
importantIf you have a hybrid organization, your communication architecture should span both distributed and non-distributed team members, and be consistent for everyone. For example, some companies choose to have everyone “dial in” from their computer for video meetings, including all the employees who are in an office. Once you understand the possible outcomes of the use of these channels, you can build a strategy that works well for your entire company.
Source: Doist
confusionThe concept of a communication architecture might sound imposing, but it’s largely the documented outcome of thinking through how your team wants to communicate, plus plenty of trial and error to learn what works and what doesn’t. It can be as simple as a set of guidelines written down in your handbook or on a shared wiki site, or as complex as what GitLab publishes for anyone to see. We offer some other examples of remote team communication architectures at the end of this section.
Email is a method of sending electronic messages between individual people or groups of people. It’s semi-synchronous, meaning it can be synchronous or asynchronous, depending on how an organization uses it. Examples of email tools include Outlook, Gmail, ProtonMail, Superhuman, and email accounts from Internet Service Providers (ISPs) like AT&T, CenturyLink, and Comcast.
Broadcasting. Email can be useful to broadcast information. For example, it can be used to inform the company of new funding, to describe new features coming soon, or to share a summary report for last quarter sales.
Sharing. Email makes it easy to share and re-share information. Messages can be forwarded or other people can be added into the conversation. This is very helpful when collaborating with other organizations outside your own, as you don’t have to set up permissions or access to your own internal tools.
Focus. When used exclusively as an asynchronous channel—where people don’t expect others to monitor and respond to email immediately—email allows you to maximize your focus. You can choose when to read your email and take time to think about how you’ll respond.
Volume and discoverability. Inboxes flood easily, obscuring important information. Counteracting this requires active management, either via labels and filters, or using other email management techniques.
Unclear expectations. People outside your organization may have different expectations for the use of email. If your role requires that you regularly interface with people outside of your company, you may not be able to control whether or not you can use it asynchronously.
Lack of boundaries. A company that doesn’t explicitly discourage responding to emails after hours can lead to unhealthy work-life balance.
Email is best used for:
Asynchronous, uni-directional broadcasting of information, such as announcements, updates to company policy, and other timely information.
Communication with people external to your company.
Fostering good work-life balance requires setting explicit expectations about responding to email after hours, with senior leadership and management leading by example in upholding those expectations. You may wish to consider using scheduling functionality to reduce the “after hours” messages you send to peers. Using established chat channels for emergencies or incident responses can also help prevent the expectation of constant email checking.
Including the frequency and the time of day that you read your email in your signature can help set expectations for people who may be accustomed to immediate email responses. “I review my email every day at 5pm EST; please text me for urgent matters.”
When broadcasting information to large groups of people or mailing lists, a good practice is to address recipients via Bcc instead of using the To or Cc fields. This prevents people from accidentally replying-all.
Web forums are web-based messaging groups where people write messages (typically called “posts”) in a hierarchical category structure organized by topics. Forums can be either public or private. Typically, public forums are for communicating with customers and private forums are for internal company communication. Examples of forum tools include Discourse, Flarum, and NodeBB.
Asynchronous. Forums can be used in an asynchronous manner to provide more static, broadcast-worthy information that people can refer to as needed. Forums can also work for brief discussions or to expand on clarifying questions. For example, a new employee can ask where to find important information in a forum, and get answers from their peers. From then on, all new hires can use that same post to get up to speed.
Predictable. Forums generally allow for information about a given topic to be updated in the same place. As new information is found, authors can expand or modify their questions or posting, keeping relevant information in the same place—especially compared to chat or text, where messages scroll up quickly over time and thus can be hard to track.
Open. Forums tend to be open by default, exposing everyone in a team or organization to the same exact information without the need for forwarding or use less transparent forms of sharing. This helps reduce the potential for miscommunication. When information is published openly in forums, it also becomes a historical record that can be searched, which improves the retention of institutional knowledge.
Lack of threading. Depending on the forum tool used, replies can become hard to follow if they can’t be threaded (or “nested.”). Threading shows individual responses to other people’s messages for a given topic, and helps maintain context as discussions of that topic evolve.
Potential for harm. Posting in spaces that are public or open by default can be intimidating or outright harmful, especially if there are people who don’t practice mindful communication.
Require moderation. Forums require active moderation so that conversations are productive, and so the forums remain collaborative spaces where everyone can feel comfortable sharing and asking questions.
Maintenance. Like all other collaborative tools, forums need someone to maintain them as the organization grows. Someone has to be explicitly in charge of managing topics and access to different groups in order for forums to work well.
Forums are best used for:
Asynchronous unidirectional broadcasting of messages and archival information (policies and the like that don’t change very often).
Asynchronous bidirectional Q&A.
Online forum discussions are famous for being controversial, giving rise to the term “flamewar.” If you choose a forum as a channel for your team, consider setting and enforcing a code of conduct that discourages off-topic and denigrating comments.
Creating labels or topics like “newbie” for forum messages can reduce the anxiety of asking a question that may seem obvious, and help newer members of your company find information they’ll need when getting ramped up.
Moderating and participating in work-related forums takes time and effort. Consider rewarding and celebrating this behavior, and allocating dedicated moderation time for people who participate in the tasks of moderation and maintenance of workplace forums.
Mailing lists are a broadcast form of communication based on email. Generally, one email address broadcasts information to all members of the group, and replies are then threaded under the same subject. Some mailing lists keep historical records, giving new members access to past discussions.
Grouping. Mailing lists can be used to cluster individuals under one shared topic or group. For example, this may include grouping all members of a team, a project, a department, the board of directors, the entire company, or specific interests.
Broadcasting. By sending to dedicated email addresses, you easily broadcast the information once to specific groups who may need access to the same information, without having to manage individual member access. For example, you could share your quarterly sales report with a sales team list and executives at the same time.
Sharing documents. Depending on the service provider that you use, you can share other types of artifacts with a mailing list. For example, Google Calendar supports sending invitations to mailing groups with a shared address. You can also manage access to specific shared documents or drives using group mailing lists.
Permission control. Mailing lists allow for specific posting and replying permissions. This feature can be handy when you want to create an asynchronous channel to update large groups on a regular basis without the risk of never-ending replies. Putting the mailing list addresses in the Bcc line will ensure that replies only go to the original author.
Focus. Mailing lists can usually be configured to provide daily digests or to filter specific information to certain recipients. This can help recipients manage how frequently they get notifications or email in their inbox, which helps them maintain focus.
Management at scale. Mailing lists can become unmanageable when there are too many people and discussions start branching out, or topics beyond the original intention start popping up. If access to large mailing lists isn’t managed, you will inevitably find yourself in the middle of one of those dreaded Reply All moments.
Closed. Membership isn’t usually transparent, leading to less control over and visibility into who has access to what information.
Spam and noise. Mailing lists can easily become spam vectors because they make it easy to contact many people at once. Similarly, when mailing lists are overused, people can start tuning them out, and they lose their effectiveness in broadcasting important information.
Bimodal. Since they are email-based, email lists are subject to the ambiguity of synchronous vs. asynchronous communication. They can become sources of interruption if you don’t properly manage the expectation about the immediacy of replies.
Potential for harm. Mailing lists are built to give quick access to a wide group of people, which means harmful or toxic messages can be quickly and widely transmitted.
Mailing lists are best used in your communication architecture for:
Asynchronous, uni-directional broadcasting of information, such as announcements, updates to company policy, and other timely information.
Communication with specific groups of people in your company
Regular digests of predictable information
Best practices include ensuring that the information you share to an email list group is on-topic and actionable or informative so you can keep recipients engaged. If the information you share is valuable and respectful of the attention it gets, you can increase the engagement on what you share.
Consider sharing broadcast-based messages with a small group of people for review before you send, so they can point out any ambiguous or confusing messaging. If you have marketing experts in your company, they can be the source of valuable feedback on internal communications.
As a recipient, consider replying privately to controversial or sensitive questions to prevent putting the original author in an uncomfortable position in front of a wide audience.
If you disagree with a specific message sent to the list, or have feedback for the sender, it is best to move to a channel that can carry tone, like phone or video, to resolve any conflict and converge on a clearer understanding.
A knowledge base (or wiki) stores structured and unstructured information online. Both are asynchronous and support rich text formatting and the embedding of different kinds of media like images, videos, or audio. Knowledge bases require that specific individuals be responsible for maintaining specific articles or documents, whereas wikis allow and expect for anyone with access to be able to add and modify anything posted. Examples of knowledge base or wiki tools include Confluence, ZenDesk, and Notion.
Easy contribution. Wikis are designed for easy contribution, which makes them excellent resources for shared knowledge. Onboarding materials, collaborative processes, or instructions on how to use specific systems are examples where office wikis can be better than knowledge bases.
Searchable. Both of these channels are designed to be searchable, making information easier to discover.
Clear change history. The modification of content in both knowledge bases and wikis is clearly documented. In knowledge bases, authorship is explicit, so someone is directly responsible for their contributions, including when changes are made. In wikis, the change history is tracked and associated with whomever made the change.
Good for reference material. Both wikis and knowledge bases support web technologies like links and attachments, which makes them excellent for documenting policies, processes, and providing related reference materials. Knowledge bases, due to their document ownership model, are better suited for institutional knowledge that doesn’t change often, like HR policies.
Maintenance. Knowledge bases and wikis are generally expected to have the most up-to-date information on a topic. When this is not the case, they become a source of misinformation. Organizations can prevent this by having explicit knowledge-maintenance roles and procedures. Similarly, these tools may become useless if adoption doesn’t propagate across an organization. Failed attempts at deploying a knowledge base or wiki can also result in skepticism in future attempts.
Curation. Knowledge bases aren’t collaborative by default, so they are best used when content will be curated, or when expertise is needed.
Not dynamic. Given the asynchronous, carefully maintained nature of knowledge bases and wikis, neither is an appropriate channel for fast-moving or rapidly changing information.
Knowledge bases and wikis are the mainstay of remote communication. They’re best used in your architecture for:
Documenting and sharing company goals, values, and onboarding materials.
In-depth writing about team plans.
Storing artifacts (spreadsheets, attachments, et cetera) that teams use in their daily work.
If you identify missing or outdated content, consider contributing something yourself. Wikis and knowledge bases are communal efforts, and can only work for everyone if there’s sufficient contribution.
If you’re not in a position to contribute content, then consider acknowledging those who do. Keeping organizations informed can sometimes be invisible work, but is worth celebrating.
It’s a good practice to help new employees find information and contribute. Knowledge bases and wikis are subject to network effects—they become more valuable as adoption and contribution increases.
Real-time chat (or chat or instant messaging or IM) allows for instant transmission of text between individuals or groups across a variety of devices.
Some forms are designed exclusively for one-to-one communication, while others allow for group conversations or the separation of conversations into different channels that can be public or private. Beyond text, different chat tools incorporate rich media like images, animated GIFs, voice memos, and emojis. Examples include Slack, Microsoft Teams, and messaging via social media like Twitter or Facebook.
Semi-synchronous. Chats can be used in either a synchronous or an asynchronous manner. This can also be a pitfall, if your company isn’t clear about expectations about how to use chat.
Instantaneous. Chats allow for instant transmission of information. This is great for getting immediate responses to questions, but often sets unhealthy expectations regarding immediate responses (see below).
Informal. Chats are a less formal method of communication, so people can spend less time thinking about how to craft the perfect message. This can be good or bad, depending on your message and who receives it. The conversational nature of chats also encourages more interaction between people. This can be great when people want to clarify questions or just have fun, informal discussions.
Interruptions. Chats have largely replaced in-office distractions and interruptions. Notifications popping up and direct messages (DMs) are now your virtual colleagues tapping you on your shoulder, pulling you out of your focused work.
Proxy for presence. Chat tools can also turn into implicit representations of presence. If you’re not on Slack, are you in fact working?
Lower quality. The casual, low-friction nature of chat can lead to lower-quality communication, which is sometimes hard to discern from more important, business-relevant messages.
Easier to misunderstand. Instant messaging can escalate heated discussions much faster when the need to respond immediately overcomes mindfulness. The lack of emotional context and cues in rapid-fire text messages can lead to misunderstandings and hurt or angry feelings. Additionally, the broad participation of a large audience can make it increasingly intimidating for others to share or participate, especially when they are newer to an organization.
Hard to track. Chat moves fast, and if people are requesting information from or assigning tasks to people on their team, those messages can get lost quickly. Chats are also not usually easy to search, and if your company has substantial history with a particular tool, search may become largely useless.
Chat tools like Slack and Teams are best used carefully and intentionally in your communication architecture for:
Asynchronous, non urgent questions to other people.
Asynchronous unidirectional broadcasting of information to a team or larger group (sparingly).
Synchronous non-work chit-chat and fun conversations.
Before you send an IM or chat message, consider using less distracting methods like emails or issue trackers. Being mindful of others’ time and interrupting less frequently will make it more likely you’ll get attention when you actually need it.
If your organization relies heavily on chats, consider using status updates or fields to communicate your availability and set expectations for others. Examples include:
“💻 focus time, getting work done”
“🥗 out for lunch, back at 1pm ET”
“🏝 out of office until the 18th; talk to Courtney”
It’s a good idea to disable the presence indicator for yourself if you can, and stop relying on it for others. It takes a village to encourage and reinforce practices that support focus over chats.
Instead of waiting for a response to a greeting before you state your request, you can group the whole statement. “Hi Jenn, do you know where I can find the wireframes for X?”
Sarcasm is very difficult to gauge tone over written conversations and therefore is best avoided. Emoticons :) and emoji 😬 may help, but can also have different meanings across age groups and cultures, and look completely different across devices.
Emails or forum posts may be a better way to get non-time-sensitive questions answered across different time zones than instant messages, since they allow recipients to batch requests and manage their outbound responses easier.
“No One Is Talking About the Biggest Problem With Slack” (Quartz)
“How Slack Ruined Work” (Wired)
“How to Use Slack: 19 Advanced Slack Tips You Need to Know” (OkDork)
Phone and video calls allow one or more people to have a conversation in real time, either via telephone or online video conferencing services. Calls are an exclusively synchronous communication channel, but can also be used to broadcast information when only one person speaks to a group. Example tools include Zoom, BlueJeans, Google Hangout and GoToMeeting.
Synchronous. Calls are great for resolving questions quickly or realigning when miscommunications over written mediums like email have happened.
Tone and emotional content. Calls also carry more tone, helping disambiguate and understand the mindset and mood of others.
Banter. Calls are a more natural channel for casual conversations, helping build better and stronger relationships.
Facial cues. Video calls allow people to see facial expressions and other gesticulations. Like intonation, this additional information makes messages clearer, adds emotional content, and helps build connection and trust.
Coordination. Calls can only happen in real time, which requires coordination overhead. This becomes harder when teams are distributed across different time zones.
Interpretation. Calls require that everyone involved understand the same language sufficiently, or that they include interpreters. Even among same-language speakers, phone calls (especially compared to video calls) can be hard for people with different auditory processing capabilities or if anyone has a bad connection.
Not documented. Calls do not immediately produce written artifacts, so if documentation is required, additional protocols or tech need to be in place to recorde or allow notes to be taken and distributed.
Despite the focus on asynchronous, written communication at remote companies, talking in real time has its time and place, including:
Regular meetings like one-on-ones and all-hands.
Team standups, if time zone overlap allows.
Planning and brainstorming meetings (best over video).
Resolving misunderstandings or dealing with escalating or emotional situations from other channels.
It’s important to be mindful of people’s schedules, be on time, and end the call on time to prevent cascading disruptions across organizations.
Calls are more effective if you take them from places with low background noise and keep in mind that wireless headphones with microphones far from your mouth can pick up more ambient noise. If you take many calls, you may wish to consider getting better-quality headphones designed for noise reduction.
If you’re having a sensitive call, like giving constructive feedback, discussing performance or even firing someone, consider role playing or rehearsing the conversation ahead of time, including unexpected scenarios, so you can be better prepared.
It’s helpful to identify someone to take notes so you can keep a record that can be distributed to other parties. If you share the notes with other call parties, you can confirm that you converged on an understanding during the call, or can correct misunderstandings quickly.
Before you ask for a “quick sync” or a “quick chat,” evaluate whether the information you seek or need to share can be disseminated or gathered via written mediums instead.
There are plenty of benefits to meeting in person occasionally as a remote company, especially for fostering meaningful connections and building trust. But there are associated costs and potential downsides worth considering when thinking about how often people get together.
Connection. Getting together fosters human connection and helps build trust.
Collaboration. Activities like planning and brainstorming are generally easier and more productive when conducted in person.
Speed. Communication and collaboration happen much more quickly when an entire team is in the same place. Some companies send new employees out to work with their onboarding buddy or mentor to making onboarding as quick and effective as possible.
Fun. Getting together isn’t just about business. Many people like offices because they’re also social spaces. Team lunches, happy hours, karoake sessions, and much more are only really possible in person, and most remote workers only get these opportunities with coworkers when they have the chance to get together.
Cost. Flying a few people to meet occasionally might be feasible for a small startup, but as companies grow, these costs can escalate quickly. A retreat for a company in the hundreds can cost hundreds of thousands of dollars*—Automattic spent $3.3M to host 800 employees in Orlando for their annual retreat.
Inconvenience. Traveling can be fun, but it can also be inconvenient. The burden of travel falls particularly hard on employees with specific physical or mental health needs, those with families or caretaking responsibilities, and for those who live far from the destination.
Safety. Some locations will be less safe for women, LGBTQ+ folks, and/or members of racial, ethnic, or religious groups to travel to or through. It is essential that companies take steps to keep all of their employees safe, by choosing locations that do not present risks of injury or harm to any employees.
Have a realistic budget. Retreats can get expensive, but a successful retreat doesn’t have to be extravagant.
Respect people’s time. Account for total travel time such that people aren’t gone for so long that caregiver and other responsibilities are strained.
Visit the section on offsites and retreats for all the details on bringing everyone together.
There’s a plethora of tools that we have at our disposal for different kinds of work. Tools like project management software, collaborative design tools, distributed source control for code, and others, become communication channels when we’re doing distributed work. Many of these types of tools support commenting, assigning people to tasks, and other means of communication that cross over with the other channels we’ve already covered—and many tools are aiming to handle a broader spectrum of uses, blurring these lines even further. We can’t cover them all here, but a few examples include Basecamp, Asana, Trello, and Jira for project management; Google Suite for documents, spreadsheets, and presentations; Figma and Sketch for collaborative design; GitHub and GitLab for code source control; and many other options.
Purpose-built. Tools can be better at serving a specific purpose than general-purpose work suites are. For example, project management tools that support collaborative teamwork are generally preferable to trying to keep track of everything in a spreadsheet.
Self-contained. important Communication features like commenting or mentioning people allow for information to be shared in the context of the work, which can lead to faster feedback cycles and less confusion about where to look for status or contextual information. This is an important principle of remote work: Keep discussions close to the work at hand. For example, if decisions about a marketing plan or bug fix are happening in Slack, then the context within the more appropriate tool or document is lost, and people relying on those tools may miss critical information or have to waste their own (and other people’s) time hunting down information in side channels.
Source confusion. When teams use too many tools, learning where to find specific information or how to find and log into each one can be cumbersome. This leads to confusion when you end up with multiple tools to track work in progress, or to store files in the cloud.
Tool proliferation. As tools become more specialized, they can be harder to use for general purposes, leading to similar tools being adopted by different teams. A source-code versioning tool may be good enough for software engineers to manage changes, but the legal team may prefer to keep using redlining in text documents for their workflow.
Overhead. As the tool collection grows, the need for dedicated access management by IT becomes more important.
Questionable reliability. Startups in particular are often early adopters of new tools. But sometimes newer companies that produce these tools are bought or shut down, leaving teams scrambling to figure out what to do with all their information.
Tools for project management, sharing designs, or tracking technical issues are a big chunk of your communication architecture, largely for:
Asynchronous status and context on projects.
Asynchronous questions and communication specific to team projects (as opposed to more general company-wide Q&A).
In some cases, synchronous collaboration, such as within a design tool or whiteboarding app.
Project management tools are only useful if the state of work in progress is represented accurately. Ensure that the state of your work is reflected on the tool as soon as you start or stop working on it, so others can rely on this information without asking around.
If you encounter information relevant to tasks in other tools, consider moving and reflecting it in the relevant tool or channel so others can have access to the same information. For example, if the team is discussing a particular GitHub issue in Slack, be sure to link to it in the chat, and direct the team back to the issue for discussion.
Evaluate your company’s tools occasionally. Especially at a growing startup, people’s needs will change and evolve, and while it’s important to allow teams to use the tools that make them the most productive, there’s a balance to strike when information starts getting scattered or hard to track across a multitude of tools.
“Best Startup Tools—According to 139 Founders” (Entrepreneur’s Handbook)
“Selecting Software: How to Choose the Best Apps for Your Business” (Zapier)
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:
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:
Source: Holloway
importantSome 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)
cautionFailing 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.
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.
importantWe’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.
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!).
importantWe 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.
contributeIf you’re aware of any other remote company or team communication architectures or plans, please let us know!
This section was written by Juan Pablo Buriticá.
For collaboration to work well in a remote organization, not only is healthy, intentional communication required, but a distributed team must clearly understand the direction they’re heading together: they need goals. Teams also need to determine a predictable rhythm to work towards those goals, giving space and autonomy to individuals to focus on their work. Goal alignment and autonomy thrive in a trusting environment supported by explicit working agreements that eliminate assumptions about how to work at a distance.
Getting teams to collaborate effectively takes effort, time, patience, and practice to refine the skills that support effective collaboration and coordination. Consider the concepts in this section as a set of capabilities that your team can strive to understand, try out, and adjust to their localized contexts. Every team is unique, and objectively defining what success looks like for your team is not something we can achieve in this guide. We hope that as you build these capabilities, you share what you learn with us and others so we can continue moving remote work forward.