Async communication: a practical guide for teams

Cancelling meetings and hoping for the best rarely works. What works is a handful of agreements about speed, channels and writing that let people get on with their day without waiting on each other.

By the VeoRec team · Oct 3, 2026 · 12 min read

Async communication means you send a message without expecting the other person to be there at the same moment, and they answer when it fits their work. That is the whole definition. The hard part is everything around it: how quickly is "when it fits"? What if it is urgent? How do you stop a simple question turning into a three-day thread?

This guide is for team leads and the people who end up writing the team's working agreements. It covers the reply-time norms that stop async from feeling slow, how to write messages that can be answered in one pass, how to choose between writing, a recorded video and a call, how to make decisions without a meeting, and a charter template you can copy.

What async communication is, and what it is not

Async is a default, not a ban. The team at 37signals puts it as "real-time sometimes, asynchronous most of the time" in their guide to how they communicate, and that framing is useful because it keeps live conversation available for the moments that need it.

Nor does async have to be slow. A well-run async team often moves faster than a meeting-heavy one, because work does not stall until Thursday's sync. A question posted at 9:00 with full context can be answered at 9:40 by whoever knows. The same question saved for the weekly meeting waits six days.

The opposite failure is a team that is "always on". If people feel they must watch chat all day in case something arrives, you have built a meeting that never ends. The point is to protect long stretches of focus. Microsoft's 2023 Work Trend Index reported that 68% of people surveyed said they do not have enough uninterrupted focus time in the workday. Async norms are mostly about giving that time back without leaving anyone stuck.

• Async: a written update in the project channel, a comment on a design file, a five minute screen recording explaining a pull request, a proposal document with a comment deadline.
• Sync: a call, a meeting, a chat conversation where both people are typing back and forth in real time, a quick tap on the shoulder in an office.
• Neither by nature: chat. It can be used either way, which is exactly why it causes most of the trouble.

Agree how fast each channel needs an answer

One person assumes a chat message means "answer now". Another reads chat twice a day. Both are reasonable, and both end up annoyed with each other by Wednesday. The fix is boring and effective: decide, per channel, how quickly a reply is expected, and write it down.

Use the table below as a starting point. Change the numbers to fit your team; what matters is that everyone uses the same ones.

Two rules make the table work. First, urgent things have one loud channel, and it is not chat. If something is on fire, call or page. That lets everyone else turn chat notifications down without fear. Second, people show their working hours. Microsoft's 2025 report on the "infinite workday" found nearly a third of meetings now span multiple time zones. If your colleague in Lisbon can see that your day ends at 17:00 in Chicago, a silent evening is not a snub.

Chat needs a few extra rules because it blurs the line between sync and async. Reply in threads, so a channel reads as a list of topics rather than one long scroll. Keep one topic per thread. Send the whole message at once instead of five fragments, because each fragment is a separate notification. And if a chat thread passes ten replies without converging, stop: either write a short summary with a proposal, or book fifteen minutes and post the outcome back in the thread.

Write messages that can be answered in one pass

In a meeting, a vague question gets clarified in ten seconds. Async, the same vague question costs a round trip, and with people in different time zones a round trip can be a whole day. So the unit of quality in async work is the message that can be answered without a follow-up question.

A one-pass message has four parts:

1. The ask, up front. What do you need from the reader: a decision, a review, an answer, nothing?
2. Context they do not have. Links to the ticket, the doc, the screen. What you already tried. What changed.
3. Options, if there are any. "I'd go with B because it ships this week" is far easier to answer than "what should we do?".
4. A deadline and a default. "If I don't hear by Thursday noon, I'll go with B." Defaults keep work moving when people are busy.

The widget shows the same request written twice. Flip between them and notice how many questions the first one forces the reader to send back.

"Do you have a sec?" is the most expensive sentence in remote work. It interrupts the reader, tells them nothing, and guarantees a second message. Just ask the question.

