Async by Default: What Actually Changes

"Async by default" gets sold as a calendar reform. It is not. The meetings were where decisions happened; removing them without replacing that function just moves the confusion somewhere less visible.

What actually has to change

Decisions get written down, with reasoning

Not meeting minutes. A short record: what was decided, by whom, and why — including what was considered and rejected.

The reasoning is the part people skip and the part that matters. Six months later, "we chose X" invites someone to re-open it. "We chose X because Y, and rejected Z because W" either settles it or gives the person a specific thing to argue with.

A decision log is the single artefact that makes async work possible. Everything else is logistics. If someone asked today why your team chose its current stack, could anyone answer without calling a meeting?

Questions get a deadline

Synchronously, a question gets an answer in the meeting. Asynchronously, a question with no deadline can sit for four days while everyone assumes someone else is handling it.

Every question needs: who specifically is being asked, by when, and what happens if there is no reply. That last one matters most — "if I do not hear back by Thursday I will go with option A" converts silence into a decision instead of a block.

Writing standards go up, for everyone

This is the cost nobody advertises. Async work means everyone's writing is now load-bearing. A vague message in a meeting gets clarified by the next sentence; a vague message in a thread costs a day.

Concretely, that means: lead with the ask, state the context second, and make the specific action obvious. It is a learnable skill and it is genuinely unevenly distributed on most teams.

Where async fails

Situation	Async outcome
Two people disagree	Threads entrench positions rather than resolving them
The problem is not yet understood	Exploration needs interruption and tangents
Something is emotionally loaded	Text removes the tone that would have defused it
Someone is new	They do not yet know what they do not know to ask

The pattern: async is excellent at transmitting settled information and poor at reaching agreement. Use it for the first and call for the second.

When it is worth it

Spanning more than about four hours of time-zone difference is the clear case. Below that, the honest answer is that async costs more than it saves: writing a decision takes longer than saying it, and the compounding benefit of a searchable record takes a year or two to outweigh that.

Teams in one time zone that adopt async by default usually end up with the costs — slower questions, heavier writing burden — and none of the reason for them.

The meeting that should not be removed

Teams adopting async tend to cut meetings by category — all standups, all one-to-ones — when the useful cut is by function. Some meetings were transmitting information, and those convert cleanly to writing. Others were doing something writing cannot do.

Meeting	Was actually doing	Convert to async?
Status standup	Transmitting information	Yes — a written update is strictly better, and searchable
Design or architecture review	Reaching agreement under disagreement	No — threads entrench positions
One-to-one	Detecting things nobody would write down	No, and this is the one most often wrongly cut
Sprint planning	Both — estimation is written, sequencing is negotiated	Split it
Incident response	Fast iteration under uncertainty	No, obviously

The one-to-one row matters most. Its real function is surfacing things people would not put in writing — that they are stuck, bored, or about to leave. Removing it does not move that conversation into a document; it removes the conversation.

The tooling matters less than people expect

Async-by-default gets discussed as a tooling decision, and it mostly is not. A team with a decision log in a plain repository and clear norms about deadlines outperforms a team with an expensive knowledge platform and no norms, every time.

What the tool does need to do is narrow: make the decision log searchable by someone who was not there, keep it in a format that outlives the vendor, and make it obvious where a decision is recorded versus where it is being discussed. Conflating those last two is the most common tooling failure — a decision buried in a chat thread is not written down in any useful sense, because nobody will find it.

How to tell whether it is working

Two signals, both cheap to check after a couple of months. If you are two months into this, run them now:

• Ask someone who joined recently to find out why a specific decision was made. If they can do it without asking a person, the log is working. If they end up in a chat channel asking "does anyone remember why", it is not.
• Count how many questions are still open after three days. A growing number means the deadline norm has not landed — and that, rather than too many meetings, is what quietly kills async teams.

The compounding part

The benefit that is genuinely hard to see early: after two years, a searchable decision log means new people can answer "why is it like this?" without asking anyone. That is worth a great deal, and it is invisible for the first eighteen months, which is why most teams abandon the practice before it pays. If you want a concrete pipeline with the checkpoints baked in, our weekly publishing workflow is one worked example.