Asynchronous First Delivery

Organisations attempting asynchronous working discover the same two failure modes, usually in that order. First, async is declared, meetings are cancelled, and a month later nothing is written down and decisions are being made in direct messages between the three people who share a timezone. Second, someone notices and mandates documentation, at which point the volume of written material increases enormously and the ability to find out why anything was decided does not improve at all.

Both come from the same misunderstanding: treating asynchronous working as an absence — the absence of meetings — rather than as a set of positive practices that have to be built, taught and enforced. Removing a meeting does not create asynchronous coordination. It creates a vacuum, and vacuums are filled by whoever is loudest and best-connected, which is the opposite of what a distributed team needs.

Written-first is a discipline with mechanics. They are learnable and somewhat unnatural, which is why organisations that have them treat them as a core capability rather than a stylistic preference. Remote-first companies that have worked this way for a long time — the publicly documented practice at GitLab and the long-running distributed model at Automattic are the usual reference points — are not distinguished by having fewer meetings, but by having a default artefact for every kind of coordination, and by the fact that not producing it is a visible omission rather than a private choice. What follows is that machinery. None of it needs tooling you do not already have.

Writing is not overhead, it is the work done once

The standard objection is that writing takes longer than talking. At the moment of production this is true; across the lifetime of the information it is wrong by a wide margin, and the arithmetic is worth doing explicitly because the objection keeps returning until someone does. A decision explained verbally to four people costs an hour of collective time and then exists in five slightly divergent copies in five heads, degrading from the moment it is stored. The fifth person to need it — the new joiner in three months, the engineer in another timezone, the auditor next year — cannot reach it except by asking someone to reconstruct it from memory, which they will do inaccurately and with unwarranted confidence. Written, the same decision costs the author forty minutes and each reader three, is identical in every head, does not degrade, is searchable, and serves the twentieth reader at no extra cost. Break-even sits around the third or fourth consumer, and almost every decision worth making has more than that.

There is a second benefit people discount until they have done it. Writing a proposal forces the author to find out which parts of their reasoning do not survive contact with a sentence. A surprising proportion of meeting-based decisions are agreements to something nobody could have stated precisely, which is why they get relitigated. The requirement to write is a filter on thinking, applied before the organisation commits resources.

Documentation and decision capture are different artefacts

This is the distinction most organisations miss, and missing it is why documenting everything so often coexists with nobody knowing why anything was done.

Documentation describes the current state of the world: how the system works, how to run it, what the interfaces are. It is continuously updated to remain true, and an out-of-date document is a defect.

Decision capture describes a moment of choice: what was decided, when, what the alternatives were, what was believed at the time, and what would make you revisit it. It is never updated, because a record of a past decision edited to match the present is not a record of anything — superseded decisions are marked as superseded and left in place. Its readers are people about to change something, who want to know which fence they are removing.

	Documentation	Decision record
Answers	How does this work now	Why is it this way
Lifecycle	Continuously updated	Immutable; superseded, never edited
Out of date means	It is a defect, fix it	Nothing; that was the state of knowledge then
Typical reader	Someone doing a task	Someone about to change something
Failure mode	Silent drift from reality	Never written; reasoning lost

Architecture decision records are the well-known implementation of the second category, and their value sits almost entirely in the sections people are tempted to skip. Anyone can record what was decided; the useful content is the options rejected, the constraints in force at the time and the consequences accepted, because that is what tells a future engineer whether the constraint still holds. A record naming the chosen database is nearly worthless. A record stating that it beat two alternatives, that the deciding factor was an operational capability you already had, and that the accepted cost was a particular scaling ceiling, tells the next person exactly what evidence would justify revisiting it.

RFCs — the longer-form proposal circulated for comment before a decision — are the companion practice on the front end. The RFC is where the argument happens; the decision record preserves the outcome and the reasoning. Collapse the two into one document and you usually get a long thread and no conclusion.

Running a decision asynchronously

People revert to meetings because they have tried to decide something in a thread, watched it run for nine days without converging, and concluded that async does not work for decisions. What they ran was a discussion, not a decision, and discussions have no natural end. Decisions need four things a thread does not supply by default.

A named decider. One person, by name, who will make the call. Not a group, not a consensus, not "the team". Consensus is an outcome you may happily arrive at and a catastrophic process commitment, because it gives every participant an indefinite veto exercised by silence.

A written proposal with real options. Not a question. State the problem, the options genuinely under consideration including doing nothing, your recommendation and your reasoning. A thread opening with a request for thoughts generates opinions for a week; a thread opening with a recommendation and two rejected alternatives generates objections, which are more useful and far more finite.

A deadline, stated in the first message. Comment by this date and time, in a named timezone; afterwards the decider decides with whatever input arrived. This converts an open thread into a closing process, and it is the component most often omitted.

A silence rule. Say explicitly what silence means — normally that it is assent and that a missed deadline is a forfeited objection. This sounds harsh and is the kindest available rule, because the alternative holds conscientious people hostage to inattentive ones and moves everything at the speed of the least responsive participant.

Run this way, a decision that would have waited eleven days for a calendar slot closes in three, with a better-argued record than the meeting would have produced. Keep the deadline proportionate — two working days for a routine technical choice, a week for something architectural — and always at least two full working days in every participating timezone, so nobody is structurally excluded by the clock. Escalate to synchronous only when the thread reveals disagreement about framing rather than about options, which is the legitimate use of shared hours described in designing-timezone-overlap. Book thirty minutes, bring the thread, write the outcome back into it.

