Async (asynchronous) communication at the work place is having a moment. The pandemic acted as a forcing function, demonstrating that remote work isn't only possible but — in many cases and for many people — both preferable and more productive. Remote work, however, lead to an ever-more remote workforce which lead to a diversity of time zones which lead to collaboration issues. Async communication is intended to resolve some of these issues; and, to provide workers with more uninterrupted, deep-thought time. And, to be clear, I am a fan of async communication. But, I believe that there is an overused toxic form of async communication: Consensus building.
If I have a pull-request (PR) that I need reviewed and you don't have time, no worries, please look at it when you have a chance (Hot Take: all PRs should be reviewed in under an hour).
If I am trying to polish a user interface (UI) and I could use some design feedback but you're in a meeting, no worries, take a look at my InVision prototype and drop some comments when you have a spare moment.
If I deployed something awesome and I want to show it off but everyone else is busy, no worries, I'll make a demo video of it and drop it in our
#product-demos Slack channel for feedback.
These are all marvelous uses of async communication. They all entail non-blocking feedback workflows in which the Asker can go about their work until the Askee has time to participate and leave feedback. This kind of async work allows people to maximize concentration and minimize interruption.
ASIDE: Technically, PRs are "blocking" since code cannot be merged and deployed until it is approved. But, they are non-blocking in the sense that the developer can start working on the "next thing" while waiting for said PR approval (branch that branch and get it done). PRs block time, but they don't block work.
The toxic form of async communication looks a lot like the aforementioned examples, so it can be hard to spot it. For me, the trigger word — the word that exposes this beast for what it really is — is (
We). As in:
Hey team, we need to figure out how we want to proceed on project XYZ. When you have some time, please review this document and leave some feedback so that we can make a decision.
The problem with the term "we" is that it denotes no ownership. Or rather, it denotes universal ownership; and, when something is everyone's responsibility, it's no one person's responsibility in particular. Which means, no one is putting any constraints on this workflow. Which means, anyone can stall this workflow though a lack of participation.
I've seen this many times: consensus building over the course of weeks, if not months. One person leaves some feedback; then, days later, someone responds to said feedback; then, there's a bunch of async hand-wringing about what is and isn't in scope; then more async messages. And so on, until someone finally puts their foot down; or, the project is altogether abandoned.
Sometimes, consensus building is necessary. Sometimes, we really do all need to be on the same page about how to proceed. This is especially true about decisions that cannot be easily reversed. But, such consensus building should be gathered synchronously in a meeting (Zoom or otherwise). Get everyone you need on a call, hammer out all the points in real-time, and then get off the call with a clear sense of next steps and direction.
ASIDE: Even when building consensus, there should be a single person who is directly responsible for leading the effort. This person ultimately makes the decision based on informed input; and, whenever possible, this person should also be the person who writes down all the things (after all, it's their interpretation of the input that helps formulate the decision). But, this level of detail is beyond the scope of this article.
I can't tell you how many times in my career I've tried to go back-and-forth asynchronously over email / Slack / Confluence / Google Docs; and then, in a fit of frustration, get everyone involved on a Zoom call only to knock something out in minutes. This always leaves us asking the question: why in the heck fire didn't we just do this in the first place!
The underlying problem here is that we talk about "async communication" as if it were "one thing"; and, that this "one thing" is always good. This makes it hard to discern what should and shouldn't be communicated asynchronously. Hopefully, differentiating between "feedback" and "consensus building" will make it easier to navigate our increasingly remote world.
Making Awful Async Communication Great
One simple trick that I like for taking awful async communication and making it great is by:
Taking clear ownership.
Setting a tight deadline.
Instead of posing an async communications workflow as being about open-ended consensus building, flip it on its head: turn it into a feedback workflow with a tight time constraint. Don't ask people to help you make a decision - tell them that you've already made a decision and that they have X number of minutes / hours / days to provide feedback before the train leaves the station.
This way, a failure for one person to participate isn't a blocking constraint - it's simply someone opting to de-prioritize their role in the work. In other words, the work doesn't stop simply because they have other things that they'd rather be doing.
Not only does this keep the machinery running smoothly, it also helps you build a stronger sense of ownership over your own work.