What is async communication?

Communication that does not need the other person to be available when you send it, such as a written update, a task comment, a recorded demo or a posted decision. The work keeps moving while the reader is busy, and they answer when they are next working.

What is a reasonable response time for async messages?

Agree on one per channel and write it down. A common ladder is next working day for task comments, same working day for team chat, a few working hours for something that blocks someone, and a phone call for real emergencies.

What should not be done asynchronously?

Disagreements that one written round did not settle, sensitive feedback, anything about a person’s performance, incidents in progress, and first conversations with new people. A short call handles these better than a long thread.

Is chat async communication?

It can be, if nobody expects an instant reply. Chat that everyone must watch all day behaves like a meeting. Use chat for conversation and keep the work itself, with its decisions, on a board or in a document people can find later.

Async Communication: Rules for Teams That Rarely Meet

Async communication works when a team agrees what goes in writing, how fast each channel gets an answer, and where work lives. What to move out of meetings, a response-time ladder, how to write a message that settles things in one round, and why the board beats the thread.

September 30, 20267 min read

Async communication is any exchange where the other person does not have to be there when you send it: a written update, a comment on a task, a recorded walkthrough, a decision posted for people to read later. It works when a team agrees on three things. First, what goes in writing by default and what still needs a live conversation. Second, how fast each channel gets an answer, so silence is never a mystery. Third, where the work itself lives, which should be a board everyone can read, not a chat thread that scrolls away. The rules for each are below, with a message format that settles most questions in one round.

This page is about the system: channels, response times and where things go. For individual rules worded so a team can adopt them, see team norms examples; for running a small remote team as a whole, see managing a remote team.

What async communication is, and what it is not

GitLab’s communication handbook (opens in a new tab) defines it as “the art of communicating and moving projects forward without the need for additional stakeholders to be available at the same time your communique is sent.” The important part is the second half. Async is not just “send a message instead of calling.” A chat message that expects a reply within two minutes is a meeting with worse audio. The test is whether the work can keep moving while the reader is busy, asleep or out.

Async: a written proposal with a deadline for comments, a task with the problem and the plan written down, a recorded demo, a weekly written update.
Sync: a call, a live meeting, a chat conversation where both people are typing at once.
Not quite either: a chat channel everyone is expected to watch all day. It has the interruptions of sync and the lost context of a thread.

What goes async and what stays live

Default to writing. Keep a short list of things that are worth a live conversation, and make everything else earn its meeting.

Async by default

Status updates. Nobody needs to hear them read aloud. The daily standup post covers how to run the update in writing.
Proposals and plans. Write them, give people until a named day to comment, then decide.
Questions that can wait a few hours. Most can.
Decisions, once made. Post what was decided, who decided and why, so people who were not there are not left out.
Handoffs between time zones. The person finishing their day writes where things stand and what the next person should pick up.

Worth a live conversation

Anything with real disagreement after one written round. A second round of long messages rarely settles it; fifteen minutes on a call usually does.
Feedback that could hurt, and anything about a person’s performance or wellbeing.
Incidents in progress, where minutes matter.
The first conversation with someone new: a new hire, a new client, a new collaborator.

Response times: one ladder, written down

Most async friction is not about slow replies. It is about not knowing how slow is normal. Write a ladder, one line per channel, and put it where new people will read it.

A response-time ladder for a small team

Channel                     Expected reply        Use it for
Task comment on the board   Next working day      Anything about a piece of work
Team chat channel           Same working day      Questions, quick coordination
Direct message              Within 4 working hrs  Something blocking you
Phone call or text          Right away            Customer-facing outage, safety
Email (outside the team)    2 working days        Clients, vendors, partners

Replies are measured in working hours, not clock hours. A message sent at 6 p.m. Pacific to someone in Boston is answered the next morning, and that is on time.
Say so when you cannot answer yet. “Seen, will reply Thursday” resets the clock and costs ten seconds.
Urgent means one channel. If anything can be urgent in any channel, people learn to watch every channel all the time, and focus goes. GitLab’s handbook puts the baseline plainly: “There is no expectation to respond to messages outside of your planned working hours.”
Send late, deliver on time. If you write after hours, schedule the message. Slack lets you schedule messages to send later (opens in a new tab), and most email clients do the same.

