How to embrace asynchronous communication for remote work

How to get started with async

GitLab believes that all-remote is the future of work. The first step to embracing remote work includes understanding asynchronous (async) workflows and communication and how to make async work for you.

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 major benefits of asynchronous working

1. Asynchronous work provides autonomy, empowerment, and agency

In an asynchronous company, team members are given agency to move projects forward on a schedule that suits them. At GitLab, we measure results, not hours. This means that people are free to achieve results when it best suits them.

If someone is traveling to a new time zone each month, or chooses to spend a beautiful afternoon with family, that’s their prerogative.

Unsurprisingly, providing those who are capable of being managers of one with this type of autonomy leads to extraordinary loyalty, retention, and quality of work.

To further optimize this approach, consider adding a “flexible time off policy”, which means team members do not need to ask permission to step away from work.

All-remote settings empower team members to live and work where they’re most fulfilled. 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.

In this GitLab Unfiltered video, Emna G., founder and CEO at Veamly, speaks with GitLab’s Darren M. about the impact of defaulting to asynchronous as it applies to stress, anxiety, mental health, and overall well-being.

Working asynchronously is more efficient, less stressful, and easier to scale.

2. Asynchronous work increases efficiency and boosts productivity

Working asynchronously is highly efficient because everyone on the team can always default to action .

“There are many times when work isn’t ready for us to tackle, tasks aren’t planned, decision makers aren’t online, etc. In these times, successful teams execute, even if they later have to refactor and adapt, they don’t waste time “waiting”.

‘Always default to action’ is a mantra we keep on repeating at Remote.”

3. Asynchronous work is more inclusive

One of the biggest benefits of asynchronous work is that it completely removes the hurdle of time zones.

“At GitLab, we have people spread across 65 countries, so almost every time zone is covered. But, that also means that someone on your team is likely in a vastly different time zone. In fact, they may be asleep the entire time you’re up working.” - Darren M., GitLab’s Head of Remote

Business happens around the clock, in all time zones, in perpetuity. Attempting to shoehorn communications into a single time zone’s predefined set of hours is dysfunctional.

As a 100% remote company with team members in more than 65 countries, working asynchronously removes time zone barriers and is another way GitLab is a more globally inclusive organization.

4. Asynchronous work alleviates stress and supports mental health

A tremendous amount of stress comes with expectations to be online, available, and responsive during set working hours. Worse, our hyper-connected society has allowed this notion to seep into every hour of the day, destroying boundaries between work and self.

An unsung benefit to working asynchronously is a reduction of tension. When your entire company operates with an understanding that any team member could be offline at any time, for any reason, there is no expectation that one will reply instantly to an inquiry.

This creates an environment where your mental health is prioritized, allowing team members to set boundaries and freeing them from a perpetual assault of notifications and judgment.

When asked how asynchronous communication impacts a societal expectation for an immediate response at all hours of the day, Darren M., GitLab’s Head of Remote, offered the following during an interview with Stuart Miniman, host of theCUBE and GM of Content at SiliconANGLE Media.

Remote is much better for your mental health and sanity than other settings because it forces you to work asynchronously.

An asynchronous mindset enables everyone to take a step back and assume that whatever we’re doing is done with no one else online. It removes the burden of an endless string of messages you must respond to immediately.

From a mental health standpoint, when you have an entire company that embraces async, we all have a little more breathing room to do deep work that requires long periods of uninterrupted time.

Society is nearing a tipping point where people can’t tolerate many more messages, emails, or seemingly urgent pings while trying to do their job well. We may be a bit ahead of the curve on that, but I hope that the industry at large embraces asynchronous communication and allows people more time to do the work they were hired to do.

5. Asynchronous work encourages thoughtfulness and intentionality

A core problem with synchronous communication is the perception of deadlines. When there is an arbitrary start time and end time to a working day, there is pressure to communicate as much as possible between those times, often at the expense of processing time.

Sahil Lavingia, founder/CEO at Gumroad, shares powerful benefits his company realized in going fully asynchronous.

From their X (Twitter) thread:

All communication is thoughtful. Because nothing is urgent (unless the site is down), comments are made after mindful processing and never in real-time. There’s no drama.

Because everyone is always effectively “blocked,” everyone plans ahead. It also means anyone can disappear for an hour, a day, or a week and not feel like they are holding the company back. Even me!

People build their work around their life, not the other way around. This is especially great for new parents, but everyone benefits from being able to structure their days to maximize their happiness and productivity.

This is possible because everything is documented. And because everyone talks through different text-based mediums, it’s easy for people to peer into anything if they’re curious (or take over if need be). There are also no meetings, and all numbers are public, so there’s no workplace FOMO.

The software we ship is well-tested and incredibly stable. It has to be, because we’re never online at the same time to “deploy” together. There are rarely fires to fight, and we lower the amount of technical debt we have at Gumroad every week too!

Overall, it’s a very low stress environment. Many of us don’t even have Slack installed. Yet, we’re shipping the best software we’ve ever shipped, and growing faster than ever. Funny how that works!

6. Asynchronous work bridges the knowledge gap

Asynchronous companies should implement a low-context culture. This means that communication is precise and direct. Team members forecast what questions may be asked about a communique and add in as much context as possible in its delivery. By assuming that the recipient is asleep, or perhaps doesn’t even work at the company yet, this added context removes ambiguity and decreases the likelihood of misinterpretation.

This may feel inefficient, as crafting a message may take longer to compose and edit. However, the long-term benefits are remarkable. At GitLab, we have years of documented decisions — such as this example of availability over velocity — loaded with context. This enables new hires to self-learn as they sift through archives to discover the context that influenced a given decision.

Synchronous organizations often make decisions in a series of meetings, documenting little to nothing along the way, such that those who come into the process mid-stream are constantly wasting cycles on fact-finding missions. Plus, those hired after a significant decision is made cannot understand the context of something that was changed before their arrival, creating cavernous knowledge gaps that eat away at a company’s efficiency.

Coda Hale, principal engineer at MailChimp, articulates this well in a comprehensive article on organizational design entitled Work is Work.

A significant source of failure demand for meetings and status updates is the desire of organizational leaders to keep abreast of who’s doing what. This situational awareness is indeed important, but trying to maintain it by calling meetings, messaging people on Slack, and catching people on the hallways is a significant systemic drag on organizational productivity.

A better model for staying informed of developments as the organization scales is for groups to publish status updates as part of the regular cadence of their work. Leaders can asynchronously read these updates and, should the need arise, initiate additional, synchronous conversation to ask questions, provide feedback, etc.

Synchronous meetings should be reserved for low-latency collaboration on complex issues; likewise, collaboration should be reserved for synchronous meetings. — Coda Hale

As companies scale, people will come and go. By utilizing asynchronous communication, an organization is able to retain knowledge throughout these natural cycles.

For example, the Git blame history of GitLab’s Values page shows a complete list of who made what change, and what the context was for each of them. This insight is invaluable, as some contributors no longer work at GitLab. Those seeking information can find it asynchronously without bothering anyone else, nor do they have to wait for anyone else to wake up or come online.

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.

Why verbalize and write when you could just write?

At GitLab, if you schedule a work-related meeting (e.g. not a coffee chat) it is required that you have an agenda. If you add an agenda item, you are expected to verbalize your agenda item and ensure that you or someone else is taking notes of the response. If writing it down effectively communicates the intent, then consider going completely asynchronous on the topic.

If you are creating double work for yourself or others — holding a meeting simply to document what will need to be written down in order to work handbook-first — it is likely more efficient to not hold a meeting and instead work asynchronously.

When considering meetings, review the GitLab value of Efficiency and following the meeting guidelines in being respectful of others’ time. Do not schedule a coffee chat which is a work-related meeting in disguise.

How to implement asynchronous workflows

Ask, “Do different conversations require different modes of communication?”

The easiest way to take on an asynchronous mindset is to ask this question: “How would I deliver this message, present this work, or move this project forward right now if no one else on my team (or in my company) were awake?”

This removes the temptation to take shortcuts, or to call a meeting to simply gather input. (After all, every meeting should be a review of a concrete proposal, and only called when it will lead to a more efficient outcome than would be possible asynchronously.)

Focus on iteration

Practicing iteration 👣 at GitLab requires intention and effort. It is often referred to as the most difficult value to embrace. Iterating on numerous ongoing projects is an ideal forcing function to ensure a bias toward asynchronous communication.

Asynchronous work can feel taxing and inefficient if you’re only working on a single project and you’re stuck waiting for another person’s contribution. Scheduling your work so you can pick up other tasks while waiting to be unblocked can reduce this downtime.

Now suppose you have five ongoing projects. It’s much easier to make iterative progress on one, tag a person or team within a GitLab epic, issue, or merge request for desired input or action, and switch to another ongoing project while you wait. Suppose you cycle through your assigned tasks, making iterative improvements on each before handing off. In that case, you’re able to create minimal valuable change for many more projects while being less concerned over the immediate response to any one of the projects in particular.

Async works well when managing multiple projects, although it does require discipline and an ability to switch contexts and compartmentalize.

