I have heard "we work asynchronously" a lot over the past few years. Whenever I looked behind the curtain, I usually found the same picture: people still waiting on each other, just in a more polite format. A message written in the morning sits unanswered until noon, work stalls, and in the afternoon a second message goes out asking "so what do you think?" That is not asynchronous work; it is delayed synchronous work. Async communication is not a tooling choice, it is a writing discipline — and the test is simple: does work move forward while the other person sleeps for nine hours?
The Only Real Test: Moving Without Waiting
Using a chat app does not make a team async. The measure is not the tool but how many steps forward a message moves its reader. When you write "could you take a look at this?", the other person wakes up holding nothing but a question, and starts waiting for you. Write the same message as "here is the state I see, here is the evidence, there are two options, I prefer the second one, and unless someone objects by Thursday 17:00 I am going with it" — and the other person wakes up holding a decision.
That "unless someone objects, I am going with it" pattern is not a bit of politeness decoration; it is a lock-release mechanism. The only thing that keeps work moving regardless of who happens to be awake is a default decision announced in advance. Teams that never write it down spend hours a day waiting on each other and then call it a "communication problem". The problem is not communication; it is that nobody can tell where the decision currently sits.
Most teams try to fix this from the wrong end, by promising a response time. A "we reply within four hours" rule looks orderly at first, but in practice it formalizes the waiting culture: nobody plans for the answer never arriving. The real lever is not shortening reply time, it is reducing the number of messages that block. If a message truly waits on an approval, it should say so explicitly — and also say what happens if the approval does not come. Everything else is information, and information should never stop anyone.
My Counterpart at 3 A.M. Was a Cron Job
Async discipline was not taught to me by a forty-person distributed team; it was taught to me by the automation that keeps this blog running. The repository currently holds eighteen separate GitHub Actions workflows; they generate content, deploy, queue social posts, and raise failure alerts. Most of them run while I am asleep, and they can only reach me in writing.
On the morning of 3 July 2026 I paid the price for that. A short-lived runner container hit a startup error because of a leftover configuration file from its previous run, and fell into a restart loop. The alert monitor then mailed the very same event once a minute, because the digest used to suppress duplicates contained a constantly changing time phrase. What waited for me in the morning was a choir repeating a single sentence all night.
The root fix landed in the repository three days later: commit 693b738e makes the runner clear the leftover file at startup. Normalizing the alert signature was a separate fix, and it lives outside this repository, on the monitoring side. That three-day gap was no accident either: the noise itself delayed the diagnosis.
The lesson of that morning was communicational. A notification that carries no state is noise. A pile of mail repeating the same sentence does not do as much work as a single message saying "this service has been exiting with this error since such-and-such a time, this command diagnoses it, here is the workaround". The equation is identical for human teams: the quality of a message is the number of decisions its reader can make without you.
Do Not Kill the Meeting, Make It Earn Its Place
The trap async advocates fall into is declaring meetings the enemy. The production meeting described in Google's SRE book is the most mature model I know here: the meeting is weekly, runs somewhere between 30 and 60 minutes, the chair rotates among team members, and attendance is compulsory for all members of the team. The book does not offer the agenda as a prescription; it says plainly that "it's not appropriate to be prescriptive" about how to run these meetings, and only suggests a default agenda: upcoming production changes, metrics, outages, paging events, nonpaging events, and prior action items.
The subtle part is how the agenda gets built: it is filled in in advance and in parallel, in a shared document everyone can edit at the same time. The meeting is not where the agenda is discovered; it is where previously written context turns into decisions. The same chapter offers one more rule for distributed meetings that I like. When two teams meet by video and one is noticeably larger than the other, the book recommends placing the chair — the person running the agenda, not a piece of furniture — on the smaller side of the call by default; the larger side then settles down on its own. The authors are honest enough to add that they have no idea whether the technique has any scientific basis, but it does tend to work. Handing that role to the sparser side changes who gets the floor without a long culture debate.
From that model I took a single rule and I stick to it: an item without written context does not get on the agenda. It sounds strict, but someone too lazy to write an item down has usually not thought it through either.
Decisions Live in the Record, Not in the Chat
A chat channel is not an archive; it is a stream. Three weeks later, nobody finds the answer to "why did we do it this way?" there, because what sits in the channel is the noise around the decision rather than the decision itself. Architecture decision records exist precisely to fill that gap: an ADR captures a single decision and its rationale, along with its trade-offs and consequences. I covered architecture decision records in detail in an earlier post; the remote-team version of that discipline is this: a decision belongs to the record that stores it, not to the channel that debated it.
The recording surface itself is a design question. What makes tools like GitHub Discussions useful is not their social features but the archive hygiene they push you toward: discussions are opened in user-defined categories, a comment can be marked as the answer in question-and-answer categories, a discussion that has reached a conclusion can be locked, and an open-ended issue can be converted into a discussion. All of it serves one question: six months from now, how will a newcomer tell the right answer from the wrong ones?
The twin of recording discipline is notification discipline. If you announce everything you write to everyone, people mute you quickly — and from that moment on, nothing you write gets read. I keep the distinction simple: a piece of text either wants someone to do something today, or it is a record someone will look for tomorrow. The first one tags a single person and says what it wants in the opening sentence; the second one sits on the recording surface without tagging anyone. Trying to make one piece of text do both is the most common silent waste I see in remote teams.
A Handoff Ends With an Explicit Acknowledgment
The most expensive failure mode in remote teams is the lost handoff: work that one person thinks they put down and another thinks they picked up drops off both radars. That is why I like the rule from the incident management chapter of the SRE book: the outgoing incident commander should be explicit in the handoff, state plainly "you're now the incident commander, okay?", and not leave the call until they receive firm acknowledgment.
I covered the discipline of shift handoff during an incident in a separate post on the incident decision log; the concern here is calmer but sneakier — the daily handoff across time zones. The async translation of that sentence is one line: silence is not consent. A handoff is completed by "I have it", not by "I sent it". In a team spread across time zones, a handoff note also has five obvious things to carry — where I stopped, what it is waiting on, which risk is still open, what the next step is, and when I am awake again. Do not skip the fifth one; it is the answer to "who do I find if this becomes urgent?"
Where the Default Decision Stops
The default-decision pattern is as abusable as it is powerful; in the wrong hands it becomes an excuse for manufacturing authority out of silence. That is why I bound it with two questions.
The first is reversibility. What may go ahead unopposed at 17:00 on Thursday is what can be rolled back with a single command the next morning: a configuration change, a piece of copy, a priority order. Things that cannot be undone — data migrations, permanent deletions, spending commitments, promises made to outsiders, changes with security or compliance impact — draw no authority from silence; they require explicit approval. For those items, the date you wrote is the deadline for the reminder, not for the decision.
The second is how you pick the deadline. I look at two things: the time-zone gap, meaning the other side must have had at least one full working day to see the message; and the cost of rollback, meaning the more expensive the undo, the longer the window and the more explicit the approval. If the one person who owns the topic is on leave, the clock does not run at all; who can decide in their place should be written in the handoff note.
And when a default turns out to be wrong, the person to look for is not the one who wrote the message. A default that goes wrong usually means the classification was off: something assumed reversible turned out not to be. That is what the post-mortem is about.
The Exception to the Rule: The Incident
Async discipline turns harmful when it becomes an ideology. Expecting everyone to write at their own convenient hour while production is burning does nothing but stretch the outage. Every mature model switches to synchronous here — without giving up the written trail.
PagerDuty's incident response guide separates the roles explicitly: the incident commander (IC), a deputy who is both a hot standby and a check on the IC — tracking timers that have been started, bringing back items missed in a roll call, and managing the call itself, a scribe who documents the incident timeline and captures important decisions as they happen, a subject matter expert for the affected service, a customer liaison for external communication, and an internal liaison for organizational stakeholders. Google's SRE book draws a similar split — command, operational work, communication, and planning — and makes maintaining the living incident document, editable by several people concurrently, the commander's essential responsibility.
When you switch to synchronous, the writing discipline does not disappear; it becomes a role. The scribe is the live form of async culture during an incident. When it is over, the team is left with a written timeline rather than a memory of what was said — and the next meeting's agenda is born from exactly that.
A Checklist
Ask your own setup these questions; every "no" is a day when someone will be waiting on you.
- Does every request message carry state, evidence, options, and a default decision?
- Is there a recording surface where decisions live, or is the chat channel mistaken for an archive?
- Is the meeting agenda filled in the shared document before the meeting?
- Do handoffs close on explicit acknowledgment, or is silence treated as consent?
- Do alerts carry state, or do they just say "something is wrong"?
- Are the threshold for going synchronous and the scribe role defined in advance?
- Does the handoff note include a "when I am awake again" line?
Conclusion
Async discipline is not an etiquette rule invented for the comfort of remote work. It is the habit of writing system state out of people's heads — and the real payoff shows up not in your colleagues but across time. Three months from now, the person hunting for the rationale behind that decision is most likely not someone else on the team; it is you. Writing well in a remote team is a courtesy extended to your future self; the team just gets the side benefit.
