Communicating using asynchronous media
A recurring theme when organizing software development teams is how to build the communication structures in and around the team.
Engineering, being knowledge work, requires large chunks of distraction-free time, in order to tackle complex problems; on the other hand, it’s also a team sport, and thus requires intense collaboration to build any system of non-trivial scale.
Balancing both of these needs is hard but, in our experience, can be done effectively by resorting to asynchronous communication media.
What is asynchronous communication?
When we say “communication”, we usually mean “conversation”: two (or more) people speaking in turns, exchanging ideas.
In this traditional means of communication, all parties are actively involved at the same time (i.e. synchronized), effectively blocked from doing anything else besides speaking or listening1. Examples of this are talking (whether in-person or on a phone) and chat systems (e.g. Slack).
For communication to be “asynchronous”, i.e., to work in the absence of significant synchronization, it is optional that everyone is available at the same time and there is an understanding that a reply probably won’t arrive immediately.
An example of asynchronous communication media that is easy to understand is conventional mail (you don’t need to be at home to receive your mail), but plain email is asynchronous as well.
For software development specifically, the issue tracker (Gitlab, GitHub, JIRA) is also an asynchronous communication media, as are most other tools that support messaging/commenting.
Why is asynchronous communication better?
The first thing to note here is that asynchronous communication is not better in every context: rather, it is usually better in the specific context of software engineering.
It produces less interruptions
By its nature, asynchronous media separate the production of the message from its consumption: in other words, even if someone sends you a letter every day, you’re free to only check your mail once a week.
Since, as mentioned above, effective engineering work requires focus, this allows engineers to focus on their work without interruptions and only stop every hour or so to check on their messages.
It allows for deeper discussions
Discussions in engineering often require:
compiling information from various sources
testing hypotheses
Both of which are awkward to do synchronously because they take time and, meanwhile, the other person would just be standing there “doing nothing”.
With asynchronous messages, the writer can devote themselves to writing something that is well structured and easy to “digest”, while the reader can take their time to make sure they understand the points that were made.
How can I use asynchronous messaging better?
An interesting observation is that, while most people will have experience with email, their usage is strongly influenced by synchronous communication patterns and, to a certain extent, defeat its whole point.
Here, we make some recommendations for making better use of asynchronous communication.
Set expectations for response times and availability
This might be the hardest to pull off: in the end, we all know we have little control over other people’s feelings, and it’s easy to imagine “missing” a message, with severe consequences.
In practice, such incidents are very rare and can be handled by providing an emergency contact (e.g. phone call), with the understanding that it’ll only be used for something that requires immediate action.
In most cases, as long as you still reply in a reasonable time (e.g. a couple of hours), most people won’t care too much or notice.
Disable notifications
Even if you’re not reading the messages right away, if you don’t disable notifications, you’ll be distracted by them.
A good strategy here is not to disable notifications completely but to keep them only for “urgent” messages (e.g. explicit mentions).
Pull all messages into a single inbox
This makes it easier to go through all the messages than having to hop between different systems; in practice, this “main” inbox will almost always be email because it’s what almost every tool supports.
This might seem overwhelming at first (especially with the amount of email that certain tools send) but can be made tractable with effective use of filters.
Something else to keep in mind is that not all messages are created equal: some will require a turn-around of only a few hours (e.g. answering a question), while others may not require one for a few days (e.g. a long discussion on a Request For Comments document), and still others might require no answer (e.g. a notification that someone created a Merge Request).
Assign an “on-call” engineer
An option, within a team, is to assign a single engineer to “on-call” duty, meaning that person will field all synchronous requests, in order to shield the team from the distractions.
This assignment can be rotated on a regular basis, so every engineer has the chance to work distraction-free.
Summary
In this article, we’ve described what asynchronous communication is and how it can be beneficial for teams developing software.
Additionally, we’ve provided some suggestions on how to make asynchronous communication work better.
Do you feel that your work environment is too distracting?
There is no such thing as multi-tasking: research has firmly established that, with the exception of basic tasks, multi-tasking produces significantly inferior outcomes and, over time, deteriorates an individual’s ability to focus effectively, even when working on one task at a time.