GitLab CEO Sid and the Learning and Development team provide more context on our bias towards asynchronous communication and the importance of our iteration value.

There is a reason we are really good at async, and that is because we make things smaller. Through iteration, you don’t have to coordinate with a ton of people. By taking smaller steps through iteration, we can ship faster. The only way this is possible is through asynchronous communication. — Sid Sijbrandij, GitLab CEO and co-founder

Aim for progress, not perfection

At GitLab, everything is in draft mode and subject to change. Asynchronous workflows are more easily adopted when you foster a culture of progress over perfection. Move a project forward as best you can given the resources available, and if you reach a point where you’re blocked, attempt to ship what you have now through a two-way door.

This allows colleagues to see the direction you’re heading and relieves pressure on them to reply immediately as some progress is better than none.

Celebrate incremental improvements

Asynchronous workflows require a culture where incremental improvements are celebrated equally, if not more, than massive launches. If leadership casts shame on unfinished or unpolished work, workers will be reluctant to work asynchronously. Rather, they will delay work for the sake of consensus. Consensus feels good, but can easily mask inefficiency, progress, and innovation.

Document accurately

Mastering the art of communicating asynchronously has a prerequisite: documentation. At its core, asynchronous communication is documentation. It is delivering a message or series of messages in a way that does not require the recipient(s) to be available — or even awake — at the same time.

If your organization has no standardized method of documentation, establish that first.

Use the right tools

Asynchronous communication works best when there is company-wide alignment on how and where to input communication. Leaders should carefully select their tools, aiming to direct communications to as few channels as possible.

A common frustration in large organizations — regardless of what stage of remote they’re in — is the chaotic splintering of communication. Projects frequently end up strewn across email, chat, text messages, unrecorded meetings, design tools, Google Docs, and more. It’s best to choose a single system for communicating project progress.

At GitLab (the company), that destination is GitLab (the product). Any side conversation that occurs in a meeting is documented in an agenda, and the useful elements are contextualized and ported to relevant GitLab issues and/or merge requests. The same goes for side conversations that happen in Slack or email. Relevant portions are ported over into GitLab (the product), which is the single source of truth for any ongoing work.

If it’s not in a GitLab epic, issue, or merge request, it doesn’t exist. This mentality is essential to reaping the benefits of asynchronous communication.

Here are some tried-and-true apps and cloud tools that facilitate asynchronous collaboration:

• Google Drive
• Dropbox Spaces
• Qatalog
• Yac
• Friday HQ
• GitLab
• Almanac
• Tettra
• Slab
• Twist

Minimize time zone bias

Leaders should strive to eliminate bias toward one time zone, or one swath of time zones (e.g. time zones covering North America). For company all-hands meetings, look to rotate these to accommodate a more diverse array of time zones. Also consider recording them so that others can watch at a later time.

When hosting live learning sessions, for instance, host several instances so people around the globe are able to attend one that suits their schedule.

If a company pulls too hard in the direction of one time zone (oftentimes the zone where most company executives live), it signals to the rest of the company that asynchronous workflows aren’t taken seriously.

Best practices for asynchronous workers

Create mental space

One of the more challenging aspects of remote work is closing out of all mental tabs — to use a web browser analogy — once you leave work. Since remote enables you to work a non-linear workday, it’s difficult to rationalize where one working session ends and another begins. There is often no reason or excuse other than “it’s time.” Dedicated remote workers may struggle with disconnecting from this feeling, deprioritizing their own well-being and falling into the trap of “just one more reply.”

Chat-style communication tools should be used primarily for informal communication. If you are accustomed to Slack being an always-on center of urgency in a prior organization, breaking your reliance on it as a core part of accomplishing tasks will require deliberate effort and reinforcement.

Below are recommended forcing functions to keep leaders and individual contributors alike from being consumed by instant messages and a bias for synchronicity. The goal is to place the power of prioritization back into one’s own hands. This is critical to being an effective manager of one.

Clear all messages daily/weekly

Humans were not designed to receive an unchecked quantity of new data in perpetuity. For many, it would be a full-time job to simply read and comprehend a daily or weekly digest of new Slack messages, private and public. While an individual’s approach to filtering what is vital and is not will differ by role and function, you can reduce your mental load by clearing all messages at the end of each working day or week.

Slack refers to this as Mark all messages as read, which is easily toggled by simultaneously pressing Shift + Esc.

Communicate your work preferences

