Async communication that keeps distributed teams moving

The thread that took two days to settle a five-minute question

The worst async thread I was ever part of started with six words: "Quick one, thoughts on the export?"

I was working in Central European Time on a small product team. The product lead was six hours behind me, the designer was somewhere in between, and the question was genuinely small. Should the new export button download a CSV straight away, or open a dialog that let people choose a format? Someone had to pick before I could finish the ticket.

The designer saw the message in her morning and replied with a fair question: which export, the reports page or the admin one? I saw that in my late afternoon and answered. The product lead woke up, read the thread from the top, and asked whether we had looked at what customers had requested. Nobody had linked the ticket. I linked it the next morning. By then the designer had added a mock-up for a dialog that nobody had asked for, and the product lead had replied to the mock-up rather than to the question.

On the third day someone booked a fifteen-minute call. We settled it in about five. CSV now, dialog later if anyone asks. Everyone agreed it was obvious.

The question was never the problem.

The question was never the problem. The first message was. It had no outcome, no link, no options, no deadline, and no default. Every reply that followed was somebody rebuilding those missing pieces, one night at a time. Most of what I now believe about async work comes from that thread and the dozen smaller versions of it I have watched since, on remote teams and with freelance clients.

Why the first message decides how many rounds you pay for

On a team that shares an office, or even a time zone, a vague question is cheap. You ask, someone frowns, you clarify, and the whole exchange takes two minutes. The vagueness gets fixed in conversation.

Across time zones, each round costs a working day. If your colleague is eight hours away and you send something incomplete at 15:00, they read it in their morning, ask a question, and you see the question in yours. One missing link is one day. Three missing pieces is most of a week, and the work you were trying to finish sits there the whole time.

That changes the economics of writing. The extra four minutes you spend making a message complete is not politeness. It is the cheapest time anyone on the team will spend that week. I've found the best async writers are not the fastest repliers. They are the people whose messages almost never need a follow-up.

So most of this guide is about the first message: what goes in it, when it should be a meeting instead, when a reply is fair to expect, and where the answer should live so nobody has to ask again.

Sort the request before you send it: write, meet, or wait

Before anything leaves your hands, decide what kind of request it is. Most confusion comes from sending one kind dressed as another.

Information someone can read later is a written update or a comment on the document. If they cannot open the thing you linked, fix the permission. A meeting will not grant access.

A choice between options names A, B, your recommendation, and the UTC time the default applies if nobody comments. Meet only when one honest written round still leaves the choice tied. "Thoughts?" is the brief you skipped writing.

A blocker one person can clear goes to that person, with the step that proves it is cleared. Share a screen only when another screenshot would cost more than the overlap you have left.

Status belongs in the end-of-day note, not in a call where someone reads the ticket aloud. The buckets I use are in end-of-day status update.

Sensitive feedback is a scheduled one-to-one inside overlap hours. A public thread is the wrong room, and so is a chat message at the end of someone's day.

Three regions should move the work along overnight and save the decisions for the thickest pairwise overlap. A three-way call is for a conflict the relay could not close. The overlap maths is in timezone collaboration without chaos.

If writing the message reveals that nobody knows what the next move is, stop there. Fix the action before you book time. Thirty minutes on a call will not invent a missing owner.

It also helps to say the paths out loud as a team. Status goes to the ticket. A decision goes to the doc. A how-to goes to the runbook. A blocker goes to the named channel. An incident goes to the page. When those paths are missing, people fall back on "just ping me", and that habit has its own cost, which I wrote about in when "just ping me" replaces a system.

Hold the send until six fields are real

This is the habit that would have saved the export thread. Do not send while any of these is empty. Your delay of ten minutes is cheaper than a night of questions in the other zone.

The outcome, in one sentence. "Checkout" is a topic. "Choose the payment provider for PAY-200" is an outcome. If you cannot write the sentence, you are not ready to ask anyone else to think about it.

A deadline in UTC. ASAP is not a deadline, and "end of day" is three different instants on a team spread across three cities. If you cannot name an hour, you do not yet know whether this is a decision or a wish.

A link to the context. The ticket, the document, the pull request. If understanding the request needs history that only lives in your head or in a private chat, put that history on the ticket first.

Options and a recommendation. "Any ideas?" asks the reader to start their day on your thinking. If you have no options yet, ask for one experiment with a time box, and say so.

How you will verify. "Looks good" is not a verify step. A command, a click path, or a comment on a named ticket is. If you cannot describe the check, you will disagree later about whether the work happened at all.

What happens if nobody replies. The owner when the thread stays silent is you, carrying out a default you will really carry out. A bluffed default teaches people to wait for a meeting. "We will figure it out" is not a default.

