Asynchronous communication for remote work

How to get started with async

Review the Asynchronous Work section on the Communication page.

What is asynchronous work?

We love Preston W.’s explanation from the Remote blog

“Asynchronous work is a simple concept: Do as much as you can with what you have, document everything, transfer ownership of the project to the next person, then start working on something else.”

Asynchronous work is growing in popularity because it significantly benefits both employees and employers.

Six benefits of asynchronous working

1. Asynchronous work provides autonomy, empowerment, and agency

2. Asynchronous work increases efficiency and boosts productivity

3. Asynchronous work is more inclusive

4. Asynchronous work alleviates stress and supports mental health

5. Asynchronous work encourages thoughtfulness and intentionality

6. Asynchronous work bridges the knowledge gap

Guide to asynchronous communication

Schedules and calendars have conditioned us to operate in synchronicity — when two or more parties are in the same place (either physically or virtually) at the same time.

However, we now live in a world where asynchronous (async) communication allows us to move projects forward without requiring stakeholders to be synchronously physically or virtually present. Async communication optimizes how (and when) people work and communicate.

How does asynchronous communication work?

Fundamentally, asynchronous communication is simple. We do it all the time, when we send messages, leave voicemails, and record videos. Communicating async just means that the recipient of the message and the sender are unlikely to be in the same space at the same time.

However, doing async communication well requires significant intentionality. When creating an async message, you have to consider questions like:

• Am I using the best format (written, verbal, video…) for this message?
• Does the person receiving this message have all the context they need?
• Am I communicating clearly so that there will be no confusion?
• Am I considering the tone of my language and how this message will be received?
• Am I providing any needed resources or next steps, so that the conversation or project can move forward?
• Is this communication being documented in a way that it can be found later for future reference?

This level of thoughtfulness often produces communications that are clear, complete, delivered with kindness, and that create productive results.

This also means that communicating asynchronously takes more time and planning, and requires specific tools. When it comes to async communication, there is as much to unlearn as there is to learn.

The investment of time and strategy is worth it: communicating well asynchronously creates major improvements in efficiency, and supports strong collaboration and teamwork.

You can’t do async communication without strong documentation

The importance of strong documentation for async communication truly can’t be overstated. No matter how intentional you are in communication, there’s always something that will be left out, misunderstood, or needed to move forward. If someone has a follow-up question, they may need to wait hours or days for a response. Alternatively, they can look up the answer in the company handbook.

GitLab has a handbook-first approach to all communication. Our goal is to ensure that our handbook is always up to date and that it is a powerful resource to make our team massively more efficient. The GitLab handbook would be over 2,000 pages if printed, and it is available to read for any visitor who wants to know how we work.

While you may not choose to have this level of transparency, be aware that transparent information-sharing within your organization is crucial to asynchronous work. Every team member should be empowered to do their work at any time, whether or not their teammates are online and available.

Using GitLab for remote collaboration

GitLab’s entire team uses GitLab to collaborate asynchronously on all of our work. GitLab is a collaboration tool designed to help people work better together whether they are in the same location or spread across multiple time zones.

Originally, GitLab let software developers collaborate on writing code and packaging it up into software applications. Today, GitLab has a wide range of capabilities used by people around the globe in all kinds of companies and roles.

You can learn more at GitLab’s remote team solutions page.

When to use asynchronous instead of synchronous communication

While GitLab has 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.

Highly capable asynchronous work still allows for, and includes at appropriate moments, some synchronous discussion. Async is very powerful for GitLab, but not an absolute — especially if at the expense of our values.

GitLab experts advise on when to use sync vs async

1. “I use sync meetings to help others when an urgent matter comes up such as incidents or deadlines.”
2. “I use sync mainly for troubleshooting where more live dialog is faster for all parties to solve the particular issue than async explanations and back and forth.”
3. “I use sync when I have exhausted async options or async is not leading towards Results.”
4. “I use sync meetings to generate creative ideas/proposals with my team that quite frankly would be difficult to do async.”
5. “10 minutes on Zoom is more efficient than 100 Slack replies over a few hours or 10 days waiting for GitLab issue thread replies from tagged team members.”
6. “For work-related, formal comms, I prefer async (and choose async when the format is up to me). Sync is great for relationship building (coffee chats, group social chats).”
7. “I enjoy sync to establish an initial human connection when team members have never met before (e.g. coffee/social/team calls).”
8. “If something is very time sensitive, I will opt for a sync meeting with all involved to have a quicker discussion.”
9. “I tend to lead with async communication and then fall back on sync conversations when async fails. I view async communication to fail when time-sensitive topics aren’t addressed efficiently or if I sense folks contradicting or talking past one another. In these situations, I’ll call a sync conversation to focus and force conversations to happen, then revert back to async once the conversation is essentially unblocked.”
10. “Async works very well for detailed technical conversations, especially when linked to code. Sometimes it can take a couple of reads to conceptualise something and async is perfect for this. Async is also great for code reviews. For big picture discussions a combination of async and live/videocall is useful, but the results should be documented in the related GitLab issue for transparency. We sometimes use Google docs but GitLab are a better record, and are easier to search and comment on.”
11. “I prefer to keep it async most of the time, but I’m also aware that as a Product Designer I need sync time during early stages in the design process to ensure I understand the problem and to brainstorm together with the team. After that, I find that async can be as efficient as sync, but only if everyone communicating puts in the effort in their written communication. It’s important to include extra details and be extra careful about how you write to minimise the potential misunderstanding and need for back-and-forth.”
12. “I handle most communications async, but found that the occasional sync meeting helps the entire product team come into alignment. Our sync sessions bring everyone to the table to discuss user research results, review designs, discuss implementations, etc. This rarer meeting helps keep everyone in alignment and helps the team’s async structure flow more easily.”
13. “For most cases I default to async communication. In general it is easier to trace back steps and reiterate on reasoning that lead to given decision. On rare occasions it is hard to share a given point of view. After several backs-and-forth on single matter I prefer to have short chat to get to the bottom of the issue, and document outcomes. Another exception where I prefer sync over async is the final brainstorm before making an important decision. In async communication, some matters appear too trivial to be asked about, while they may turn out to be important in the end. For such cases, after having a synchronous brainstorm as a final closing step, a retrospective or AMA session may be useful.”
14. “I work with very technical concepts that are hard and time consuming (for me as a designer) to understand via async communication (especially written). It is more efficient to meet with a more technical colleague who can explain the tech details and purpose of a feature and who can answer questions on the spot. After I have a good understanding of the technical details I am more comfortable working async.”
15. “During async communication, there’s often a lot of context-switching that happens as you wait for someone to respond. It’s sometimes necessary to have synchronous communication to make sure that you can move forward quickly.”