Update file _index.md to add clarity on async

If there is an issue to raise regarding someone's communication or conduct, team members should follow the process for [raising communication concerns](/handbook/people-group/team-member-relations/#raising-communication-concerns) by sharing their concern with their manager or, if preferred, email Team Member Relations (teammemberrelations@gitlab.com) directly.

### Transparent Communication

As GitLab grows, multiple teams are working together to scale up our processes, policies and systems. Leadership DRIs also strive to make decisions that will directly or indirectly impact team members. In order to make sure we provide adequate communications on these incoming changes, the following communication matrix aims to provide guidance for both leadership and team member on what to expect for each type of change.

| Communication Type | Explanation of Why | Feedback Mechanism | Example |

|-----------|-------------|---------|---------|

| **Decision has already been made** | Within confines of SAFE, explain why this decision was made, and "What prompted you to make this decision" | Provide a link to an issue or similar where feedback can be submitted but with the understanding that the decision may not change in the near future | GitLab's New Operating Model |

| **Intent/Proposal discussion** | "Why" is explained in detail, with data where possible. Include "What are we looking for, Problem to solve, Here are all the options, go deeper" – what do you expect from others (based on what they can influence) | Provide a link to the issue or similar where feedback can be provided. Also share timeline by when feedback is gathered and provide updates on decision making process | Moving Friends and Family to End of Year (we've seen problems with XYZ so we'd like to move to end of year, and would like feedback on these specific / more targeted areas) |

### Communicate directly

When working on a problem or issue, communicate directly with the people you need support from rather than working through reporting lines. Direct communication with the people you need to collaborate with is more efficient than working through your manager, their manager, or another intermediary.