Choose between writing, a recording and a call

Async does not mean everything is text. It means the receiver chooses when to engage. Within that, you have three formats, and each is good at different things.

A useful test: if you would need to share your screen to explain it in a meeting, record it instead (screen recording vs screen sharing covers the exceptions). If you would need to read it twice to answer, write it. If you suspect the conversation will go five rounds in comments, or someone might be upset, talk.

Take a real week. On Monday a designer wants feedback on a new onboarding flow: that is a recording, because the reviewer needs to see the screens in order and hear why each one exists. On Tuesday the team needs to agree a release date: that is a short written proposal with a deadline. On Wednesday a developer and a product manager disagree for the third time about scope: that is a call, followed by a two-line written summary. Same team, same week, three formats, and none of them is a recurring meeting.

Length matters too. Reading is faster than listening for most people: a 2019 meta-analysis by Marc Brysbaert put average silent reading of English non-fiction at about 238 words a minute. Speech runs slower. The widget below shows what that means for a message of a given length.

For a full decision guide with worked examples, see video, text or meeting: how to choose.

Use video where the screen does the explaining

Short recordings fill the gap between a long written explanation and a meeting. A three minute walkthrough of a checkout bug, with your cursor pointing at the broken field and your voice explaining what you expected, replaces a page of steps and a 30 minute call. The viewer can watch it when they are ready, pause, and replay the tricky part.

A few habits make work recordings worth watching:

• Say the point in the first ten seconds: "The coupon field breaks checkout on mobile; I need someone from payments to look today."
• Show, do not read. If you are reading text off the screen, the reader would rather have the text.
• Keep it under five minutes. If it runs longer, split it or add chapters so people can jump.
• Put the ask in writing next to the link, so people who skim the channel still see it.

In VeoRec's Chrome screen recorder, the video uploads while you record and the share link is already copied when you stop, so posting a recording takes about as long as posting a message. Every recording gets an automatic transcript, which matters for async: people who prefer to read can, and the content becomes searchable later. Viewers can leave timestamped comments, so feedback lands on the exact moment it refers to instead of in a separate thread.

If you have never recorded a work update, how to script a screen recording covers the hook, context and ask structure that keeps them short.

Make decisions without a meeting

Decisions are where async teams most often fall back to meetings, usually because nobody knows when a comment thread is "done". You can fix that with structure. Amazon is the well-known example: Jeff Bezos described in his 2017 letter to shareholders how the company uses written six-page memos, read silently at the start of meetings. The meeting still happens there, but the thinking is in the document. Async teams take the next step and let the discussion happen in the document too.

1. Write a short proposal One page: the problem, the options you considered, your recommendation and what you need from readers. Link evidence; do not paste it in.
2. Name the decider One person decides. Everyone else advises. Without a decider, async decisions drift until someone books a meeting.
3. Set a comment window For example, "comments open until Wednesday 17:00 UTC". Long enough for every time zone to see it twice.
4. Respond to objections in the doc The author answers questions in the comments or updates the proposal. If two people disagree on the same point after two rounds, that point (not the whole proposal) goes to a 15 minute call.
5. Record the decision where people will look Close the comment window with a short note at the top: decided, by whom, why, and what happens next. Link it from the task or channel.

The step people skip is the last one. A decision that exists only in a comment thread will be relitigated in three months by someone who never saw it.

Here is what that looks like in practice. A team needs to choose whether to drop support for an old browser version. The engineering lead writes a one-page proposal on Monday: the support cost, the share of sessions it represents from their own analytics, two options (drop it now, or drop it after the next major release) and a recommendation. She names the product manager as decider and opens comments until Wednesday 17:00 UTC. Support asks how many paying accounts would be affected; she adds the number to the doc. Sales objects that one large customer is mid-renewal; that single point goes to a fifteen-minute call on Wednesday morning, which ends with "after the renewal closes". On Wednesday evening the product manager writes three lines at the top: decided, after the renewal, owner, date. Nobody sat in a one-hour meeting, and the reasoning is still there in a year.