Writing a message that settles it in one round

The cost of async is round trips. Every “which one do you mean?” adds a day when people are in different time zones. A message that answers the reader’s obvious questions in advance saves those days. Four parts cover most of it:

Context in one or two sentences: what this is about and why now.
The ask, stated as a question someone can answer: approve, choose, review, or tell me what I am missing.
By when, and why that date matters.
The default. What you will do if nobody replies by then. This is the part most people leave out, and it is what keeps work moving when a reader is out.

Name who does what. Digital.gov’s plain language guide (opens in a new tab) says “Active voice makes it clear who should do what,” and in a message nobody can ask about in real time, that clarity is the difference between an answer and a follow-up question.

A message built to need one reply

Context: The checkout page still rejects 9-digit ZIP+4 codes.
Two customers wrote in about it this week.

Ask: Should we fix it before Friday's release, or ship the release
and fix it next week? The fix is small but touches the address form.

By: Thursday noon Eastern, so there is time to test.

Default: If I don't hear back, I'll include the fix and test it on
staging Thursday afternoon. Details are on the task, BUG-087.

Boards over threads

Chat threads are good at conversation and bad at memory. A decision made in message 34 of a thread is invisible a week later, and a task mentioned in passing belongs to nobody. The fix is a simple split: talk in chat, keep work on the board.

Every piece of work is a task on the team board, with the problem written down. If a thread produces work, someone files the task before the thread goes quiet and posts the link back.
Discussion about a task happens in the task’s comments, so the next person to pick it up reads the whole story in one place.
The board’s lanes are the status. Nobody should need to ask “where is this?” when the answer is which lane it is in.
Decisions go to one place where they are kept, not into whichever thread they happened in. A decision log is enough.

This is also what makes async work for people who join late. A new teammate can read the board and the decisions in an afternoon. Nobody can read three months of chat.

Time zones and working hours

Publish your hours. With a work or school account, Google Calendar lets you set working hours (opens in a new tab) so people can see when you are available before they invite you.
Hand off in writing at the end of the day: what moved, what is stuck, what the next person should look at first.
Rotate the inconvenient meeting time instead of always asking the same time zone to stay late.
Put deadlines in one time zone and say which: “Thursday noon Eastern,” not “Thursday noon.”

Async work on a fenbs board

fenbs is built for the board side of this. Each task has a note for the problem and a plan for how it will be done, so the context travels with the work rather than living in a thread. Comments sit on the task. The lanes, To Do, Next Up, In Progress and Completed, answer “where is this?” without anyone asking, and History records who changed what, person or AI assistant.

Decisions go on the Decisions and rules page, with who decided, when and why. A rule is a decision that holds from now on, and every connected AI assistant reads the rules first, so an assistant working at 2 a.m. follows the same agreements as the team.
fenbs does not send activity email or digests, so the board never pings anyone. People check it at the times the team agreed, which is the point of async.
Copy as Markdown, below the board, copies every lane as text for a written update in chat or email.
To bring in someone who is not on the board, Ask someone on the task adds them by email with a role and posts your question as a comment on it. They get one email with a link to the board.

What fenbs does not do: there are no due dates, no assignee field you can set and no reminders, so deadlines and owners go in the task note, and the response-time ladder stays in your team’s own agreement.

Signs async is not working

The same question gets asked in chat every week. The answer should be written down once and linked.
People reply at 11 p.m. to show they are keeping up. The norm about working hours is not being modeled by the people who set it.
Meetings keep coming back because written proposals get no replies. Add a deadline and a default to every proposal.
Work is discovered in threads instead of on the board. Whoever sees it, files it.

Individual rules to adopt: team norms examples. The one-page agreement: team working agreement template. Written standups: standup meeting questions. A small team working apart: managing a remote team. Notes every AI assistant reads: AI context.