Distributed teams are hard. Distributed teams, where some people are in office and others at home, are harder. Widely distributed teams with people working across countries and time zones are exceptionally hard. Widely distributed teams in a pandemic are damn near impossible to get right.

Culture clash alone is an enormous challenge. I once had a fantastic American product manager piss off an equally strong director of engineering (in India) by complaining that the tool the PM needed “had fallen and can’t get up.” The director—and the engineers on the thread—took it as a tremendous insult, even though the product manager was trying to inject a little levity. The PM should have linked to the commercial:

Distance, culture, and time zone problems make communicating hard in remote teams.

We have spent trillions of electrons this year on how to lead remote teams, so I’ll stick to something more prosaic: communication tools.

Slack, Jira, Microsoft Teams, Zoom – the communication tools you use matter but not as much as how your organization uses them.

Tweet

Over the past twelve years I have worked in four different distributed organizations that ranged from bootstrapped start-ups to huge, traditional corporations. I often found a lack of alignment caused by the inconsistent use of communication tools. Solving this required us to be way more intentional in how we communicate.

To communicate as a distributed team, you need to establish norms. Brainstorm norms as a group, winnow them down as leaders, align on them as a team and then communicate them out. When it works you get a written, jointly owned artifact that you can use to orient new team members and bolster the confidence of quieter team members. Above all leaders must model the right behavior; they need to adhere to the norms. When the rules are set up front, collaboratively, and followed by leaders, then the team is more likely to follow them. This eliminates the need for awkward corrections down the road.

My List

So here’s my list of communication tools and how to use them.

Face to Face Meetings

Good for: Well, really, everything. As my friend Dave Feldman put it, “all other things equal, face-to-face meetings are better for everything because they have really high emotional bandwidth. But they’re the most interruptive, hardest to coordinate, and can be wasteful of people’s time.” Face-to-face is the best way to have hard conversations. Generative exercises. Team building. Anything that started not face-to-face and got heated. Things that require dialogue. Design meetings, planning meetings, betting tables.

Bad for: Status meetings. Networking conversations. Routine discussions.

Video or Audio Conferences

Good for: Things that require synchronous attention but less dialogue. Structured discussions. Ideally, decisions that are less contentious. Prioritization exercises, design reviews, presentations of an analysis. Collaboration where a small number of people are presenting to a larger number of people.

Also good for: Not getting Covid 19. Right now it’s usually as close as we get to face-to-face. That said, video conferences have unavoidable limitations. We need to acknowledge them and mitigate.

Bad for: Energy levels. Video is draining. Use it sparingly. Find other ways to ensure that all participants are “present” and attentive. You know your team is healthy if it is present without being threatened by the green camera LED. If the meeting is small enough be sure to “go around the room” once and check in with each attendee, one by one, asking them what they have to add. Make sure that everyone feels heard.

Email

Good for: Asynchronous, text-heavy communication. Wide distribution groups. Not time sensitive. Easy to read, so long as you write them carefully and put important content high in the email body. Things that people may want to consider and respond to. Monthly status updates to investors or senior leadership. Summaries of organizational changes (after those organizational changes have been announced synchronously to those directly affected).

Major 🔑: Put the most important information into the subject line and lede (more here). Make sure your emails are easy to read on mobile devices.

Phone and Text

Good for: Getting a hold of someone after hours or while they are away from keyboard (e.g. in transit) and you need a dialogue. Always text first.

Chat

Patterns: Establish clear norms as to when people are / are not expected to be available on Slack; use threads to allow people to follow topics. Be aware of timezones; encourage use of Away messages. Train people on how to manage their notifications, alert settings, and Do Not Disturb. Don’t assume they’ll figure it out, or will feel comfortable turning it off. Use public channels, created for topics, teams and projects.

Anti-patterns: This is going to need a bulleted list.

• Remember that text loses tone, and that low-fidelity communication tools like chat can amplify management mistakes. Give people the benefit of the doubt when they seem clueless but do not tolerate behavior that makes people feel unsafe, particularly by those with power.
• Chat transcripts ≠ documentation because is almost impossible to find things in history and often unclear what decisions were made. If you agree on a behaviour or solution to a problem then document it somewhere and link to it from the conversation, then link the document or ticket back to the conversation.
• Chat messages ≠ to-dos or workflow tasks. If someone agrees to do something in slack, create a ticket in the relevant tracking tool and link to it from the conversation.
• Avoid using #general. Real conversations should happen in dedicated channels. Slack channels are analogous to email threads.
• Avoid using group messages: they’re hard to find, not categorized by topic, and carry an unclear expectation of privacy.
• Most channels should be public: You should only make a channel private if you have a solid, clear reason to make it private, like a channel for peer managers to discuss performance issues across their collective team. If people only feel safe in private team channels something bigger is wrong with your organization.

Finally, chat can make bad managers worse. The combination of immediacy, reach, lack of nuance, and lack of non-verbal feedback can encourage some incredibly stupid behaviour that can be hard to undo.

Wiki

Good for: Documentation, references, working documents; Version tracking important; High-fidelity (fancy formatting) not important

Bad for: Things that imply sequence. Workflows, etc. Require a lot of maintenance. Prone to getting out of date.

Bug Tracking or Workflow Management Tools

Good for: Things that have a deadline, dependencies, multi-step tasks, etc.

Bad for: Requirements, specs, designs – anything more than a few lines shouldn’t live in the bug, but should be linked out to a doc from the bug. Bug tracking tools are hell to search.

Documents

This includes Google/Word Docs, Slides/Powerpoint/Keynote and Sheets/Excel

Good for: Narratives or analyses; work that needs a lot of formatting and high fidelity. Work that changes slowly. Read-aheads for meetings. Group editing. Tools like Google Docs and Dropbox Paper have great commenting tools although Confluence has come a long way.

Bad for: Requirements. Reference documents. Documents that are expected to be maintained over a long period of time. After a project is over things like Word Documents are typically lost in a shared folder, hidden away, and never used again.

Major 🔑: Tuck documents away neatly after a project. If they are no longer being updated, add a prominent note to that effect in the top of the document, with a link to other relevant, and more recent information (i.e. a Wiki). Manage the zombies.

Things to remember

Avoid holy wars. Focus on picking the smallest number of tools that cover the greatest number of use cases, weighted by importance. Don’t let the perfect be the enemy of the good, but be aware of tools with high switching costs (bug tracking, chat) and be careful.

Remember that the process is as important as the outcome. You want to have broad support for the list so that influential team members feel ownership and will actively help to improve communication. That support should be backed up by top-down direction. And finally, don’t be cheap. Buy the right version of the tools and spend the money needed to get them configured and maintained property. If well paid software engineers are cutting and pasting tickets between bug tracking systems, I will find you.

Above all, expect change. How an organization communicates will change. Plan for it.

TL;DR

In a distributed organization, leading well requires intentional communication. Intentional communication requires the effective, consistent use of digital tools. To achieve this:

• take an inventory of the communication tools in use,
• crowd source and align on the specific tools you are going to use and how you’re going to use them,
• write patterns, anti-patterns, and starting points for each–make norms explicit by writing them down,
• share them widely, and finally,
• revise them often to keep them useful.

One last thing. Communication is good, but too much communication is not a healthy signal. People need time to think, plan and work. They should not be thrashing endlessly between Slack, Jira and Docs. So make sure that people know how to protect their time and are able to set boundaries, get work done, and feel as though they are accomplishing things.

---

Special thanks to my friends Michael Masouras and Dave Feldman for their ideas and their thoughtful help polishing this. Updated with ideas and edits from Dave on September 7, 2020.