Almost every team I talk to says they work asynchronously. Almost none of them actually do. What they have is a default that quietly reverses itself the moment anything gets difficult. The easy stuff happens in chat and docs, and everyone feels productive and modern. Then a hard decision comes up, or a disagreement, or something ambiguous, and the reflex kicks in: let's just hop on a call. That reflex is the tell. It means async was never the operating model. It was the thing you did until real work showed up, at which point you fell back to synchronous because synchronous is what you actually trust.
I lead product, and I have watched this pattern break otherwise excellent teams. Async by default is not a vibe and it is not a tool you install. It is a decision you make on purpose, and then defend, with structure underneath it that makes the async path the path of least resistance instead of the heroic exception. Without that structure, asynchronous communication does not happen, it just degrades, and you end up with the worst of both worlds: the latency of remote work and the meeting load of an office.
The fallback to meetings is the failure, not the fix
Let me be precise about what goes wrong, because the failure is subtle and feels like the responsible choice in the moment. A thread gets complicated. Two people are talking past each other. Someone, usually trying to help, says "this is getting hard to do over text, let's just get on a call." And it works. The call resolves it. Everyone leaves relieved. That relief is the trap.
Every time you resolve a hard thing in a meeting, you teach the team that the way to handle hard things is a meeting. You train the reflex. You also lose the record, because the reasoning that took thirty minutes to work out lives only in the heads of whoever was on the call, and the next person who hits the same question has to ask all over again. The meeting did not just cost the hour. It cost the durability of the answer and it reinforced the exact habit that makes distributed teams slow.
The deeper problem is that the meeting fallback hides whatever was actually broken. The thread got hard for a reason. Maybe the question was not framed clearly. Maybe the right context was not attached. Maybe the decision rights were ambiguous and two people each thought it was theirs to make. A meeting paves over all of that with real-time bandwidth. The underlying defect stays unfixed, so it recurs, so you have another meeting, and the cycle convinces everyone that async simply does not work for hard problems. Async works fine for hard problems. Unstructured async does not.
Async is a decision, and decisions need defaults
Making async real starts with naming it as the default and being willing to pay the cost of holding the line. A default only means something if it survives pressure. Ours is simple to state and hard to live: if something can be done in writing, it is done in writing, and a meeting has to justify itself rather than being assumed. The burden of proof flips. Nobody has to defend writing a doc. Someone does have to defend booking a call.
That sounds rigid, and the first weeks of it are uncomfortable, because synchronous is the easy reflex and easy reflexes are hard to break. But the discomfort is the point. You are retraining a habit, and habits do not retrain themselves gently. What makes it stick is not willpower, it is making the written path genuinely lower-friction than the meeting path, so that doing the right thing is also the easy thing. If writing things down is painful and getting on a call is one click, people will get on the call every time, and no amount of policy will stop them. The policy has to be backed by structure that makes async the comfortable choice.
Example: We had a team that scheduled a recurring meeting for every contentious design review because text reviews kept stalling. Instead of accepting that as proof async fails, we looked at why the text reviews stalled. The reviews had no structure: no clear question, no decision owner, no deadline, just a link dropped in a channel. We added a simple template that forced the author to state the decision being made, the options, their recommendation, and who decides by when. The stalling stopped. The recurring meeting got cancelled. The async version was actually faster once it had a shape.
The structure that makes async actually work
Async by default is mostly an exercise in removing the reasons people fall back to meetings. Every meeting solves a specific problem, and if you solve that problem another way, the meeting loses its reason to exist. A few structures do most of the heavy lifting.
- Clear decision ownership. Most threads spiral because nobody knows who actually decides. Name a single decision owner for anything important. The owner gathers input asynchronously and then decides, in writing, with reasoning. Ambiguity about who decides is the single biggest driver of the meeting reflex.
- Strong defaults for written formats. A decision doc, an update, a proposal, each with a known shape. Templates are not bureaucracy here, they are the thing that makes writing fast and reading faster, because everyone knows where the point lives.
- Explicit response-time expectations. Async does not mean whenever. It means within a known window. If people do not know whether a question will be answered in an hour or a week, they reach for a meeting to get certainty. State the window and the reflex relaxes.
- A single source of truth. When the decision, the discussion, and the work live in separate tools, async collapses, because reconstructing context is so painful that a call feels easier. Keep them together and the written path wins.
Notice that none of these are about typing faster or being a better writer. They are about removing ambiguity, because ambiguity is what sends people running to real time. Real-time conversation is wonderful at resolving ambiguity on the fly. The trick of good async is to resolve the ambiguity up front, in the structure, so you never need the real-time pass.
What you get back, and what it actually costs
I want to be honest that async by default is not free, because the version of this argument that pretends it has no downside is the version that gets teams to try it, fail, and quit. Async is slower for any single resolution. A question that a call would settle in five minutes might take a day in writing. That is a real cost and you have to be willing to pay it, because what you buy with it is significant.
You buy protected focus, which is the thing knowledge work actually runs on and the thing meetings destroy most efficiently. You buy a written record, so decisions and their reasoning persist instead of evaporating, which compounds enormously over time. You buy genuine inclusion across time zones, so the person in a different region is a full participant rather than someone who reads the meeting notes after the fact. And you buy better decisions, because writing forces the thinking that talking lets you skip, and because the people who reason well but speak up slowly finally get heard.
The trade is latency for compounding value. You give up speed on the individual interaction and you get back depth, durability, and reach across the whole team. For most knowledge work that is a trade worth making, but only if you make it consciously. Teams that drift into async without deciding to get the latency cost and none of the payoff, because they never built the structure that converts the cost into a benefit.
How we operationalized it
Concretely, here is what async by default looks like for us on an ordinary week. Important decisions start as written proposals with a named owner and a deadline, not as calendar invites. Updates are written and read on people's own time, not delivered live to a room. We keep a small number of meetings on purpose, for the things that genuinely benefit from real-time, like fast creative back-and-forth or the human connection that holds a remote team together, and we protect those by not diluting them with everything that should have been a document. The meetings we keep are better because they are rare and chosen.
The piece that made it durable was getting the decision, the discussion, and the work into the same surface, because the moment those fragment, the meeting reflex comes back. This is a big part of why we build Atlas the way we do, with tasks, projects, inbox, and the conversation around them in one place rather than scattered across tools that force you to rebuild context every time. When the written record sits next to the work it governs, async stops being effortful and becomes the obvious path, which is the only way a default ever really holds.
So if your team says it works async but reaches for a call the moment things get hard, you do not have an async problem, you have an unmade decision. Make it on purpose. Name the default, build the structure that makes the written path easier than the meeting, and accept the latency cost for what it buys you. Async by default is not what happens when people are remote. It is what happens when you decide it should, and then build the thing that lets it.