The annoying part is that this feels slow the first few times. It stops feeling slow once you notice how many threads end after one reply.

Copy the six-field request template

Need: [one sentence outcome]
By: [deadline in UTC]
Context: [link to the ticket, doc, or pull request]
Options / recommendation: [A, B, and which you recommend, or "action only, no decision"]
How I'll verify: [the check that proves done]
If no reply by the deadline: [the default you will actually execute]

Paste the block and change the nouns. After a few weeks you stop needing the labels, but I still keep them for anything that crosses more than one time zone, because the labels make an empty field obvious before you press send.

A worked request, and the bump that follows it

Assumptions for this example: the team is choosing between two payment providers for checkout, the cost table and risk notes already live on the ticket, legal has not raised anything about either, and you will ship if the thread stays quiet.

This version produces five pings and a meeting:

Thoughts on checkout? ASAP thanks.

This one can sit overnight and still get answered:

Need: Choose payment provider A or B for PAY-200
By: Thursday 16:00 UTC
Context: PAY-200 (cost table and risk notes are on the ticket)
Options / recommendation: A has lower fees. B has stronger defaults for EU payment authentication. I recommend A.
How I'll verify: A decision comment on PAY-200 and the ticket owner updated
If no reply by the deadline: Ship with A. Revisit only if legal flags an authentication gap.

What usually happens next is one of three things. Someone agrees, and you are done. Someone disagrees with a reason, and you now have a real discussion with all the facts on the table. Or nobody replies.

When the deadline passes in silence, the default applies. Silence is not a veto and it is not extra time. If you think people genuinely missed it, send one bump with the same fields, a new UTC cutoff, and the default restated:

Bumping PAY-200. Same recommendation: ship provider A. New cutoff is Friday 16:00 UTC. If there is no comment by then, I will ship A and record it on the ticket.

A second bump with no new cutoff is a meeting request you have not earned. If one written round genuinely leaves two options tied and you would defend either, book a short live slot. Take it from the meeting budget in fewer and better remote meetings and do not let it grow into a standing series because one thread got stuck.

Afterwards, keep the record small: context, options, the choice, the owner, the date, and when you would revisit. A light pattern for that is in document team decisions without bureaucracy.

When a default must not apply on its own

Defaults are what make async decisions finish, but some of them should never fire automatically. If carrying out the default would spend money you cannot get back, run a database migration, or take a legal position nobody has read, write a different last line: "Do not ship. Book the next overlap slot."

This matters more than it looks. If a default quietly turns into a hold when the deadline arrives, people learn that defaults are bluffs and start ignoring the next one. Be honest at the moment you write the request about which kind it is.

Publish reply windows before chat habits form

"Always available" feels generous for about a week. Then a ping at 02:00 seems to expect a reply and an apology for the delay. The fix is boring: publish the window. A reply outside it is a favour. It must not quietly become the job. If a new hire cannot point to the sentence that says when replies are fair, you do not have a window.

During agreed overlap, chat is fair game and a same-day reply is the aim. Instant reply is a different product. If production needs instant reply, that is an on-call rotation, named and paid.

Outside overlap, the message has to be complete already, and the reply waits for the next overlap. Overnight silence means the system is working. A midnight nudge "in case you are up" means it is not.

Urgent is one named channel, or the contract phone number, for production that is down. A vague ask is not urgent because the sender feels stuck. Write down who may use that path: on-call may page, a Thursday demo may not, a client uses the number in the contract and nothing else. If urgency has crept into every message, available all day is a bad system is about exactly that problem.

Put the UTC range where people find it in their first week. Re-post it when the roster changes and in the weeks the clocks move, because Europe and the US change on different Sundays and your overlap shifts by an hour for a week or two. The wording I like for the windows themselves is in response expectations across time zones.

Three examples of windows that actually held:

A small engineering team. Six engineers, split between Berlin and New York, with a paid on-call rotation and everyone else off call. A P1 gets a reply within one hour inside overlap, or on the page path outside it. A P2 gets a reply on the next workday in the requester's zone. Everything else is a written request with a UTC deadline. "Can you look today?" is not a P2.

A freelancer with one client. The statement of work names email, and chat is not included. I check email at 11:00 and 16:00 local time, those two times are in the kickoff note, and a message at 18:30 waits until the next morning. Production down goes to the phone number in the contract.

Product and design sharing one doc. The Thursday overlap is about two hours. Comments are due at 17:00 UTC on Tuesday. A 25-minute slot gets booked on Thursday only if two options are still tied. Otherwise the recommendation is recorded and the default ships. A skipped comment is not a tie.

Put the answer where the next reader will look