Chat is not asynchronous

This is the most consequential misconception in the field, and almost everyone who has recently adopted a chat tool and believes it made them async holds it.

Chat is synchronous communication with a delay tolerance. It is ephemeral, ordered by time rather than by topic, unsearchable in practice once past a few weeks, and it rewards presence: the people online when a thread happens participate, and everyone else finds a resolved conversation with no record of the reasoning. It also creates a low-grade expectation of immediate response that follows people across timezones, which is precisely the pressure asynchronous working is meant to remove.

A genuinely asynchronous artefact is addressable and durable: someone joining in six months can find it, read it in a sensible order and understand it without having been present. A chat thread fails all three tests. A document, an RFC, a decision record, a well-written issue, a recorded demo with a written summary: these pass.

Use chat for coordination, availability, quick lookups and the social texture distributed teams need. Do not use it for decisions, specifications, anything you will need to find again, or anything a person in another timezone must be able to participate in. The discipline that makes this work is slightly tedious: when a chat conversation starts turning into a decision, someone stops it and moves it to a durable artefact. That intervention has to be socially cheap, which means senior people have to do it visibly and often.

Recorded demos and the review loop

The sprint demo is the most-defended synchronous ritual in distributed delivery and one of the least defensible: a group watching one person click through software while an audience with muted microphones half-attends. As a use of scarce overlap it is close to the worst available.

Record it instead, and change its shape while you are at it. Short — a few minutes per item, not one long session. Narrated by the person who built the thing, focused on what a user can now do rather than on what was completed, and published with a written summary stating the change, its limitations, and the one or two questions the team actually wants feedback on.

The gain is not mainly time saved. A recording reaches people who could never have attended: stakeholders in other timezones, the support function, colleagues interested but not invited. Asynchronous feedback also tends to be better, because the reviewer can pause and think, and because the thoughtful person who never speaks up in a call will happily write a paragraph. What a recording cannot replicate is the live reaction of someone seeing the product for the first time and being visibly confused — an argument for periodic sessions with real users, not for a weekly internal demo call.

The read-culture problem

This is where most async programmes actually fail, and it is not on the writing side. Writing culture is the visible half. Reading culture is the half nobody builds, and without it the artefacts accumulate, go unread, and the organisation concludes that nobody reads documents. The conclusion is correct and the diagnosis is wrong: nobody reads documents because reading has never been made an expectation with a time budget, a norm and a consequence.

Give reading protected time. Unallocated, review time comes from the end of someone's day, which means it does not come at all. A protected block for reading and responding to open threads is a legitimate calendar item.

Make reading visible. An acknowledgement, a comment, a question, a recorded position — something that distinguishes read from not-seen. Silence-as-assent only works if there is a way to tell agreement from absence.

Keep the corpus navigable. A fifteen-page document nobody can navigate will not be read, and neither will a wiki with four thousand pages and no index. Length discipline, a summary at the top of anything longer than a page, consistent structure and ruthless archiving are what make the read side affordable.

Model it from the top. When a senior person responds substantively to a written proposal within a day, the organisation learns that writing works. When senior people only ever respond in meetings, everyone correctly infers that the meeting is where decisions really happen. This one signal outweighs every policy.

Stopping async from becoming silence

The fear is legitimate. Asynchronous can degrade into a state where a question sits for four days, nobody owns anything, and work stalls while everyone waits politely. That is not a property of asynchronous working; it is a property of asynchronous working without service levels.

The fix is explicit response expectations, tiered by urgency and treated as commitments rather than aspirations. Something blocking work needs an answer within a working day, with an escalation path — a named backup, then a synchronous interrupt — if it does not arrive. A proposal needs comments by its stated deadline. Ordinary discussion should take as long as it takes. Publish these, and treat a repeatedly missed blocking-question response as a management issue rather than an individual quirk, because it is one: someone has become a structural single point of answer, and the fix is to widen that.

Add a deliberate ownership rule. Every open thread needing a resolution has a named person responsible for closing it, and threads without an owner are closed rather than left drifting. Drifting threads are the visible residue of async done badly, and a team that clears them weekly feels entirely different from one that does not.

Finally, keep the synchronous escape hatch open and unstigmatised. Asynchronous-first does not mean asynchronous-only. When a thread is clearly not converging, the correct move is a thirty-minute call, and someone should be able to call it without feeling they have failed a doctrine. The discipline is not never meeting. It is that the meeting has a written input, produces a written output, and is chosen deliberately rather than by default.

What to do on Monday

Take the last significant decision your team made and try to find the record of it. Not the outcome — the reasoning, the alternatives, the constraints that applied. If you cannot find it in five minutes, or it exists only in a chat thread or someone's memory, you have measured your decision capture and the number is zero. Write that decision up retrospectively this week, honestly, including what you were unsure about. Half an hour, and it establishes the template.

Then take the next decision coming and run it asynchronously, properly. Name the decider. Write the proposal with real options and a recommendation. Set a deadline giving every timezone two full working days. State that silence is assent. Publish the outcome as an immutable record. Do this three or four times and it will start to feel normal even to the sceptics, because they will notice decisions closing faster than they used to.

Separately — and this is the part organisations skip — put a recurring block in your own calendar for reading and responding to written proposals, and respond substantively in it. If you are senior, do it visibly. The read side is where async programmes die, and it is fixed by behaviour at the top rather than by policy.