Asynchronous working gets announced as a policy: fewer meetings, more written communication, no expectation of immediate response.

The announcement rarely changes anything, because the constraint isn't policy. It's that most people write badly for this purpose, and the failure mode is invisible to the person doing it.

What goes wrong

The characteristic failure is a message that requires a reply to be useful.

"Can we talk about the pricing thing?" "Do you have a minute?" "Any thoughts on the deck?" Each of these initiates a conversation and conveys nothing. The recipient can't act, can't decide, can't do anything except respond and wait.

In a synchronous environment this is fine — the reply comes in seconds. In an asynchronous one, each round trip costs hours or a day, and a question that needed three exchanges takes three days.

The result is that async organisations frequently feel slower, and people conclude async doesn't work, when what's actually happening is synchronous communication habits being executed over asynchronous infrastructure.

What a good async message contains

The principle: a message should let the recipient act without needing to reply first.

Which means it needs the context, the specific question or decision required, the relevant information, your own view, and a deadline.

Compare: "Can we talk about pricing?" with "I'm proposing we raise the standard tier from X to Y from the first of next month. Reasoning and the competitor comparison are in the attached document. The main risk is the three largest accounts, which I've modelled on page two. I need a yes or a specific objection by Thursday so we can give customers thirty days' notice. Unless I hear otherwise I'll proceed."

The second is longer to write and resolves in one exchange. That trade — more effort for the writer, less for everyone else — is the entire discipline.

The default-to-action pattern

The most useful single technique: state what you'll do if nobody responds.

"Unless somebody objects by Thursday, I'll go ahead." This converts a blocking question into a non-blocking one. Silence becomes agreement rather than a stall.

It requires organisational trust and appropriate scoping — you can't apply it to decisions above your authority — and within those limits it removes an enormous amount of waiting.

The alternative, where everything requires explicit approval, means the slowest responder sets the pace for everything.

Writing decisions down

The other half of the discipline, and the one that compounds.

Decisions made in conversation exist only in the memories of those present. Decisions written down — what was decided, why, what alternatives were considered, who decided — are available to everyone, including people who join later.

This is where distributed organisations gain a real advantage over co-located ones, and only if they actually do it. An organisation with a searchable record of its decisions has a genuine asset. One that holds decisions in meetings has an oral tradition, and oral traditions don't scale.

The practical version is modest: a short written record of any decision that took more than a brief discussion, stored somewhere findable. Context, options, decision, reasoning. Fifteen minutes.

What genuinely needs to be synchronous

Not everything should be written, and pretending otherwise produces its own dysfunction.

Anything with emotional content. Difficult feedback, conflict, bad news. Written communication strips tone, and the recipient supplies the missing tone from their own anxiety.

Genuinely ambiguous problems. Where nobody knows the shape of the question yet, the back-and-forth of live conversation is more efficient than structured writing.

Building relationships. Trust is largely built through informal interaction, and there's no written substitute. Distributed teams that never speak develop coordination problems that no amount of documentation solves.

Anything that's already gone wrong in writing. If a thread is going in circles or getting tense, a fifteen-minute call resolves it. Recognising that moment early is a skill in itself.

The response time question

The most common source of anxiety, and it's usually unaddressed.

If nobody states what response times are expected, everybody assumes the fastest — which means constant monitoring, which is exactly what async was supposed to eliminate.

The fix is explicit norms by channel. Something like: chat within a working day, email within two, anything urgent by phone. Whatever the specifics, stating them removes the ambiguity that produces the anxiety.

And the norms have to be honoured by senior people, particularly the habit of not sending messages outside working hours. A leader who works evenings and messages as they go creates an expectation regardless of what any policy says, because people read behaviour rather than documents.

The meeting that should have been a document

The inverse of the familiar complaint, and it is the more common failure in organisations trying to work asynchronously.

A status meeting where everybody reports in turn is a document read aloud slowly. A presentation followed by questions is a document plus a discussion, and the reading should happen before the room assembles.

The format some organisations use — circulate the document in advance, spend the first ten minutes of the meeting reading it in silence, then discuss — looks strange and works remarkably well. It guarantees everybody has actually read it, which the honour system does not, and it converts the meeting into the part that genuinely needs people present.

The general test: if the meeting's purpose is transferring information, write it. If its purpose is resolving disagreement or making a judgement together, meet.