The simple version
Async-first communication means you stop treating every thought as an interruption that someone else must handle right now. Distributed teams adopted it out of necessity, and it turns out to work better than the always-on alternative.
What open-plan offices got wrong
The open-plan office was sold as a collaboration machine. What it actually built was an interruption machine. When everyone is visible and physically proximate, the default becomes: walk over, ask now, expect an answer immediately. The cost of that interaction feels low because no one has to schedule anything. But the cost to the person being interrupted is real and large.
Researchers studying knowledge workers have found that it can take more than twenty minutes to return to a complex task after an interruption. Multiply that by a dozen interruptions a day and you haven’t built a collaborative environment, you’ve built one where focused work becomes a luxury that happens before 9am or after 5pm. Splitting attention across two tasks costs more than both isn’t a metaphor. It’s a measurable tax on output.
Open-plan offices never fixed this because the social pressure ran in the wrong direction. Looking busy by being responsive felt virtuous. Closing your laptop, putting on headphones, and signaling unavailability felt antisocial. The culture rewarded interruption.
What distributed teams had to build instead
When your colleague is eight time zones away, you can’t walk over. You either wait, or you learn to communicate in a way that doesn’t require the other person to be present.
Distributed teams, especially those that have been doing this for more than a decade (companies like Automattic, GitLab, and Basecamp), developed a set of practices that aren’t really about remote work at all. They’re about treating other people’s attention as a scarce resource worth respecting.
The core shift is this: the burden of communication moves from the receiver to the sender. Instead of pinging someone and waiting, you write the message in a way that contains enough context that a response can happen hours later, or not at all. You stop optimizing for speed of sending and start optimizing for clarity of content.
GitLab publishes its internal handbook publicly, and it’s one of the clearest illustrations of what async-first looks like in practice. Decisions get written down. Context gets documented. Nobody needs to be in the same room, or even the same hour, to understand what happened and why.
The four practices that actually transfer
You don’t need a distributed team to use any of this. Here’s what translates directly.
Write before you meet. Before scheduling a meeting, ask whether a written document would do the same job. Not a message, a document. Something with a title, a clear question or decision to be made, and enough background that someone coming in cold can follow it. Many meetings exist because the person who called them didn’t want to do the writing. Make the writing the default, and meetings become the exception for things that genuinely need real-time negotiation.
Default to public channels, not DMs. When you ask someone a question in a private message, you’ve created a private answer that no one else can learn from. When you ask it in a shared channel or document, the answer becomes organizational memory. Distributed teams learned this because they had no other choice. Co-located teams can still rely on hallway conversations, and they do, which is why the same questions get answered over and over.
Set explicit response-time norms, not implicit ones. The anxiety of async communication usually comes from not knowing when a response is expected. This is solvable. You can simply say: non-urgent questions get a response within 24 hours, urgent ones within 4 hours, and anything that needs an answer in the next 30 minutes gets a phone call. Writing that down removes the pressure to monitor every channel in real time.
Separate your communication from your work. The mistake most people make with tools like Slack is treating them as a continuous feed that must be monitored. The better model is: you work, then you communicate, then you work again. Check messages at defined times. Close the tab in between. This feels aggressive until you realize that almost nothing is actually urgent, and what you cancel reveals more than what you attend applies just as much to notifications as to calendar entries.
The real reason this is hard to adopt
Async-first isn’t technically complicated. The reason co-located teams resist it isn’t that it doesn’t work, it’s that it makes certain things visible that synchronous communication hides.
When you have to write something down clearly enough for someone to act on without asking follow-up questions, you quickly discover whether you actually understand what you’re asking. Vague requests that survive a spoken conversation collapse when written. Decisions that felt made in a meeting turn out to have left critical things unresolved. The writing surfaces the muddiness.
This is uncomfortable, but it’s the point. Async communication isn’t just a scheduling convenience. It’s a quality filter on thinking. Teams that adopt it tend to produce clearer decisions because they’re forced to articulate them before acting on them.
The open-plan office never figured this out because it was designed around the belief that proximity creates collaboration. Sometimes it does. More often, it creates the feeling of collaboration while fragmenting the actual work. Distributed teams didn’t choose async-first as a philosophy. They chose it because the alternative was chaos. But the thing they built in the process is worth importing regardless of where you sit.
Start with one meeting this week that you replace with a document. Write down the context, the question, and what you need from your colleagues. See what comes back. That’s not a remote-work exercise. That’s just better communication.
