Introduction

In a world dictated by calendars and schedules, people are conditioned to operate in synchronicity — a manner in which two or more parties exert effort to be in the same place (either physically or virtually) at the same time. Asynchronous communication is the art of communicating and moving projects forward without the need for additional stakeholders to be available at the same time your communique is sent. It also gives people a chance to express their opinions in the way that is best suited for them.

In a distributed work setting, where team members are empowered to live and work where they’re most fulfilled, mastering asynchronous workflows is vital to avoiding dysfunction and enjoying outsized efficiencies. 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. A distributed setting is proven to be more inclusive as it provides flexibility to child care providers to combine their work with their parental responsibilities. It also enables team members to be on equal footing as other team members globally. Asynchronous work does not replace or invalidate synchronous, realtime teamwork, mentoring and collaboration with your colleagues. Rather, it is a set of techniques to focus and maximize the return we get on those efforts.

Asynchronous Work in Roivant IT

Asynchronous communication is a significant differentiator in a world where businesses are increasingly remote. Roivant IT’s work techniques seek to more clearly define and operationalize asynchronous communication. Our developing techniques for distributed, asynchronous work can be considered “Asynchronous 1.0”. With varying challenges, from COVID-19 to a growing and widening business, Roivant IT strives to be at the forefront of highly effective methodologies that address our changing global work landscape.

When to use asynchronous and synchronous communication

Working asynchronously may seem contradictory to our cultural norms of pairing, retrospectives, standups and other synchronous realtime “ceremonies”, but what it really means is that we must use these sessions judiciously and we should never stall progress when our schedules do not align, unless it’s absolutely necessary.

Our synchronous techniques are effective, borne from experience and high-yield, but they are also expensive in terms of time and attention. Finding a balance of using the best of both sync and async should always be a goal. The strategic balance between synchronous and asynchronous work 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 Roivant, but not an absolute — especially if at the expense of our values.

Examples of asynchronous integration In Roivant IT

Activity	Async Communication
Capacity planning	Team updates a Confluence space monthly.
Team members who are unable to attend sync meetings	Meeting organizers should affix a O365 Word Document link, which includes an 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).
Broadening coverage during PTO	Team members may assign a Channel instead of a Co-worker to cover for them when planning PTO.
Blocked calendars and respect for personal time	You are encouraged to block your work calendar to ensure that family and friends come first.
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 EST (8:00AM Pacific) and a time ideal for APAC and PST (3:00PM Pacific).
Asynchronous engineering standup meetings	Standup meetings are commonly used by 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 Roivant encourages asynchronous work, consider using 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 using Miro as a remote whiteboard which can be as power asynchronously as it is realtime.

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 Jira story, service ticket or other mechanism, with the appropriate and suffiicient context that your colleague can answer you asynchronously.

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 Roivant IT 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 colleagues 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 Jira story, Freshservice ticket 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 Jira story, issue ticket, 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

Roivant IT Async 1.0 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 our existing tools (Jira, Freshservice, Miro, O365) enable teams to work in an asynchronous manner.

1. Roivant IT team members may question meetings, suggesting an asynchronous alternative (e.g. discussing in a ticket, story or Miro board) to cover the topic of the meeting.

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

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 Roivant IT’s meeting practices, affixing a Word Doc (online only, no attachments) agenda to the calendar invite, encourging all parties to contribute textually if they cannot attend in person, and recording the full session for future viewing.

7. If a Jira story, Freshservice ticket, or git merge request is over 1,000 words (honestly, don’t do this), a summary is required at the top of the issue/merge request for efficient absorption of key points.

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

When to start asynchronous first

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. FYI’s and process documentation

3. Meeting about a meeting

When to pivot 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

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, there should be a written summary created to inform others of the outcome, ideally shared in a relevant Jira epic, story, or in a service ticket.

When to start synchronous first

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

1. Product scoping or discovery

2. First-time meetings with external parties

3. First-time meetings with Roivant IT 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)

How to implement asynchronous workflows

The easiest way to enter into 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 include a concrete proposal, and only called when it will lead to a more efficient outcome than would be possible asynchronously.)

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. — Preston W. on the Remote blog

Focus on iteration

Practicing iteration in Roivant IT 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. If you’re only working on a single project, asynchronous can feel taxing and inefficient, as you’re perpetually waiting for another party to unblock you. This creates idle time and makes synchronicity seem alluring. Scheduling your work such that you can pick up other items while waiting to be unblocked can reduce this down time. If you’re working on five ongoing projects, for example, it’s much easier to make iterative progress on one, tag a person or team within a Jira epic, issue, or merge request for desired input or action, and switch to another ongoing project while you wait. If you cycle through your assigned projects, making iterative improvements on each before handing off, you’re able to create minimum viable change for many more projects, while being less concerned over the immediate response to any one of the projects in particular.

Asynchronous works well when you manage multiple concurrent projects, though this does require discipline and an ability to context switch and compartmentalize. As such, we try to keep WIP to a minimum to encourage focus, but working asynchronously helps with our inflow of unplanned operational work such as service tickets.

Aim for progress, not perfection