Create a rudimentary README that clarifies how you work. Ideally, it’s working from a GitLab Issue board, tagging system, or To-Do list which can be understood and used company-wide. You can then post the link to your README in your Slack profile, pointing others to it. Showing others how to deliberately choose asynchronous over synchronous is vital to reinforcing our operating principle of Bias towards asynchronous communication.

This is an extension of another remote-first forcing function: Always answer with a link.

Communicating your async work days

GitLab embraces asynchronous work and non-linear workdays broadly, but there may be times when you’re working outside your normal work hours (e.g. while traveling before/after a trip, working during a trip, working a weekend, etc.) and want to communicate that to team members. In these situations, team members should add a Focus Time calendar event and change their Slack status rather than entering time off in Workday.

Remove Slack from your phone

Remote workers lack many of the physical gateways that serve as dividers between work and life. When work and life happen in the same building, and one’s work equipment is always within reach, it’s far too easy to allow unread Slack messages to haunt you.

Being intentional about removing Slack from one’s phone is a great way to reinforce that time away from work is important. A litany of studies have covered the addictive impact of smartphones. Even if you aren’t sure if this approach will benefit you, give it a try. It’s a two-way door.

Be transparent on capacity

In a colocated setting, a worker can pick up context clues by seeing someone storm away, sigh loudly, or intentionally put on a pair of noise-cancelling headphones to prevent interruptions. In a remote setting, it’s not as simple to let people know you need uninterrupted focus.

Thus, it’s important to leverage Slack statuses to broadcast information on your capacity to your team. You should feel safe to manually adjust your status to indicate when you are at capacity or engaged in focus time. This reinforces that others can and should consider doing likewise, while also reminding others that Slack and synchronous conversation should not be the default.

Remind people that async is more inclusive

While GitLab’s approach to self-service and self-learning is reinforced during onboarding, continual reinforcement may be necessary. It is acceptable to ask someone if they are exercising a bias towards asynchronous communication, regardless of their position on the org chart.

Just as we would hope that all GitLab team members would be quick to ask if something is inclusive, it’s important to remember that asynchronous communications is another way for GitLab to be more inclusive.

There is as much to unlearn as there is to learn.

Use accurate terms and identifiers

It is important to use accurate names when referring to people. To do so, use the @ symbol in GitLab Issues/Merge requests, Google documents, and Slack to clarify to whom you are referring. This avoids accidentally misspelling someone’s name or referring to the wrong person.

Examples:

• Names that may be difficult to spell. E.g.: Hubert Wolfeschlegelsteinhausenbergerdorff
• Names that could refer to multiple people. E.g.: There are multiple GitLab team members with the name Tatiana.

How to manage asynchronous meetings

At GitLab, we have a bias towards asynchronous communication. As a meeting participant, whether you are scheduling or an invitee, question every work-related meeting.

1. What is the outcome I am trying to achieve that has led to my desire to schedule a meeting?
2. Can the desired outcome be broken down into smaller tasks?
3. Can the desired outcome be achieved or worked towards by dogfooding and using a GitLab issue or merge request?
4. Am I trying to gather consensus? (If so, this can be done asynchronously.)
5. Am I trying to make a decision after consensus is gathered and there is a proposal to react to? (If so, a meeting may be acceptable if it cannot be agreed upon asynchronously, but remember that outcomes must still be documented in the handbook. If your outcome(s) will be documented in the end, it calls into question the efficiency of a synchronous meeting.)

When to start synchronously

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 kickoff may make sense for the following. (Thanks to the team at Dropbox for articulating this well in its remote communications guide.)

1. A sales engagement
2. First-time meetings with external parties
3. First-time meetings with GitLab team members who have not previously worked together
4. One-way door decisions (e.g. when stakes are high and decisions are difficult to reverse)
5. Complex initializations (e.g. defining a corporate narrative, a major overhaul to scope, etc.)
6. Emotionally sensitive topics (e.g. discussing personal issues, career path/promotion, difficult feedback, etc.)
7. Supporting and unblocking your direct reports (e.g. a regular 1:1)
8. Celebrations and retrospectives (it feels good to celebrate wins with a group, and lightweight retrospectives can serve as kickoff points for future sprints)

When to start asynchronously

Suggesting to “hop on a quick videocall” may feel insignificant, but it can have a negative impact on productivity. Generally, it’s best to avoid a meeting for the following items.

1. Status updates
2. FYIs and process documentation
3. Meeting about a meeting

For an example of starting async first in a highly complex scenario: View Vision Statement: gitlab.tv (Vision Statement: gitlab.tv). In this scenario, the project began asynchronously, as the initiator needed to convey a complex series of assumptions and examples in order to provide enough context for team members to contribute feedback.

