Asynchronous Communication
How many times have you sat in a meeting where people just took turns talking past each other? Asynchronous communication is underrated and underutilized in the Enterprise. It’s an invaluable tool to help solve our aforementioned meeting malaise as well as many others.
Old habits are hard to break of course. And the Enterprise as a whole has a bad synchronous communication habit. Fortunately, the rise of remote work is helping to change this for which we as developers should be very grateful.
Synchronous is Still Useful, But…
Synchronous communication has been the default for a long time. Any time an issue arises in the Enterprise, “let’s get everyone in a room and solve it.” Though we can no longer get people in the same room because companies are almost all distributed now.
But the bigger problem with this approach is especially relevant to us developers and technologists. That is, the problems we routinely deal with are highly complex and deterministic. Compare this with other domains where outcomes are much more non-deterministic.
This is a shortened way of saying that tech problems we solve generally have an algorithmic solution or solutions. Whereas problems in other domains, such as Sales that are governed by human psychology, are much more intractable when it comes to finding algorithmic solutions.
Moreover, meetings can be very useful in domains like Sales, while often being very fruitless in other domains like Tech. Sales will rely much more heavily on a trial and error iteration approach to solving problems. In Tech, this kind of approach is horribly inefficient for most problems.
As developers we need to build complex mental models of our problem domains. Trying to then share this information verbally in a synchronous exchange is very ineffective. This is the kind of thing that needs to be translated to a durable medium and then provided to others in an asynchronous manner.
A follow-up synchronous exchange then would have some benefit. In practice however, Enterprises generally favor skipping straight to the synchronous meeting. This omits the most crucial part of the problem solving and allows other interpersonal attributes to dominate the exchanges.
Asynchronous Promotes Iteration
All complex systems in Tech and elsewhere are the result of iteration. This is the greatest feature of asynchronous communication in my opinion as well. It promotes iteration. Iteration of understanding to individuals as well as iteration to the durability and robustness of solutions.
Consider when you’re trying to learn a new technology. You choose your favorite learning platform between Pluralsight vs O’Reilly Safari and start watching a video tutorial. Do you immediately retain every bit of information you see and hear? Or do you need to think, build something yourself, and re-watch some parts before everything starts to sink in?
If you retain everything immediately, you are amazing! You’d also be great in synchronous communication and should by all means favor it whenever possible.
However, for us mere mortals, it’s going to take time. Time to absorb new information and incorporate it within our own mental models of the technological and business domain landscapes.
Like learning a new technology, trying to solve a complex development problem is similar. We benefit from having time to digest and understand the problem on our own before collaborating on a solution. The collaboration is where the value of iteration comes in, but without the asynchronous problem digestion phase this value is drastically reduced.
More Efficient
Asynchronous communication is simply more efficient in most cases. Especially when it comes to developers and our usual workflow. Much of a developer’s time is spent in deep concentration which is difficult to achieve and whose interruption is extremely costly.
Barring a pants-on-fire PROD emergency, it’s usually best to let developers manage their own time without forced interruptions. Promoting an asynchronous communication policy within the team is important. This way developers are empowered to respond to non-critical items on their own schedule and allow them to optimize for when they are most productive.
Contrast this with your average dev team whose manager schedules regular meetings scattered throughout the day and week. A developer in this environment is not in control of her time and cannot possibly optimize for her most productive times due to the cavalcade of interruptions foist upon her.
Simply put, by providing an asynchronous and empowered environment for your developers they will be more productive. They will also undoubtedly be happier and more likely to stay with your organization long-term as they are empowered to do what they love without needless encumbrances.
Summary
Asynchronous communication requires a durable medium and is therefore durable as well. Contrast this with synchronous communication which is inherently ephemeral.
As developers, we work with complex systems that generally have deterministic solutions. With asynchronous communication, a developer has time to fully understand a problem before collaborating and iterating on solutions with her peers.
A dev team that optimizes for asynchronous communication has a tremendous advantage over traditional dev teams. This method of empowering developers to control their own schedules is highly undervalued and underutilized.
It’s remarkable that this simple approach is so rare given its ability to drastically improve dev team productivity. Old habits are indeed hard to break.