Keep a few meetings, and make them earn their slot

An async-first team still meets. It just meets for things a document cannot do: building trust, untangling a messy problem, resolving disagreement, celebrating. The 37signals guide calls meetings a last resort, not a first option, which is a good bar.

For the meetings that remain:

• Send the agenda and any pre-reading at least a day ahead. If there is nothing to read, ask whether the meeting is needed.
• Use the time for discussion, not status. Status goes in writing before the meeting.
• Take notes in a shared doc during the meeting, with decisions and owners at the top.
• Record or summarise it for people who could not attend, and say where the record lives.
• Leave gaps between meetings. A small Microsoft EEG study found stress built up across back-to-back video meetings, while short breaks between them kept it level.

If your calendar is the problem rather than the occasional meeting, how to reduce meetings on a remote team walks through an audit you can run in a week.

Write the norms down in a team charter

Norms that live in people's heads drift apart within a month, and new joiners guess. A one-page charter fixes both. It is not a policy document; it is a short list of agreements that anyone can point to when expectations clash.

Copy the template, fill the brackets with your team, and pin it where people look. Review it after four weeks: which rules did people actually follow, and which ones did everyone quietly ignore?

Spot the ways async goes wrong

Teams that try async and give up usually hit one of a few predictable problems. Each has a fix that is cheaper than going back to a full calendar.

Everything is marked urgent

If the loud channel gets used for ordinary questions, people stop trusting it and start watching every channel again. Fix: managers model the norm. When a lead sends a non-urgent request through the urgent channel, someone should say so, kindly and in public.

Messages disappear into silence

People post a question, nobody answers, and the author concludes async does not work. Usually the message had no named owner. Fix: mention the one person you need, not the channel. "Can someone look at this?" is addressed to nobody.

Context lives in too many places

A decision in chat, the spec in a doc, the feedback in email, the bug in a video comment. Fix: pick one home per type of work (tasks in the tracker, decisions in a log, discussion next to the thing being discussed) and link from everywhere else to it.

People feel isolated

Pure text all day can feel cold. Fix: keep a social call that has no agenda, and use short videos with your camera on for updates that would otherwise be dry. A face and a voice carry tone that text loses.

Hard conversations get pushed into text

Async makes it easy to avoid the uncomfortable call: critical feedback becomes a careful comment, a missed deadline becomes a brief note in the channel. Text strips out tone, and readers tend to fill the gap with the worst interpretation. Fix: agree that performance feedback, conflict and bad news start live, one to one, and only the follow-up goes in writing.

Use the scorecard below to see where your team stands today. Tick what is already true.

Roll it out in a month

Do not announce "we are async now" and cancel everything on Monday. Change one habit a week, and let people feel the time come back before asking for the next change.

1. Week 1: reply times Agree the table of channels and reply times. Move urgent issues to one loud channel. Ask everyone to set their working hours.
2. Week 2: status out of meetings Replace one status meeting with written or recorded updates. Keep the slot in calendars, but only for discussion that comes out of the updates. The async standup template is a good format to start with.
3. Week 3: one async decision Pick a real decision that would normally get a meeting. Run it with a proposal, a decider and a comment window. Log the outcome.
4. Week 4: charter and review Write the charter from what actually worked. Ask the team what still feels slow or noisy and adjust the numbers.

Record the update instead of booking the meeting VeoRec records your screen, voice and camera in Chrome and copies the share link when you stop. Viewers need no account, and every video gets a transcript. See VeoRec for async updates

What to do next

Pick the smallest change with the biggest effect for your team. For most teams that is writing down reply times per channel, because it removes the low-level anxiety that makes people watch chat all day. Then take your noisiest recurring meeting and ask: what part of this could be read or watched beforehand? Move that part out, keep the discussion, and see how much of the slot you still need.