A complete note in a place nobody searches is still lost. You will end up explaining it again, live, to someone who joined after the thread scrolled away.

Status lives on the ticket, or in one named channel, never both. Once that is true, the standup that reads tickets aloud can go. A lead can skim the Blocked filter in two minutes.

Decisions live in a doc with a comment deadline. If you have to use chat, keep one topic per thread, put the ticket link in the first message, and close the thread with a summary line. When you inherit a long thread, read the latest summary first, then the decision, then the open questions. Only read the full history when those disagree.

After you answer a new question once, put the answer in the runbook and reply with the link. The second time someone asks, they get the link only. It feels a bit cold the first time you do it. It stops feeling cold when the question stops coming.

A blocker with no named owner is yours until the ticket names one. "Waiting on someone" does not say who, or what done looks like.

Choose between a status note, one bump, or twenty minutes

When work is stuck there are really only three moves. Opening a fourth channel just splits one request across people who each see part of it.

You still own the work tomorrow. Write Done, Open, Blocked, and Next in one place, and link to it from everywhere else. The test I use is from how to write async status people actually read: could someone offline name your next physical move from the note alone?

A complete request has passed its deadline. Send one bump, same six fields, new cutoff, default restated. "Any update?" gets you "looking into it", which is not a decision.

The options are still tied after one honest round. Book twenty minutes, invite only the people who must decide, and write the choice down before anyone leaves. If you cannot say what the call will end with, you are not ready for it. Cut the choice in half and go back to the brief.

When ownership crosses a night, the handoff needs five things: the current state, proof of it, the next move, any blockers, and what not to redo. If the next person has to ping you before they can start, fix the proof or the next move before you log off. The longer version of that is in leave work someone else can continue.

Pick one cadence and keep it. On the teams where this worked best, it was an end-of-day note for the squad, a midweek note to the client with one decision request, and a Friday note with what was done and Monday's first move. Two homes for the same news means Monday morning is spent reconciling them.

Publish the norm as one short page

The norm is a page, not a culture deck. Paste this, replace the brackets, and change any line that is not true yet. A norm the team ignores trains people to skip the next one.

Write first. Meet only when one written round still ties a real choice.
Status: Done / Open / Blocked / Next in [location]
Overlap hours: [UTC range] on weekdays
Outside overlap: complete written request, reply next overlap
Urgent: [channel] for production down only
Decisions: doc, UTC deadline, default if silent
Handoff when ownership crosses a night: State, Proof, Next, Blockers, Do not redo

When someone new joins, walk them through it for thirty minutes on a real ticket and fill in the six fields together. A made-up ticket hides the hard part, which is finding the right link and committing to a default you will genuinely carry out. Tell them what overlap is not: it is not a promise of instant replies, and it is not the place to put status updates, because those are the only hours two cities share.

Redirect the private ping without being rude about it

Even with the page published, people will send direct messages with no ticket and no context. Most of them are not being careless. They are stuck and in a hurry. Redirect them where others can see, once:

Logged on TICKET-88 with options A and B. Reply there by Thursday 16:00 UTC. I will not track this in DMs.

Then do not also answer privately. A fast reply on the ticket is fine. A private answer buys a permanent exception, and the next person will ask privately too.

If "just ping me" is the existing habit, give it three weeks. In the first week, publish the paths. In the second, leads redirect in public with a link every time, including for friends. In the third, any question asked three times gets a doc section before Friday. Watch two numbers: repeat questions, and whether the newest person can file a complete request without help. Do not watch who answers fastest in chat.

The one number I check on Friday

Trying to fix everything at once is how these norms die. I pick one count for the week and fix that before Friday.

• Requests with no owner or no UTC date. Add the default, or send it back as not ready.
• Pings outside overlap. Re-post the hours and redirect once in public.
• Meetings with no pre-read. Cancel them, or require the link a day ahead.
• Repeated questions with no doc. Write the section and reply with the link only.

For freelance work, the equivalent is a single sentence sent at kickoff and repeated whenever it slips, including on a week when you happen to be free at 18:00:

I check email at 11:00 and 16:00 CET on workdays. Production down: call the number in the statement of work. Everything else gets a same-day reply inside those two checks.

Always-on is a different product. Price it or decline it. A launch-week exception needs an end date in the same sentence, and when it ends, restate the two checks.

Looking back at the export thread, nobody on that team was lazy or rude. Everyone replied within their working day. The system simply had no expectation that the first message would carry the decision, so each of us added one piece at a time and called it collaboration. Write the outcome, the deadline, the link, the options, the check and the default before you send. Meet when one honest written round still leaves a real choice tied. Publish the hours, so that sleeping in another country stops counting as a slow reply.