Most companies that fail at async communication are solving the wrong problem. They buy better tools, set up more channels, write policies about response times. Then they wonder why everyone still feels out of the loop and meetings keep multiplying.
Here’s the actual problem: async communication only works when your team can write well enough to replace a conversation. Not write formally, not write at length, but write with enough clarity and context that the reader can act without follow-up. That’s a skill most teams haven’t developed, and no tool will develop it for them.
Companies that have genuinely figured out async, places like Basecamp, GitLab, and Automattic, share one trait more than any other: they treat writing as a professional competency, not a soft skill. Everything else follows from that.
Writing Quality Is the Actual Infrastructure
When Automattic (the company behind WordPress.com) built a fully distributed team long before remote work became a point of debate, they didn’t start by picking collaboration software. They started by hiring people who could communicate in writing. Their hiring process famously includes a paid trial period specifically to observe how candidates communicate asynchronously under realistic conditions.
This matters because the cost of bad async writing compounds fast. A vague Slack message generates a clarifying thread, which someone misses, which requires a meeting to resolve. You’ve now spent more total time than the original meeting would have taken, and you have nothing documented at the end of it.
Good async writing does three things: it gives enough context that the reader doesn’t need to ask what prompted the message, it makes the ask explicit, and it surfaces the relevant constraints (timeline, decision authority, dependencies). If you write messages that do all three, you will be stunned how rarely you need to wait for a response before moving forward.
Norms Beat Tools by a Significant Margin
Every async failure story involves Slack, and Slack is not the problem. The problem is that teams installed Slack and immediately recreated the psychological pressure of being in a physical office, where visible responsiveness signals engagement. If someone can see you’re online, you’re expected to respond quickly. That expectation is the opposite of async.
Companies that get async right establish explicit social norms around response time, and they enforce those norms from the top down. GitLab’s public handbook, which runs to thousands of pages, specifies expected response windows for different communication channels. Managers at those companies demonstrably do not respond to messages instantly, which gives everyone else permission not to.
You probably can’t rewrite your company’s culture overnight, but you can change your own behavior and articulate why. Respond to non-urgent messages in batches. When you do respond, write a message that could reasonably end the thread rather than kick it forward. The people who work with you will notice.
Decisions Need a Paper Trail That Doesn’t Require Excavation
One reason teams default back to synchronous communication is that they’ve learned, from experience, that async discussions don’t actually produce decisions. They produce a long thread that ends ambiguously, after which someone calls a meeting to actually decide.
The fix is structural. Every async discussion that involves a decision needs a designated person who closes it. Not mediates it, not summarizes it: closes it. They write a short conclusion (what was decided, what the alternatives were, who owns the next step) and post it somewhere findable. This is the part living documents do better than most teams realize, because the decision lives somewhere outside the thread where it was made.
Without this, async generates noise that looks like signal. With it, you build an institutional memory that actually reduces the volume of future communication because people can look things up instead of asking.
The Counterargument
The serious objection to prioritizing async is that some communication genuinely benefits from real-time back-and-forth. Emotional conversations, creative brainstorms, situations where you need to read the room. This is true.
The answer isn’t async fundamentalism. It’s using synchronous time for the things that actually require it, and protecting that time by keeping everything else async. Teams that default to meetings for everything undervalue their synchronous time as much as they undervalue their asynchronous time. When every conversation happens in a meeting, the important ones get no more attention than the trivial ones.
Calibrating this well is harder than adopting any particular tool or policy, and it requires ongoing judgment. That’s the point. Async is not a system you install. It’s a set of habits your team builds, repeatedly, over time.
The Payoff Is Real But Delayed
Shifting to genuine async communication will feel slower for the first few weeks. Writing takes more time than talking. Waiting for a response is uncomfortable if you’re used to getting one instantly. The temptation to schedule a quick call is strong.
Push through it. What you’re trading is the false efficiency of constant real-time contact for the actual efficiency of uninterrupted focus time, decisions that don’t need to be relitigated, and communication that produces artifacts instead of evaporating into the air.
The companies that have figured this out aren’t using better software than you. They’ve built teams where writing is taken seriously, where norms are explicit, and where decisions actually close. You can start on all three today, with whatever tools you already have.
