Skip to content
Shishir's Guide to Distributed Teams
Intro
1. Virtual Space
2. Meetings
3. Communication
4. IRL
5. Fun!
More
Share
Explore

icon picker
3. Communication

Principle: A matrix of communication channels, with a public-by-default bias

When people talk about distributed teams, one of the main questions to ask is the time zone question ー it is one step to be distributed across different locations in the same time zone, but it is entirely different to work across time zones as many of the single time zone norms break down. Your communication patterns get split and you have to choose what works synchronously and what needs to be done asynchronously.
Setting up a communication structure requires matching the communication channel with its purpose. Here are a few tips...

Choose your communication channels, and set norms for each

While many teams dream of a fixed set of communication channels, in my experience, it is inevitable (and perhaps even helpful) to have different channels for different types of communication. At Coda, we have 4 primary modes of communication, that are generally paired together for each team:
Coda doc: Primary home for team communication, coordination, and documentation
Slack: Synchronous "whoever is available", unstructured, ephemeral communication.
Email: Asynchronous "targeted", unstructured, long-living communication.
Meeting: Standing checkpoints for alignment, and ad-hoc when the above methods are insufficient.

When a new team is created at Coda, all 4 of the above are generally created (ideally with matching names so others can find them too).
The Coda doc forms the home for the team ー it generally describes and aligns on the purpose of the team, sets the norms and priorities, and often has the tracking lists for tasks and work items. A well constructed Coda doc with clear areas for both structured and unstructured communication can significantly reduce the needs for the other 3 tools. Here are a
few templates
⁠
to start with.
Typically this is paired with a Slack channel (the Coda doc is usually "pinned" to the channel for each access). For us, Slack forms the virtual water cooler for the team ー intentionally unstructured and meant to fill gaps as quickly as possible. That said, the synchronous nature of Slack can often be a downside to communication, as it can lead to lead to (a) an "always on" feeling and (b) confuse decision making by optimizing for "whoever is available". We find it best to think of Slack as ephemeral and lean into its synchronous nature as an advantage. One simple rule of thumb we have is: if you are out for a few days, you should expect to be able to declare Slack bankruptcy and not read what you missed.
Each team then constructs two email aliases (more on why there are two below). While email leaves a lot to be desired, it still tends to be a critical communication stream. For externally facing teams, email is the most common medium of customer and partner communication so it's somewhat inevitable. Internally, email fills the gap that Slack misses ー it's intentionally asynchronous and leads to more thoughtful discussion.
Finally, a new team will generally set up a standing team meeting. A general best practice is to keep a section in the Coda doc with the agenda for the next upcoming meeting. In this way, adhoc conversations that haven't been resolved via Slack or email can be put on the docket to be handled at the team meeting.

A new twist: Public-by-default email

One choice we made that made the above system work was adopting a public-by-default email system ー inspired by the
Stripe Email Transparency model
⁠
(also adopted by other teams like
Khan Academy
⁠
).
The core idea is simple, and inspired by Slack. One of the best by-products of Slack is that it greatly opens up communication. Though private channels are well-supported, most teams default to public. This leads to teams developing a set of followers who are not necessarily team members.
⁠
⁠
⁠
While this may seem negative, in practice, the benefits tend to outweigh the cons. We'll regularly see non-team members comment in a Slack thread ー adding context to a conversation, or highlighting an overlap that they may have missed. Norms tend to adapt quickly with an expectation and understanding that the core team is primary, but great ideas are accepted from anywhere.
A core Coda value is "great ideas can come from anywhere" and a public-by-default system aligns with that value.
But the challenge is that Slack isn't appropriate for all communications, and email is by nature "private" by default.
As we were discussing options here, I happened upon the
Stripe post on email transparency
⁠
. In some ways, this felt like a nirvana. From there, we developed our own version of this system. Here's the core mechanics:
Each team has two email aliases: team-[name]@a.com and team-[name]-fyi@a.com. The former includes all the formal members of the team, and the latter is meant for followers. The fyi alias is a member of the team alias, so communication naturally flows to followers.
When sending email, almost always cc an fyi alias: If your communication is explicitly private, it's fine to ignore, but generally you should pick some fyi alias [there's a coda-fyi@ alias if nothing seems appropriate]. You should expect your mail to be read by everyone on the To line, but anyone in the fyi aliases may or may not choose to read / participate.
When receiving emails, focus on your team and direct mentions, optionally handle fyi messages: Most people set up email filtering rules to place their fyi messages in the appropriate place (and we've built a few tools to help with this as well).

That's it! This system has a few key benefits:
Embrace followers: Provides a way for serendipitous interactions to happen. Someone who has more state on something may notice what's happening and jump in to help. This reduces siloing, makes it easier to function as a distributed team (and even just know what we're working on), and generally increases the feeling of connectedness.
Persistent and long-living: Provides the full history on interactions that are relevant to you. If you're pulled into something, you can always pull up the relevant state. Makes conversations persistent and linkable, which is particularly useful for partner teams and new hires.
Ideally, requires ~no additional effort from the sender, and may reduce effort: When we started this, I was concerned that this would add extra effort for senders, but then observed the opposite. It turns out that one of the daunting tasks in sending an email is trying to get the perfect list of "To:" and "cc:" recipients. With fyi aliases, this substantially reduces this pressure. And it forces senders to think about how we're segmenting information — if you're tempted to send something off-list, you should think through why.

It's a bit non-traditional, but public-by-default email has helped fill a key gap in our communication stack.

Publish the matrix

Once you have set up the communication channels and have your patterns, a very simple, helpful tool is to publish a table that shows the matrix like this:

Team Channel Mapping
0
Team Name
Slack channel
Email Alias for Team Members
Email Alias for FYI Members
Standing Doc
Standing Meeting
1
Mobile
#team-mobile
team-mobile@a.com
team-mobile-fyi@a.com
https://coda.io/d/...
Every Mon at 9am
2
Sales
#team-sales
team-sales@a.com
team-sales-fyi@a.com
https://coda.io/d/...
Every Tues at 2pm
There are no rows in this table
⁠
Not only with this help new and existing employees find the right resources, it will also help maintain naming conventions and identify gaps in the structure.

⁠
👉 Next up:
4. IRL
⁠
⁠
⁠

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.