Link Search Menu Expand Document

Asynchronous communication

1. What is asynchronous communication?

Asynchronous communication is when two (or more) people can communicate without the requirement that they be “present” at the same exact moment in time.

Examples: email, Slack, project management tools like Jira, company wiki and workspaces.

Synchronous communication is real-time communication when two or more parties are talking or exchanging messages at the same time.

Examples: in-person meeting, video call/conference, phone call, asking the teammate across your desk a quick question.

2. When to prefer asynchronous communication

  • Proposals and thought-starters should be written down, so that feedback and consensus can be gathered quickly asynchronously by a wide group of people.
  • If you’re asking for help or feedback from another team member(s), you should be willing to document the request in a Jira issue, or pull request with the appropriate context.
  • You don’t require immediate feedback, and you want to respect your recipients’ time
  • You need to collaborate with someone in a different time zone who isn’t at their desk at the same time you are
  • You need to communicate a message to group of people who can’t all be in the same place at the same specific time, or whom it’s difficult or expensive to get together
  • You want to provide context before or after a real-time event
  • You need to explain a complex concept in a way that people can go back and reference later
  • You’re providing a response to a piece of asynchronous communication you received
  • Generally, it’s best to avoid a meeting for the following items: status updates, FYIs and process documentation, meeting about a meeting. Suggesting to “hop on a quick videocall” may feel insignificant, but it can have a negative impact on productivity.

3. When to prefer synchronous communication

While we should have a bias towards asynchronous communication, a strategic balance between synchronous and asynchronous is useful for achieving maximum efficiency. Working asynchronously is not a goal unto itself; rather, being considerate and opting to move a discussion or project forward asynchronously when feasible creates more space for synchronous moments. Use synchronous communication when:

  • You want to build rapport with people (e.g., in one-on-ones, team meetings or company retreats)
  • You need to provide critical feedback or discuss sensitive topics
  • You have a lot of unknowns and you want to brainstorm different ideas and solutions
  • There are a lot of moving variables and you want to bring everyone on the same page quickly, e.g., a project kickoff meeting
  • A crisis happens that requires immediate attention
  • When a back-and-forth asynchronous conversation is moving very slowly with a high volume of small statements between two people, sometimes a quick synchronous discussion leads to a quick micro-resolution. Generally, if two people go back-and-forth more than three times on the exact same topic — and it’s impractical to break it into smaller async-friendly decisions — it makes sense to temporarily pivot to synchronous. Following pivots to synchronous, there should be a written summary created to inform others of the outcome, ideally shared in a relevant Jira issue or pull request.
  • When it’s clear that a kickoff meeting is useful to build rapport, trust, and quickly deliver shared context to a group, consider starting a project synchronously. This initial engagement should be used to establish a working foundation, such that future touch points can be primarily asynchronous. Starting with a synchronous may make sense for the following: first-time meetings with team members who have not previously worked together or external parties; one-way door decisions (e.g. when stakes are high and decisions are difficult to reverse), emotionally sensitive topics (e.g. discussing personal issues, career path/promotion, difficult feedback, etc.), celebrations and retrospectives (it feels good to celebrate wins with a group, and lightweight retrospectives can serve as kickoff points for future sprints)

4. How to decline meetings in favor of async

Suggesting an asynchronous workflow over a meeting can feel uncomfortable. We want to ensure that all team members recognize this for what it is: a sincere attempt to move work forward in a more inclusive way, and not a personal slight. If you’re invited to a meeting that may not need to exist, it’s OK to respectfully decline and point team members back to this handbook section. Below are a few sample responses, borrowed from an excellent remote communications guide assembled by Dropbox.

  • “Thanks for including me! I’m wondering if we could try to solve this using a Jira issue or pull request instead so our thoughts and progress is documented?”
  • “I’ve been in so many meetings lately, but I’m trying to be more disciplined about my schedule. Could we try to solve this without a meeting, first?”
  • “I’d be happy to give you feedback on that! Before we schedule a meeting, could I review it in a Jira issue or pull request, or shared doc?”

5. Other tips and best practices

  • Plan ahead to give people time to consider your message. For example, “I want to finish this in 2 days and would love your input”, instead of “I need your feedback in the next hour.” If you need an answer quickly, explain in your message why this is the case.

  • Always check your document sharing settings. This seems like a small thing, but if someone needs to request access, it can lead to hours or even a full day of delay.

  • After meetings, document discussions, and outcomes. Start, or continue, a thread or document so that people who weren’t there can find that information. Make video recordings of the important meetings so that others can “attend” them asynchronously.

  • Turn off notifications. Instead, set aside specific time blocks during the day for checking and responding to emails and messages.

  • Use waiting time productively. We’ve found that waiting for a reply isn’t a huge problem as there’s always something else to work on. If it is a problem, then communicate that to the other party.

  • Overcommunicate. When sending a message, include as much information as possible. Visualize things with screenshots or screencasts. Be clear about what you need from the other person and what the deadline is. A few extra minutes adding details and editing for clarity on the front-end can save days of back-and-forths in an async environment.

  • For some meetings it is better not to use PowerPoint presentations, but a well prepared and narratively structured memo instead, which can be read before or at the start of a meeting. Our brains process good storytelling much better than hard data. Such narrative memos give authors the chance to fully communicate the thoughts behind their ideas, and give meeting participants the chance to better understand full concepts.

  • Indicate what will happen if no response or feedback is given. Make sure that the default action is reasonable and that everyone has time to react. You can ask people to acknowledge the message using Slack reactions for example to distinguish between no feedback and not responding.

Inspiration