Asynchronous Communication

For most of the history of office work, anything work-related needed both people present at the same time. A question meant tapping the person at the next desk or calling them, and if they were in a meeting the work stopped until they came out. Sitting on the same floor made this look like a non-problem: the longest anyone waited was about half an hour.

The person who stopped working wasn't the only one paying. The asker thought of it as a one-minute interruption, but the person interrupted lost the thread of whatever they were holding in their head. An engineer who fields five of those questions in a day spends more time rebuilding context than writing code.

Then teams started working outside a single office and the arrangement stopped working altogether. A team split between Seoul and Berlin overlaps for an hour or two a day, and everything that needs both people has to squeeze into that window or wait until tomorrow.

The word comes from engineering, where an asynchronous call sends a request and moves on instead of standing still waiting for the reply. Applying the same name to how people talk carries the same intent: no one's work should be parked while an answer is in flight.

The whole mechanic is writing a message so the sender can keep working while the answer is on its way. Four things have to be in it.

1. Full context in one pass. Say what you were doing, where you got stuck, what you already checked, and what kind of answer you need. A bare "can you take a look at this?" only produces a reply asking which screen you mean.
2. Narrowed options. "Option A gives us this, option B gives us that, and I lean toward A" leaves the other person a choice to make rather than a problem to reconstruct. The cheaper the reply is to write, the sooner it arrives.
3. A deadline. A request with no by-when can't be prioritized by the person receiving it, so it slides to the bottom of the pile.
4. A default for the waiting period. One line — "if I don't hear back by tomorrow morning I'll go with A" — means a late answer doesn't turn into a stalled day.

All four exist to get the exchange down to a single round trip. In different time zones a round trip costs half a day, so a message that triggers two clarifying questions burns three days.

Where you write it matters just as much. A question answered in a private message gets asked again three months later by someone else. Put it somewhere searchable — an issue, a shared document, an open channel — and the exchange becomes something the team owns. That is also why documentation first, the habit of writing a thing up and circulating it before talking about it, tends to travel with asynchronous work: there has to be something to read before there is anything to answer.

It's the default for teams whose hours don't overlap, or whose overlap is too expensive to spend on routine questions. For a team doing remote work or spread across time zones there isn't really an alternative. A team that fixes a few hours of guaranteed overlap as core time runs the rest of the day asynchronously, and a team doing hybrid work needs the work to move even when nobody knows who came in today.

By the kind of work, three situations come up over and over.

1. Work that needs deep concentration. Engineering and design both cost twenty minutes of recovery per interruption. Batching questions into writing lets the person on the other end keep their own rhythm.
2. Decisions that involve a lot of people. Instead of pulling eight people into an hour-long meeting, someone writes up the background and options and collects opinions as comments. A product requirements document (PRD), which records what is being built and why, is usually where that conversation starts.
3. Recurring status updates. Plenty of teams run the daily scrum — the short daily sync on progress and blockers — as written posts instead of a meeting, and only the people actually blocked pair up afterward.

The places it fits badly are just as clear. Conversations with feelings in them, arguments where the two sides start from different premises, and early exploration of an idea with no shape yet all go much faster with synchronous communication. So does anything that moves minute by minute, like an outage — a ten-minute call beats twenty lines of writing.

"Let's keep this async. Drop your comments on the doc and I'll pull them together tomorrow morning."

A proposal to skip the meeting and handle it in writing, each person on their own schedule.

"If you're asking async, send the context with it. A bare 'please take a look' costs us another day of back-and-forth."

A request to put everything the answer depends on in the first message.

"Async is the default because of the time difference, and the one hour we overlap is only for things that need a decision."

An operating rule: shared hours are scarce, so they don't get spent on anything that works in writing.

At Pagedeck, Theo was implementing the screen-lock policy when he found a gap in the spec. Mia was in customer meetings all afternoon. Theo wrote an issue with the screen he was building, what he had already confirmed in the document, the two possible resolutions, and what each would do to existing users. He closed with "if I don't hear back by 11 tomorrow, I'm going with the first one," and moved to another task.

Mia read the issue between meetings and left three lines explaining why she picked the second option. Grace saw the decision in the same thread. The exchange took one round trip, and the reasoning stayed in the issue for the next person.

The most common misreading is that working asynchronously means abolishing meetings. Teams that adopt it do watch their meeting count drop, so the conclusion is easy to reach. What actually goes is the set of meetings that worked as writing anyway; the ones left get denser. Remove all of them and you get a document with forty comments on it and no conclusion two weeks later. What that document needs isn't more text — it's a decision making rule that says who closes the question and how, plus meeting hygiene tight enough to keep the meeting that closes it short.

The second mistake is treating an instant reply as basic courtesy. Fast answers feel like progress. But replying instantly means keeping notifications on all day, and a team doing that is asynchronous in name only — everyone is still tethered to the same stream. The thing to agree on is the deadline, not the speed. A team where people check messages twice a day and still answer within the stated window is working asynchronously. Miss this and the practice adopted to win back focused time ends up doubling interruptions instead.