1. Due to the large volume of information, the creator of the Epic added a series of Highlights at the top, an indication of being respectful of others’ time.
2. The creator time-boxed feedback, providing a specific window of time that asynchronous input would be accepted.
3. The creator transparently notified the group that a focused synchronous meeting would follow in order to make a decision on the asynchronous feedback and proposals.

When to pivot from asynchronous to synchronous

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 or leverage a richer communication medium such as Yac or Loom.

These tools allow messages to be conveyed asynchronously, though the use of audio and video as the medium may enable deeper connections to be made compared to raw text transmissions.

Following pivots to synchronous calls, there should be a written summary created to inform others of the outcome, ideally shared in a relevant GitLab epic, issue, or merge request.

Best practices for asynchronous meetings

In this GitLab Unfiltered video, two GitLab colleagues discuss lessons learned from managing a team asynchronously, across many time zones, while traveling.

Focus on the positives

Working asynchronously allows teams to have fewer meetings. Initially, the notion of “optional meetings” may seem absurd to those who are accustomed to synchronous communication. The truth is that you’re either at a meeting to contribute, or you aren’t.

The beauty of asynchronous is that team members can contribute to meetings that occur while they sleep.

Meeting attendance becomes optional when each team member has access to an agenda and a Google Doc, which should be attached to each invite. This allows people anywhere in the world to contribute questions/input asynchronously in advance, and catch up on documented outcomes at a later time.

The person who called the meeting is responsible for contextualizing the outcomes and porting relevant snippets to relevant GitLab issues and/or merge requests.

The organizer is responsible for informing the entire company, via post-meeting documentation, of the outcomes should team members go searching. That’s a big responsibility, which keeps the quantity of meetings in check and acts as a filter for whether or not a meeting is truly necessary.

Set KPI targets to track improvements due to asynchronous work

Team needs are as unique as their objectives and will experience asynchronous communication differently. However, team leaders and managers can set KPI targets based on one or all of the following:

1. Percent reduction of minutes spent in synchronous meetings
2. Percent increase in GitLab issue/epic/merge request usage
3. Improved ratio of meeting minutes-to-GitLab contributions
4. Increase in 360 feedback citing ‘bias towards asynchronous communication’ in the Diversity, Inclusion & Belonging field

How to have an async 1:1 meeting

Async 1:1 meetings are an excellent way to broaden the communication skills of a manager and a direct report. While face-to-face or walk-and-talk 1:1s are beneficial, the ability to cover 1:1 agenda items asynchronously using written text bolsters one’s overall remote competency.

To conduct an async 1:1, be sure to

1. Communicate to the other party that you would prefer the next 1:1 to be async to ensure mutual understanding of the format.
2. During the week of the async 1:1, consider the entire working week fair game to make comments in an ongoing agenda document. Tag the other party with FYI or FYA commands and provide written or embedded video context, understanding that their feedback or input will not happen in real-time.
3. Consider leaving the original 1:1 calendar block on your schedule. If you are not able to look at the agenda document before that block, this ensures dedicated focus time to respond to agenda items or add new ones.
4. For any agenda items which could not be addressed during the week of the async 1:1, move those to the following instance and resume face-to-face or walk-and-talk.

Retrospectives on meetings

For existing and upcoming meetings, add this question at the top or bottom of the agenda and document the answer: Could this meeting have been handled asynchronously, and if so, how?

Consider sharing these learnings in a public channel to create additional awareness of what’s possible through asynchronous workflows. Take time to reflect on which meetings you’ve attended or scheduled in recent weeks. Which were a valuable use of time and which could have been handled asynchronously?

There are many tasks which can be handled synchronously and asynchronously. The goal is to always select asynchronous where feasible, creating more focus time in your day. This also creates a higher likelihood that team members will have more energy for synchronous connections that bolster work relationships. Informal communication is vital in an all-remote setting; by being ruthless in one’s bias towards asynchronous work, it creates more space for synchronous team bonding. We each have a finite amount of tolerance for work-related meetings and video calls; synchronous moments are better saved for informal communication such as coffee chats and team trivia where feasible.

Limitations and challenges of asynchronous communications

Asynchronous communication has its limits. Although projects are moved forward asynchronously at GitLab, there are times when portions of the project are best handled synchronously.

Evaluating efficiency

As a rule, when team members at GitLab go back and forth three times, we look to jump on a synchronous video call (and document outcomes).

Client-facing roles

Certain roles are more tolerant of asynchronous communication than others. Client-facing roles, for instance, may have certain requirements for coverage during certain hours. It’s possible to layer async work atop these demands by ensuring that there is no single point of failure, such that a team within an asynchronous organization can self-organize and decide who covers given time slots.

Time zones

While communicating asynchronously is an excellent way to reduce the pain of having team members spread across an array of time zones, managing this as a small team is particularly challenging. For example, a small team which is primarily based in North America may struggle to communicate well with the first team member who joins from Singapore given the time zone difference.

However, as a team scales and more coverage is added in time zones in between, it’s easier to hand work off as the world turns. In many ways, managing time zones becomes easier with scale, as the delta between teams is reduced.

Interviewing external candidates

All of GitLab’s interview processes involve some form of synchronous communication. Some of our teams utilize asynchronous practices during the interview process, however, this is not a standard approach across every interview process.

Working async outside of your company

Even if you have established asynchronous work within your team, it can be challenging or uncomfortable to encourage async practices when working with people outside of your company.

Every organization has their own norms, but you can politely challenge the status quo by seeking to inform and educate. Here’s how to approach working async with external parties:

1. Start synchronously: Have a sync call to kick off a project or partnership. During that call, mention that you’d like to incorporate some asynchronous work into the project moving forward. If you use this call to build relationships and rapport, your async work will be more efficient.
2. Set expectations and model behavior: Discuss up front how you will work async together (what tools you’ll use, what to document, and how often). Agree on a cadence for any future syncs so that everyone knows what to expect. Be sure that you model this behavior throughout the project or partnership.
3. Share async documentation: Send your handbook page or documentation about async to people you’re working with externally. This way, anyone unfamiliar with working this way can refer to the page and share it with others.

Some organizations may not be open to working asynchronously, so it’s important to remain flexible, particularly in a client-facing role. However, imagine how much time could be saved if more companies had a bias for async?

Async at GitLab

Asynchronous communication is a significant differentiator in a world where businesses are increasingly remote. GitLab’s seeks to more clearly define and operationalize asynchronous communication.

Over time, GitLab, the company, has iterated on its asynchronous culture:

1. Iteration 1: GitLab operated largely async through shared observed behaviors as a small team
2. Iteration 2: we began to build a playbook and define when synchronous and asynchronous was appropriate
3. Iteration 3: we have defined best practices and intentional operations.

We believe this will:

1. Help GitLab maintain its leadership in remote work.
2. Reduce ambiguity in communication modes and reinforce handbook-first.
3. Allow for added flexibility in the day-to-day lives of GitLab team members.
4. Support our long-term vision for global remote work.

Examples of asynchronous integration on GitLab teams

