Why you should work asynchronously

TL;DR: Asynchronous work allows for remote work that’s enjoyable and that actually works. Async increases inclusivity, produces better outcomes faster, encourages discoverability and permanence of context, creates space for learning, shifts knowledge workers to higher value work, improves work-life balance, empowers distributed teams, and enables parallelization and flow.

5 minute read

Most corporations (and their employees) made the shift to remote work during the pandemic. Many of these shifts were to remote-capable workflows (moving offline workflows online), but they never made the maturity leap to fully remote-first, rendering their employees less productive and more likely to burn out. The difference between being able to work remotely and being able to thrive remotely is the ability to work not just digitally, but also to work asynchronously, and it brings with it a number of benefits not possible under legacy workflows.

Evolving beyond Cold War workflows

Most corporate workflows have not evolved significantly from their cold war predecessors. Sure, we’ve replaced typewriters with laptops, inter-office mail with email (or Slack), and in-person meetings with Zoom, but if you diagram out how people work and how information flows, not much has changed over the past seventy or so years beyond the cadence. We’ve digitized paper-based workflows, but we haven’t reimagined them for the modern (and distributed) world.

Working asynchronously

Asynchronous work is knowledge workers’¹ natural evolution beyond the assembly-line-inspired, ad-hoc, and bespoke workflows that continue to influence most companies today. Specifically, working asynchronously is defined as:

not requiring people to be in a certain place at a certain time, or working on a certain thing at a certain time,
allowing individuals to be productive without waiting for others to respond or complete a task,
reducing batch size so that work can progress faster than its slowest component,
minimizing unplanned interruptions and demands for immediate attention,
decoupling work from communication,² and ultimately
granting workers the trust to work autonomously in the pursuit of shared goals.

Benefits of working asynchronously

Async work is a forcing function that not only replicates the outcomes of synchronous work,³ but makes it more productive and more enjoyable than working in person. Specifically:

Inclusivity - When done right, async work is timezone agnostic. It also reduces proximity bias and access to information imbalance. There’s no “you had to be there”, when “there”, is “online” and “anytime”. Additionally, async means that all voices, not just the loudest, fastest to unmute, or most extroverted, are able to contribute to the conversation.
Produces better outcomes faster - Async encourages higher-quality communication and planning by forcing a shift to better (even if perceived to be slower), more deliberate decision-making. It reduces ambiguity, imprecision, and churn through distillation of ideas and intentions that over time, will allow teams to ship the best ideas faster.⁴
Discoverability and permanence - By capturing and linking decisions, process, and artifacts, async naturally places a heavy reliance on written communications, documentation, discoverability, permanence, openness, self-documentation, succinctness, and transparency. This unlocks a number of benefits.
Create space for learning - Most of us don’t learn at the speed of synchronous human interaction. In addition to allowing for passive observation and lightweight participation, async creates the necessary space for reflection, processing, and ultimately learning. This is true of both the business or technical problem at hand and the organizational culture and values that it socializes through its operation.
Shift to higher-value work - By not requiring knowledge workers (especially managers) to spend countless cycles shuttling information around the organization, async shifts workers from low value work to higher value work, allowing them to solve novel, more interesting, and if you believe creative minds want to be creative, ultimately more enjoyable problems. As a result, the shift to async simultaneously increases both productivity and overall job satisfaction.
Work-life balance - When work becomes largely time-agnostic, it allows for greater flexibility and work-life balance. Work is measured on its impact, not time in seat, meaning employees can schedule their working hours around child care, personal commitments,⁵ and when they personally work best.
Distributed teams - Async allows distributed teams to thrive, meaning your team can tap into the world’s top talent, expand your business globally, and enable “follow the sun” work by spanning across timezones. This is especially beneficial for on-call roles like incident response or SRE that can be on call during their local working hours and for customer-facing roles like support, sales, and marketing that specialize in the regions where they are located.
Parallelization and flow - Async necessitates adopting non-blocking workflows that allow for parallelization of work⁶ and ultimately encourage flow.⁷ It’s the shift from waterfall to agile, but applied to personal and organizational time management and productivity.

Conclusion

To make remote work successful, it’s not enough to digitize traditional workflows. Asynchronous work offers many advantages, but in practice, the shift to async requires adoption of remote-first tools and more importantly, a remote-first culture. That means defaulting to things like GitHub or Google Docs as your primary means of collaboration and reserving more synchronous tools like Slack or Zoom as points of escalation only when the urgency or complexity of the communication requires it. If you’re considering adopting more asynchronous workflows (you should!), I encourage you to check out my previous post on how to approach working asynchronously. After all, how you work is just as important as what you work on, so why not use the best, most modern workflows available.

Thank you and to Jed Verity and Lizzy Soltis for the conversations, observations, frameworks, and suggestions that inspired (and are reflected in) this post. Thanks also to @randw on Twitter, who when I asked about ideas for this post, they replied with a presentation I gave 8 years ago and subsequently forgot about.

Interested in learning more about how GitHub works and what it's like to be a GitHubber?
Check out these popular posts on GitHub's culture and communication patterns.

If you’re a professional, there’s a good chance that you’re a knowledge worker. Your deliverable at the end of each day, doesn’t actually exist beyond electrical impulses in the cloud. Through meetings, discussions, and drafting, you create organizational knowledge. ↩
Making work naturally visible is one of the “cheapest” and most impactful forms of communication for distributed teams. This requires low-friction tooling that organically captures and exposes process and the necessary psychological safety and trust to make high-visibility workflows low-risk for those involved. ↩
That said, there’s a lot that you get for “free” from working in-person, that is painful if you don’t purposefully recreate through remote work. ↩
The optimal cycle rate will speed up the overall system. Even if a single batch feels slower, because you’re waiting for a well-thought-out reply with links to source material instead of the instant gratification of a series of stream-of-conscious chat messages, the overall time for the team to ship an idea will decrease due to (A) parallelizing work to minimize blockers, (B) reducing decision churn through clarity, thoroughness, and forward thinking (fast thinking vs. slow thinking), © shifting communications from optimizing for the single sender to optimizing for the long-tail of recipients through one-to-many communications, and (D) building up shared context that increases tempo, quality, and resiliency of the team over time. ↩
Doctors appointments, mid-day grocery runs, haircuts, or just going for a walk around the block because you’re not feeling it. Work when you’re productive and do what you need to do to take care of your life, when you need to. ↩
This is the engineering concept of multiplexing applied to humans. Rather than waiting for one large unit of work to conclude before starting the next, you start 2, 3, or 4 small tasks in parallel, and make progress on each individually. By breaking work into their smaller tasks and make smaller, more frequent changes, you can gain confidence with each change, respond in nearer-to-real-time, and allows for better allocation of resources. ↩
Knowledge workers are most productive when they have large blocks of uninterrupted time. A two hour block of time is not fungible with four thirty minute blocks, or more realistically, that thirty minute block being further subdivided into three ten-minute blocks of uninterrupted time between responding to DMs. ↩

Originally published March 17, 2022 | View revision history

If you enjoyed this post, you might also enjoy:

Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit