Async communication for remote work: rules that stick

Here is a message that arrives in a lot of remote teams every morning:

hey, got a sec?

It’s sent at 08:10 in London. The recipient is in Toronto, asleep. When they wake up, they reply “sure, what’s up?” The sender has gone to lunch. By the time the actual question surfaces, a working day has gone, and the answer took thirty seconds.

Async communication is the fix for that, and it’s less about tools than about a small set of habits everyone agrees to. This guide covers the habits, the rules that make them stick, and the point at which you should stop typing and get on a call.

What async actually means

Asynchronous communication is any exchange where the other person doesn’t need to be present at the same moment: a written update, a comment on a document, a recorded video walkthrough, a well-formed chat message that can be answered whenever the reader gets to it.

It doesn’t mean slow, and it doesn’t mean no meetings. It means the default is a message that stands on its own, and real-time conversation is something you choose for a reason.

The 37signals guide to internal communication puts the case in four words: “Writing solidifies, chat dissolves.” Their point is that substantial decisions belong in complete written thoughts, not a scroll of one-liners. That’s the spirit of everything below.

Rule 1: Every message must survive being read eight hours later

This is the rule that changes the most. Before you send, assume the reader will see it after you’ve logged off. Will they be able to act on it without asking you anything?

A message that survives has four parts:

1. Context. What this is about, with a link to the thing.
2. The ask. What you need from them, stated as a question or a request.
3. The deadline. When you need it by, and why.
4. Your default. What you’ll do if you don’t hear back.

Here’s the same request, before and after:

Before: “Can we chat about the Q1 plan?”

After: “On the Q1 plan (link), I think the launch date in row 14 is two weeks too early given the hiring gap. Can you confirm whether design can start on 5 January? I need to know by Thursday 17:00 UTC to update the board deck. If I don’t hear back, I’ll move the launch to 2 February and flag it in the deck.”

The second version is longer to write and much shorter to resolve. Nobody needs a call.

The “your default” line is the one people forget, and it’s the one that stops async from stalling. It gives the reader permission to stay silent if they agree.

Rule 2: Agree response-time tiers, in writing

Async falls apart when nobody knows how fast a reply is expected. Some people answer everything within minutes and burn out; others answer in two days and look disengaged. Neither is wrong without a shared norm.

Write the tiers down. A starting point for most teams:

“Working” hours means the reader’s, not yours. That one word removes a lot of guilt.

Rule 3: Send at the right time for the reader

Writing at 22:00 is your business. Sending at 22:00 makes it the reader’s business.

Most tools now let you schedule a message. Slack lets you schedule a message to send later from the send button, and Gmail has scheduled send too. Use it for anything you write outside the recipient’s working hours.

The other half is letting people switch off. Slack’s notification schedule means you only get notifications during the hours you choose, and calendar working hours (where your admin has enabled them in Google Calendar) show others when you’re around. Ask everyone to set both in their first week.

Rule 4: One topic, one place

Async needs messages to be findable later. That breaks down quickly when a decision starts in a direct message, continues in a channel and ends in a call.

Keep each topic in one thread, next to the work it relates to. A question about a document goes in a comment on the document. A question about a task goes on the task. A discussion goes in one chat thread, not five top-level messages. When a conversation does move (to a call, say), the person who moved it posts the outcome back in the original thread.

If you’re still choosing which tool handles which job, our guide to async communication tools sorts them by job.

Rule 5: Decisions get a written record

Every decision that changes someone else’s work gets a short note: what, why, who decided, and when. It lives where the work lives. This is the single habit that most separates teams who are good at async from teams who just have chat.

It also makes disagreement easier. Someone in another time zone can read the reasoning and object in writing before anything is final, instead of finding out after the fact.

Rule 6: Updates are pushed, not pulled

In an office, managers can walk round and ask how things are going. Remote, that becomes a stream of “any update?” messages, each one an interruption.

Flip it. Each person posts a short written status on a fixed rhythm (daily or a few times a week), covering what’s done, what’s next and what’s blocked. Managers read instead of asking. Our guide to managing remote employees covers how this fits into the weekly rhythm.

When to stop typing and talk

Async is the default, not a religion. Switch to a call when:

• The thread has gone back and forth three times without converging. Three rounds is usually a sign that the disagreement is about something nobody has written down.
• Emotions are involved. Difficult feedback, conflict, anything personal. Text strips tone, and the reader fills it in with the worst version.
• It’s genuinely urgent. If something is on fire, a call is faster than any thread.
• You’re brainstorming from scratch. Early-stage ideas benefit from quick back-and-forth. Write up the result afterwards.
• Someone new is struggling. A new starter stuck on something basic needs ten minutes of screen-sharing, not a link to a wiki page.

After the call, post a two-line summary in the original thread. Otherwise the call becomes the kind of corridor conversation async was meant to replace.

Rolling it out without a big launch

Rules announced in an all-hands memo tend to fade within a month. A lighter approach works better:

1. Pick three rules, not ten. Rule 1 (survives eight hours), Rule 2 (response tiers) and Rule 3 (send at the right time) change the most.
2. Run them for two weeks as a trial. Say it’s a trial. People engage more with something they can give feedback on.
3. Managers go first, visibly. If the team lead sends “got a sec?” messages, nobody else will change.
4. Review at the end of the trial. What helped, what was annoying, what to keep. Then write the survivors into your remote work policy or team handbook.
5. Add the norms to onboarding. New starters are the easiest people to teach, because they have no old habits to break.

One honest warning: async can feel slower for the first couple of weeks, because people are writing more carefully. The time comes back in fewer meetings and fewer clarifying messages.

Rules to paste into your handbook

OUR ASYNC RULES

1. Write every message so it can be acted on 8 hours later:
   context + link, the ask, the deadline, and what you'll do by default.
2. Never send "got a sec?" or "hi" on its own. Ask the actual question.
3. Response times (reader's working hours):
   - Phone / on-call page: immediately
   - Chat mention marked "urgent": within 2 hours
   - Direct message or mention: within 1 working day
   - Doc or task comments: within 2 working days
   - Updates and announcements: read within the week
4. Outside the reader's hours, schedule the message.
5. Set your notification schedule and calendar working hours.
6. One topic, one place. Discuss work next to the work.
7. Decisions get a written record: what, why, who, when.
8. Status is pushed on a fixed rhythm, never chased.
9. Three rounds without agreement, or anything emotional: take it to a
   call, then post a two-line summary back in the thread.
10. Review these rules every [6 months].