The purpose of this series will be to explore what async-first principles are, what they’re not, why they’re useful, and how they can help your team to deliver better software & get a better work-life balance.
What is Asynchronous Communication?
It would be easy to write that “asynchronous communication is communication which isn’t synchronous”, but that would be unhelpful. Simply put, the longer the gap is between replies, the more asynchronous a method of communication is.
In the context of technology, when we talk about synchronous communication, we’re generally talking about in-person meetings, video calls, or phone calls. Asynchronous communication would be e-mail, forums, and bulletin boards.
Instant messaging tools can be asynchronous, if the company culture allows for delaying a response to a message. This usually has to be explicitly communicated & configured, as tools like Slack and Teams are designed to interrupt with notifications by default.
What does Async-first Mean?
Most of us are accustomed to working sync-first.
Our default modes of communication are video calls and instant messages with an expectation of quick replies. Our default mode of working is to start and end at the same time.
We’ve had it drummed into us that we’re not truly agile unless we have a daily scrum, weekly backlog refinements, weekly retrospectives, three amigos sessions, pairing sessions, mobbing sessions, guild discussions, and plenty of ad hoc meetings on top of those. None of this is true.
We’ve left the office, but we’ve taken it home with us.
Async-first is a different way of thinking. The default method of communication is long-form text, and team members are given the time to properly read, understand, formulate opinions and reply. Instead of focusing on presenteeism and micro-management, Async-first teams focus on value delivered. Instead of rewarding the loudest voices or the first to respond, Async-first seeks to reward the most robust ideas.
Because of this, team members can live where they want to live, and work when they want to work (with some on-call duties usually required).
The Benefits of Synchronous Communication
Async-first isn’t async-always, though. There are times when we want, or even need, to use synchronous communication methods. All we’re doing is flipping the default from a video call to a message thread.
Here are some examples of use cases for synchronous discussions:
(Not-)Office Chatter
The best case for synchronous communication is that it offers a sense of personability that text lacks.
The value of social chat, about work or otherwise, should never be underestimated, and as such we always recommend having an optional ‘virtual water cooler’ that people can pop into and out of as they choose, especially in fully remote environments.
Genuine Urgency
Genuine urgency is the most pressing business case for synchronous communications. Some examples, but by no means an exhaustive list, are:
- an outage in production
- a team member being blocked
- a contractual deadline
Paired & Mob Programming
Pair and mob programming have well-researched benefits, especially when it comes to tackling complex problems, preventing knowledge from being siloed, unblocking members of the team, and training juniors.
It’s important to strike the right balance between pairing and individual coding for each individual, as more introverted team members can become exhausted and burnt out if they’re required to pair regularly.
Some Drawbacks of Synchronous Communication
Context Switching
Context switching is, as the name implies, the act of switching from one ‘context’ to another. For example, when an engineer has to stop writing code in order to respond to someone tapping on their shoulder or a meeting in their calendar, this is a context switch.
Software engineers often talk about being “in the zone” or “in flow”. This to a state of focus achieved because they’ve absorbed all of the important context around it: the requirements, the problem function (and the four functions between the edge and that function), the testing strategy, and possible solutions.
When an engineer switches context, all of this information is dumped and needs to be picked back up again.
Research suggests that software developers lose up to 44% of their productive time to context switching. That isn’t the time they spend doing non-coding activities, it’s the additional non-productive time associated with switching between activities.
Videoconferencing Limitations
A compounding factor in the era of remote-first working is videoconference fatigue, where researchers have concluded that “frequency, duration, and burstiness of Zoom meetings were associated with a higher level of fatigue”.
New research at Stanford suggests that the condition disproportionately affects women and introverted individuals. We also know that women struggle to be heard on video calls, with up to 45% of women reporting that they struggled to get a sentence in, and 20% reporting that they felt they’d been actively ignored by colleagues.
Contextual Disparity
Another issue with synchronous communications is a lack of time to parse and think about ideas. Different participants go into meetings with different amounts of context, and therefore, it’s quite common for the people with the greatest level of contextual understanding to dominate the discussion, and for others to be relegated to the sidelines.
It’s not (in most cases) because they don’t want to participate, it’s just that they’re having to do a lot more mental work to understand the points being made than the people with the context in their heads, or perhaps that they’re more introverted and want to think things through more carefully before sharing them. Long-form text allows everyone to do the research, put thought into their responses, and share their best ideas.
If a decision doesn’t need to be made in the next forty-five minutes, it’s likely that a more thoughtful decision, with more contributors, could be made over the next four to five days.
It Sounds Interesting, But Who Uses It?
Corporate Users
Async-first has been used successfully at remote-first companies for over a decade, with some of the biggest names including:
Each of these companies has different practices that work for them, and ‘async-first’ encompasses many modes of thinking.
Free Software Users
Of course, the roots of Async-first development are in the free software world.
Nearly all free software projects work asynchronously, with newsgroups, forums & IRC channels providing the main channels of communication.
Linux kernel developers, the GNU project, OpenSSL, nearly every programming language core team, the vim & emacs teams, and many more whose work all of us use daily rely on Async-first communications to build the most important projects out there.
Does Async-First Mean Less Communication?
In a word, no.
Async-first means clearer, more inclusive, and more thoughtful communication, culminating in better ideas and more value delivered to end users. Being able to read, digest, think about and reply to ideas over hours instead of seconds leads to better decision making, and better documentation of that decision-making.
Compare this public RFC to any meeting you can remember about a single feature, and I expect you’d agree that it’s at least equally collaborative.
Coming Up Next
The next article in the series will be taking a deeper dive into the practices of some async-first companies, which have thoughtfully published their working guides on the public Internet.
Cover Photo: Oleksandr Gamaniuk on Unsplash.