In Roivant IT, everything is in draft 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 teammates to clearly 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 optimize for delaying work until a satisfactory amount of consensus gathering can occur. Consensus feels good, but can easily mask inefficiency, progress, and innovation.

Documentation as a prerequisite

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. Otherwise, team members will be left to determine their own methods for communicating asynchronously, creating a cacophony of textual noise which is poorly organized and difficult to query against.

Utilize the right tools

Asynchronous communication works best when there is companywide 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, etc. While there are a litany of unified communication tools available which attempt to wrangle all of that, you’re best served by choosing a single system for communicating project progress.

In Roivant IT, we make a distinction between planned and unplanned work. Planned work is any intentional, scoped and prioritized project. The destination for planned work is Jira. Any side conversation that occurs in a meeting is documented in an agenda, and the useful elements are contextualized and ported to relevant Jira epics or stories. The same goes for side conversations that happen in Slack or email. Relevant portions are ported over into Jira, which is the single source of truth for any ongoing project work.

Remove bias toward one time zone

Leaders should strive to remove 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.

Reducing reliance on Slack and synchronicity

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 work by nature has few physical boundarie, it’s difficult to rationalize where one working session ends and another begins. There is oftentimes no reason or excuse other than “it’s time.” Dedicated remote workers may struggle with disconnecting from this feeling, deprioritizing their own wellbeing and falling into the trap of “just one more reply.”

Below are recommended forcing functions to keep leaders and individual contributors alike from being consumed by Slack 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 Jira board, ticketing 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 chose asynchronous over synchronous is vital to reinforcing our sub-value of Bias towards asynchronous communication. This is an extension of another remote-first forcing function: Always answer with a link.

Transparency 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. Remote colleagues are oftentimes unable to demonstrate similar indicators. Thus, it’s important to leverage Slack statuses to broadcast information on your capacity to your team. Many at Roivant utilize the O365-Slack integration, which automatically showcases a calendar icon within Slack while you’re in a meeting. Consider configuring Slack for your working hours. 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 a dependency to making progress.

Question every meeting

In Roivant IT, 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. Am I trying to gather consensus? (If so, this can be done asynchronously.)

4. 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.)

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 an org-wide 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?

Why verbalize and write when you could just write?

At Roivant, if you schedule a work-related meeting 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 Roivant IT value of Efficiency and following the meeting guidelines in being respectful of others’ time. Do not schedule a social chat which is a work-related meeting in disguise.

Asynchronous meeting participation

Have as few mandated meetings as possible. The notion of “optional meetings” is absurd to those who only think in terms of synchronous communication — 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 one has an agenda and an online Word Doc 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 Jira stories and/or service tickets. By placing this burden on the meeting organizer, it acts as a filter for whether or not a meeting is truly necessary. The organizer is responsible for informing the entire organization, 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.

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 compentency. To conduct an async 1:1, consider the following steps:

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.

Working async outside IT

Even if you have established asynchronous work within your own team, it can be challenging and sometimes 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 still may not be open to working asynchronously, so it’s important to remain flexible. However, imagine how much time could be saved if more companies had a bias for async?

Benefits of asynchronous workflows

Working asynchronously is more efficient, less stressful, and more amenable to scale. The benefits for both employee and employer are numerous, and we’ve highlighted a few below.

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

Everything is thoughtful

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 an irrational pressure to communicate as much as possible between those times, oftentimes at the expense of processing time. This is also entirely incongruent with today’s business world. There is no actual start time and end time. Business occurs around the clock, in all time zones, in perpetuity. Attempting to shoehorn communications into a predefined set of hours without a documented need leads to dysfunction and misinterpretation.

Sahil Lavingia, founder and CEO at Gumroad, shares a series of powerful benefits his company realized in going fully asynchronous.

Going fully remote was nice, but the real benefit was in going fully asynchronous. Here are a list of the benefits we’ve seen at @Gumroad:

A thread 👇🏽

— Sahil Lavingia (@shl) January 29, 2020

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 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!

Autonomy, empowerment, and agency

In an asynchronous company, team members are given agency to move projects forward on a schedule that suits them. In Roivant IT, we measure results, not hours. This means that people are free to achieve results when it best suits them. 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 “no ask, must tell” time off policy, which means team members do not need to ask permission to step away from work, but with an expection that they will keep their teammates and managers fully informed about their availability.

Plugging the knowledge leak

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 communiques may take longer to compose and edit. However, the long-term benefits are remarkable.

An organization should endeavor to produce documented decisions, loaded with context. This enables new hires to sift through archives and understand the context of the moment, and what went into 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 who are hired after a significant decision is made have no way of understanding the context that went into something prior to 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 Roivant IT’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 may eventually no longer work at Roivant. Too, those seeking information on this are able to find it asynchronously — they do not have to bother anyone else, nor do they have to wait for anyone else to wake up or come online.

Limitations and challenges

Asynchronous communication has its limits. Although projects can be moved forward asynchronously, with decisions documented along the way in documents, stories and ticket, there are times when portions of the project are best handled synchronously.

Evaluating efficiency

As a rule, when team members at Roivant 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 tolerable of asynchronous than others. Operational on-call roles, for instance, may have certain requirements for coverage during certain hours. It’s possible to layer asynchronous 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.