Async etiquette: working across time zones
Distributed teams that default to async ship faster — but only if everyone writes as if the reader is asleep when they send it.
It is 9 a.m. in Bangalore. A senior engineer opens Slack to find a thread from her Berlin colleague that started at 11 p.m. her time: “Hey, you there?” Followed by nothing. She types a reply. Berlin is now asleep. She waits. The thread sits open on her screen for the rest of the morning, a small cognitive tax on every context switch. By end of day she still does not know what her colleague needed. They schedule a call. The call surfaces a question that could have been resolved in two asynchronous messages.
This is not a Berlin problem or a Bangalore problem. It is a communication design problem. And most distributed teams never fix it because they treat it as a cultural inconvenience rather than an engineering challenge.
The core shift: write for the absent reader
In a co-located office, incomplete messages are cheap. You say “hey” and your colleague turns around. You say “can you look at this?” and point at your screen. The physical environment fills the gaps.
In a distributed team, every incomplete message starts a chain of waiting. A “hey, you there?” with no payload costs the recipient’s attention twice: once when they read it, once when they reply and wait for the actual question. If the time-zone gap is six hours or more, that two-hop exchange takes two full days.
The fix is not complicated: write every message as if the reader is asleep when you send it and will not wake up for eight hours. Ask yourself, before you hit send: does this message contain everything they need to act, without any back-and-forth from me?
That one question restructures how you write everything.
The Async-Ready Message: four elements
A message that travels well across time zones has four elements. Call it the ACDC pattern — Action, Context, Decision, and Confirm.
Action first. Start with what you need: a review, a decision, a status update, a specific question. “I need your approval on the revised scoping document before I send it to the client Friday” is an action statement. “Just wanted to touch base about the project” is noise.
Context second. Give exactly enough background for the reader to act without researching independently. Not your entire thought process — just the minimum viable context. If they would need to dig through a Jira ticket, six Slack threads, and last week’s spec to understand your question, you have not written the context; you have offloaded the work.
Decision or recommendation third. Do not ask open-ended questions when you already have a view. “Should we use Kafka or RabbitMQ?” forces the reader to do your thinking. “I recommend Kafka for this use case because of X and Y — do you agree, or do you see something I am missing?” gives them a position to react to. Reacting is faster than generating from scratch.
Confirm the ask explicitly. End with one clear action: “Please reply by Thursday EOD your time” or “No action needed — this is FYI.” Never leave the reader guessing whether they need to do anything.
Synchronous time is a scarce resource, not a default
Most teams get this backwards. They schedule standing calls to avoid writing things down. They pull people into video calls to share information that could have been a document. Then they wonder why everyone is exhausted and nothing is getting done.
Synchronous time has one irreplaceable property: real-time interactivity. It is the right tool for brainstorming where ideas build on each other in unpredictable directions, for difficult conversations where tone matters, for debugging sessions where two people need to be inside the same problem at the same moment.
It is the wrong tool for status updates, announcements, decisions with a clear recommendation, reviews of documents that could be read asynchronously, and anything where the core value is information transfer rather than interaction.
A useful rule: if the meeting would be fully useful to someone who watches a recording of it, it should not have been a meeting. Record a Loom video. Write a decision document. Post a status update. Save the live time for the work that cannot happen without it.
Write decisions down — every time
This is the one that teams resist the most because it feels slow in the moment.
A decision made in a call and not written down is not a shared decision. It is a shared experience, which is different. Two people can leave the same call with genuinely different understandings of what was agreed, and neither is lying. Memory reconstructs, emphasis shifts, and a week later nobody can explain why they chose option B over option A.
The discipline is simple: whoever runs a discussion owns the write-up. Not meeting minutes — a decision record. One paragraph: what was decided, what the alternatives were, and why this one won. Posted in the channel where the relevant team can find it. Linked from the Jira ticket or Linear issue it affects.
This feels like overhead. It is actually insurance against re-litigating decisions, onboarding new team members, and the specific misery of six months later asking “wait, why did we build it this way?”
Respect quiet hours — explicitly
Remote work has a quiet-hours problem that nobody talks about honestly. Because everyone’s notifications are technically always on, there is an implicit pressure to be available around the clock. A Slack message at 11 p.m. your time might be 7 a.m. for your colleague — a reasonable work hour. But it might also be midnight. And even if they do not reply, they often see it, and the seeing is the interruption.
The fix requires both structural and cultural work.
Structurally: agree on a team response-time SLA (Service Level Agreement) for async messages. Something like “we commit to replying to async messages within one business day in the recipient’s time zone.” Once the SLA exists, sending a message at an off hour stops carrying implicit urgency. The sender knows it will be read in the morning. The recipient knows there is no expectation to reply tonight.
Culturally: managers have to model this. If a manager sends messages at 11 p.m. and replies to them at midnight, the team reads that as a signal about expectations, regardless of any policy. The actual behavior of senior people in the team sets the ambient norm.
When you need to send something at an off hour, most Slack and Teams clients let you schedule delivery. Use that feature. It costs two extra clicks and removes the ambient pressure entirely.
The “no hello” rule is about respect, not rudeness
There is a small practice that makes an outsized difference: never open a Slack message with “hey” or “hi” or “you there?” without the actual content in the same message.
It sounds like a minor annoyance. In practice it is a power dynamic. The “hey” message signals: my time is more valuable than yours, so I will grab your attention now and make you wait to find out why. The recipient has to stop what they are doing, check the message, and then wait for the follow-up. Two interruptions for one exchange.
The rule is simple: if you would not walk up to someone’s desk and say “hey” and then stand there silently until they look up, do not send the message equivalent. Send the full ask. If the full ask is going to be long, send a brief one-line framing first and the detail in the same message, not in a follow-up that requires another round trip.
This is not about being cold or transactional. The warmth goes into how you write the full message, not into a placeholder opener.
Building a team agreement
Individual discipline matters, but async culture requires a team-level agreement to hold. Without explicit norms, individuals default to whatever they did at their last job, and you get a mixture of habits that clash.
A useful async working agreement covers five things:
First, the channels and their expected response times. Urgent issues go where. Async questions go where. Decisions go where. Social conversation goes where.
Second, the response SLA by channel. Not a vague “we try to reply quickly” — an actual number. One business day in the recipient’s time zone is a reasonable default for non-urgent async messages.
Third, how meetings are called. Who can call them, what the minimum required agenda is, whether an async alternative was considered.
Fourth, how decisions are documented. Who writes the record, where it lives, how it gets linked to the relevant issue tracker.
Fifth, quiet hours. What counts as outside normal hours for each team member, and the expectation that messages sent during those hours carry no implicit urgency.
This agreement does not need to be long. A shared doc with five sections, revisited quarterly, is enough. The value is not in the document — it is in the conversation you have while writing it, because that conversation surfaces the assumptions people were already making but never said out loud.
The harder truth
Async-first communication is harder at first than just calling a meeting. Writing a full-context message with a clear recommendation takes more time than sending a “hey can we talk?” It requires thinking before you communicate rather than thinking while you communicate.
But that cognitive cost is a transfer, not a net addition. You are moving the thinking from a shared synchronous moment — where it happens at the speed of the slowest participant — to individual asynchronous moments where each person can think at their own pace and in their own language if translation is involved.
The teams that get this right are not necessarily smarter or more disciplined. They have simply decided that the discomfort of writing well is a price worth paying for the freedom of not being chained to a calendar. That decision, once made and held consistently, compounds over months into a meaningfully different way of working.
The teams that never make it keep scheduling calls to discuss things they could have written down, and wondering why their distributed colleagues seem disengaged.