Escalate to management if you are not getting the support you need. Remember that everyone is a [manager of one](/handbook/values/#managers-of-one) and they might have to complete their own assignments and inform the reporting lines.

### Communicating When Using Generative AI Tools

1. **[Own your output](/handbook/values/#have-ownership--accountability)**: You are responsible for the accuracy, appropriateness, and value of any content you share, regardless of how it was created. As the ultimate author, you should read, understand, and refine comments, code or other artifacts before asking others to review.

In an all-remote organization effective communication is key to exchanging knowledge, ideas, and information. Effective communication at GitLab:

- Uses [asynchronous](/handbook/company/culture/all-remote/asynchronous/) communication as the starting point and stays as open and transparent as we can by [communicating via text](/handbook/communication/#writing-style-guidelines) through public issues, merge requests, and Slack channels (over DMs).

- Uses [asynchronous](/handbook/communication/#asynchronous-communication) communication as the starting point and stays as open and transparent as we can by [communicating via text](/handbook/communication/#writing-style-guidelines) through public issues, merge requests, and Slack channels (over DMs).

- Places an emphasis on ensuring that conclusions of offline conversations are written down ensuring a [single source of truth](https://docs.gitlab.com/development/documentation/styleguide/#documentation-is-the-single-source-of-truth-ssot).

- [Produces video](/handbook/marketing/marketing-operations/youtube/) when necessary.

If you would like to improve your skills or expand your knowledge on topics relating to Communication at GitLab, check out our resources:

- [Communicating effectively and responsibly through text](/handbook/company/culture/all-remote/)

- [Embracing asynchronous communication](/handbook/company/culture/all-remote/asynchronous/)

- [Embracing asynchronous communication](/handbook/communication/#asynchronous-communication)

**Skills and behavior of applying effective communication as a Team Member**:

---

title: "Asynchronous communication for remote work"

description: "How to communicate asynchronously in a remote work environment."

twitter_image: "/images/opengraph/all-remote.jpg"

twitter_image_alt: "GitLab remote team graphic"

twitter_site: "@gitlab"

twitter_creator: "@gitlab"

---

## How to get started with async

Review the Asynchronous Work section on the Communication page.

### What is asynchronous work?

We love [Preston W.'s](https://twitter.com/PrestonWick) explanation from the [Remote blog](https://remote.com/blog/elements-sustainable-remote-work-culture)

> "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](https://hbr.org/2022/01/11-trends-that-will-shape-work-in-2022-and-beyond) 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](https://about.gitlab.com/blog/2019/12/30/mastering-the-all-remote-environment/) 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](handbook-first/) 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](/handbook/about/handbook-usage/#why-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](/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](/handbook/values/#transparency) 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](/handbook/company/culture/all-remote/).

### When to use asynchronous instead of synchronous communication

While GitLab has [a bias towards asynchronous communication](/handbook/values/#bias-towards-asynchronous-communication), a strategic balance between synchronous and asynchronous is useful for achieving maximum [efficiency](/handbook/values/#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](/handbook/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."

1. "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."

1. "I use sync when I have exhausted async options or async is not leading towards [Results](/handbook/values/#results)."

1. "I use sync meetings to generate creative ideas/proposals with my team that quite frankly would be difficult to do async."

1. "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."

1. "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)."

1. "I enjoy sync to establish an initial human connection when team members have never met before (e.g. coffee/social/team calls)."

1. "If something is very time sensitive, I will opt for a sync meeting with all involved to have a quicker discussion."

1. "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."

1. "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."

1. "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."

1. "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."

1. "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."

1. "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."

1. "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."

### Challenge thinking, not schedules

All-remote settings empower team members to live and work where they're most fulfilled. Implementing [asynchronous workflows](asynchronous/) increases efficiency and decreases dysfunction. Increasingly, operating asynchronously is necessary even in colocated companies which have team members on various floors or offices, especially when multiple time zones are involved. All-remote settings are more inclusive; for example, they provide flexibility to childcare providers who are combining work with parental responsibilities. Async work also removes time zone bias, enabling global team members to be on equal footing.

All-remote settings empower team members to live and work where they're most fulfilled. Implementing [asynchronous workflows](/handbook/communication/#asynchronous-communication) increases efficiency and decreases dysfunction. Increasingly, operating asynchronously is necessary even in colocated companies which have team members on various floors or offices, especially when multiple time zones are involved. All-remote settings are more inclusive; for example, they provide flexibility to childcare providers who are combining work with parental responsibilities. Async work also removes time zone bias, enabling global team members to be on equal footing.

### Delegate

One way to create inclusion among your remote staff is to remove time zone bias via asynchronous communication.

Take initiative to operate [asynchronously](asynchronous/) whenever possible. This shows care and consideration for those who may not be in the same time zone, are traveling outside of their usual time zone, or are [structuring their day](/handbook/company/culture/all-remote/) around pressing personal or local commitments.

Take initiative to operate [asynchronously](/handbook/communication/#asynchronous-communication) whenever possible. This shows care and consideration for those who may not be in the same time zone, are traveling outside of their usual time zone, or are [structuring their day](/handbook/company/culture/all-remote/) around pressing personal or local commitments.

For example, you can record and share team [meetings](meetings/) using GitLab Issues and Merge Requests rather than sending texts, calls, or Slack messages. Be aware of local holidays, personal vacation statuses, and encourage others to default to [documentation](/handbook/marketing/technical-writing/#documentation) rather than pressuring team members to be online outside of their working hours.

![GitLab all-remote team](/images/all-remote/gitlab-com-all-remote-v3-dark-1280x270.png)

{style="max-width:50%;"}

[Asynchronous communication](../asynchronous/) is the process of being productive without depending on the presence of other people. Async work empowers people to work independently and to trust that others are doing the same, but not necessarily at the same time. Collaborating asynchronously frees people from calendars and time zones.

[Asynchronous communication](/handbook/communication/#asynchronous-communication) is the process of being productive without depending on the presence of other people. Async work empowers people to work independently and to trust that others are doing the same, but not necessarily at the same time. Collaborating asynchronously frees people from calendars and time zones.

With documentation, there is transparency on workloads, project capacity, and an overall understanding of what everyone's expectations are. The focus shifts away from the hours spent doing the work, to the actual results of the work.