Activity	Async Communication
Weekly announcements	Engineering Management creates a weekly announcement video and slides to be viewed async, at a time convenient for each team member.
New team member introduction	New team member creates a 2-minute video introduction, introducing themselves to the team which can be shared in meetings / Slack channels
Backlog refinement / planning poker	Team collaborates via a GitLab issue (or Epic, or merge request, if more relevant), tagging the appropriate parties with specific requests. If the volume of information is above 1,000 words, ensure that a Highlights section is at the top.
Capacity planning	Team updates a shared Google Sheet monthly.
Team members who are unable to attend sync meetings	Meeting organizers should affix a Google Doc agenda to each meeting invite prior to sending. Team members invited to the meeting should update the meeting agenda and questions async, or pre-record a video with information to be shared (linking the video in the agenda).
Quarterly team results recaps and celebrations	Corporate Marketing (#corp-mktg) creates a Google Doc or Slides for team members to add results async, then shares the resulting celebration video (with those could attend sync) on GitLab Unfiltered.
Monthly finance accruals	DRIs (Directly Responsible Individuals) in respective departments set a monthly personal reminder to update ongoing Google Sheets with the latest financial accruals, tagging their finance partner(s) in the doc if there are questions.
Project sprints and milestones	Inbound Marketing (#inbound-mktg) uses the Geekbot Slack app to poll team members with the following questions: 1) Which project are you currently focusing on? 2) What went live/was completed since Tuesday? 3) What is this week’s top 3 priorities? 4) Do you need help with anything that may slip?
Broadening coverage during PTO	Team members may assign a Channel instead of a Co-worker to cover for them when planning paid time off using Time Off by Deel.
Preparing for meetings or interviews	GitLab’s PR teams (#external-comms) prepare speakers async by sharing a Google Doc in advance with background on the topic, key messages to convey, relevant handbook and media links, meeting time and join links, session logistics, etc.
Editing communiques and content	GitLab’s Content (#content), Events (#events), and Corporate Marketing (#corp-mktg) teams routinely edit panel questions, session titles, company announcements, and pitches via Google Doc. Async feedback is given using the Suggesting feature in Google Docs and accurately tagging individuals with the Comments function.
Weekly team kickoff/standup sessions	Corporate Marketing (#corp-mktg) uses the Geekbot Slack app to conduct weekly async standups with the following questions: 1) How do you feel today? Red/Yellow/Green 2) What did you do this weekend? 3) What are your priorities this week? 4) Anything blocking your progress? 5) Any upcoming paid time off (PTO)?
Missed deliverable retrospective	Engineering Package Group utilizes async deliverable retrospectives through GitLab issues labeled ~"group::package"
Blocked calendars and non-linear workdays	You are encouraged to block your work calendar to ensure that family and friends come first. This comes in many forms, from blocks to engage in fitness or meditation, to caregiving, to picking one’s child up from school. These blocks force a non-linear workday, which reinforces that you may not be immediately available during these blocked times, and team members should engage with you asynchronously.
Alternate times for recurring scheduled meetings	Synchronous meetings should be inclusive of those who want to attend and are in different time zones. For example, a team’s recurring weekly meetings, alternate between a time which is ideal for EMEA and Eastern AMER (8:00AM Pacific) and a time ideal for APAC and Western AMER (3:00PM Pacific).
Async communication with those who are not GitLab team members	It may be challenging to coordinate and communicate asynchronously with customers, business partners, community contributors, etc. who default to synchronous communication. To convey GitLab’s async practices, share our All-Remote Asynchronous Guide in advance, and consider affixing it to calendar invites and agenda docs as well. It’s important to be flexible, and educate others on the benefits of and processes for effective asynchronous communication.
Asynchronous engineering standup meetings	Standup meetings are commonly used by engineering teams to keep all team members appraised of what they were working on recently, what they plan to work on next, and if they need help on anything. Since GitLab operates primarily async, we use Slack channels and bots like GeekBot to communicate this in an async fashion.

All are welcome to make a merge request to this page and add more examples of async integration.

Core behaviors/communications that should be async and structured

1. If you’re seeking to collaborate or brainstorm via whiteboard, study how GitLab uses Google Docs as a remote whiteboard.
2. Proposals and thought-starters should be written down, so that feedback and consensus can be gathered quickly asynchronously by a wide group of people.
3. If you’re asking for help or feedback from another team member(s), you should be willing to document the request in a GitLab epic, issue, or merge request with the appropriate context.

How to decline meetings in favor of async

Meetings are useful for building rapport and moving projects forward. They are also extremely costly and disruptive to flow. It’s a shared responsibility to think twice before scheduling a meeting, as well as politely questioning meeting invitations.

Suggesting an asynchronous workflow over a meeting can feel uncomfortable. We want to ensure that all GitLab 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 GitLab team members back to this handbook section.

Below are a few sample regrets, borrowed from an excellent remote communications guide assembled by Dropbox.

1. “Thanks for including me! I’m wondering if we could try to solve this using a GitLab issue or merge request instead so our thoughts and progress is documented?”
2. “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?”
3. “I’d be happy to give you feedback on that! Before we schedule a meeting, could I review it in a GitLab issue/merge request, or shared doc?”

If the team decides to go ahead with a meeting you can’t make, consider assigning a delegate to represent you and contributing feedback/questions in advance in the agenda that should be attached to the calendar invite.

Best practices, guidelines, and async feature set

Asynchronous working is a feature set that supports and streamlines the variety of communication approaches, emphasizing comprehension and consideration, rather than prescribing a one-size-fits-all approach.

Teams should embrace a self-service mentality, single source of truth (SSoT) to fully understand the capabilities of asynchronous workflows, how GitLab (the product) facilitates asynchronous communication, and how to leverage existing tools (e.g. Google Docs) in an asynchronous manner.

GitLab team members may question meetings, suggesting an asynchronous alternative (e.g. discussing in a GitLab epic, issue, or merge request) to cover the topic of the meeting.

1. Conduct an asynchronous pilot. This could mean attending half of your weekly meetings async for a week and conducting a retrospective on the differences between sync attendance and async attendance.
2. Conduct a non-linear workday pilot. Consider shifting your schedule to better suit your peak productivity hours, caregiving hours, or experiment with alternative work schedules that would not be supported in rigidly synchronous organizations.
3. For any given piece of work, seek to optimize the mix of synchronous and asynchronous engagements for maximum efficiency and potential for iteration.
4. Team members have varying learning and communication style preferences (e.g. neurodiversity) that make audio discussion much more effective than written. Thoughtfully timed synchronous discussions ensure that everyone can contribute.
5. Every meeting should be a review of a concrete proposal or to catalyze a future series of asynchronous events, and only called when it will lead to a more efficient outcome than would be possible asynchronously.
6. An initial team-building sync at the start of a project or milestone can unlock a highly efficient follow-on series of asynchronous events. Be mindful to structure these initial syncs intentionally to build rapport and trust. The goal of gathering the group in a shared space should be unambiguous: it serves to equip team members with the context they need to switch primarily to asynchronous afterwards. Note that even these intentionally structured kickoff calls may not be inclusive of all time zones. Thus, it is important to adhere to GitLab’s meeting guidelines, affixing a Google Doc agenda to the calendar invite, encouraging all parties to contribute textually if they cannot attend in person, and recording the full session for future viewing.
7. Do not use @-handles unless you are requesting a specific written action or piece of feedback from the person and you provide the proposal and context necessary for them to execute.
8. If a GitLab epic, issue, or merge request is over 1,000 words, a summary is required at the top of the issue/merge request for efficient absorption of key points.
9. Brainstorming or incubating ideas synchronously shouldn’t be outright discouraged, though team members should be mindful to document takeaways as quickly as possible to prevent knowledge decay and to be inclusive of feedback from a wider group than those in the synchronous brainstorm session. Consider two songwriters who discover a spark for a new jingle, destined for glory in the GitLab Songbook. They may record a voice memo to capture the essence of the idea, then share that more broadly to refine and iterate on the song. A similar approach can be taken by documenting sparks in a GitLab merge request or issue, then shared in relevant Slack channels for added feedback.

Async survey data

GitLab team members were polled on 2020-09-02 in the public #company-fyi Slack channel, with polling open through 2020-10-02. Roughly 20% of team members responded to the poll, with answers and percentage of replies outlined below.

Team members were asked: Why would you choose synchronous communication over asynchronous for work-related (e.g. not informal communication) discussions?

• I was unaware of GitLab’s operating principle ‘Bias towards asynchronous communication’ - 1%
• I prefer verbal communication over written communication - 3%
• I believe the subject matter is confidential - 10%
• Someone else on my team can join and document the takeaways from a synchronous meeting - 1%
• I find it difficult to get others’ attention via asynchronous communication - 12%
• It’s useful to build rapport and catalyze future async conversations - 38%
• I don’t feel that I have the tools, support, and/or training to rely on asynchronous in my role - 0%
• It takes more time to set up an async communication for success that it does to schedule/conduct a meeting - 6%
• I find it hard to brainstorm or gather information when I operate async - 19%
• Other - 10%

Key learnings

Responses are open to interpretation, though the data provide key insights that GitLab leaders may use to better understand the dynamics of their teams and iterate on solutions.

1. While only 1% noted that they were unaware of an operating principle related to asynchronous communication, leaders should not assume that all operating principles are acknowledged and well-understood. Reinforce and discuss values in 1:1 meetings and day-to-day workflows.
2. GitLab is public by default. If you believe a matter is confidential, check this in the Not Public section of the Communication handbook.
3. If you find it difficult to get someone’s attention via asynchronous means, consider leveraging a synchronous engagement to discuss potential gaps in expectations. While GitLab is articulate about where work happens, some team members work exclusively from GitLab’s To-Do List or Scoped Labels and have varying approaches to prioritization (see Brand and Digital Design’s Working With Us handbook for an example). Assume positive intent, as delays in response may be attributable to putting family and friends first.
4. The majority of respondents indicated that they leverage synchronous engagements to build rapport and catalyze future async conversations. Having a meeting not because it’s easy, but because it will create future efficiencies and cohesion, is a positive outcome.
5. It is encouraging that GitLab team members feel that they have the tools, support, and training to rely on asynchronous workflows. However, leaders should be mindful of new tools and practices that GitLab can pilot and surface these in the public #values Slack channel. Iteration also applies to our approach to asynchronous communication.

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.”

GitLab Knowledge Assessment: Embracing Asynchronous Communication

Complete all knowledge assessments in the Remote Work Foundation course . If you have questions, please reach out to our Learning & Development team at learning@gitlab.com.

GitLab is one of the world’s largest all-remote companies. We are 100% remote, with no company-owned offices anywhere on the planet. We have team members in more than 65 countries.

Just as it is valid to ask if GitLab’s product is any good, we want to be transparent about our expertise in the field of remote work.

Contribute your lessons

GitLab believes that all-remote is the future of work, and remote companies have a shared responsibility to show the way for other organizations who are embracing it. If you or your company has an experience that would benefit the greater world, consider creating a merge request and adding a contribution to this page.

---

Return to the main all-remote page.