team
Asynchronous communication usually gets adopted as a reaction. The calendar filled up, someone counted the hours spent in meetings, and a rule was announced about writing things down instead. Three weeks later the meetings are back, plus a chat channel that now has to be read.
The reason is that async is not a tool choice or a meeting ban. It is a decision about response time, and it only works when four things have been settled: how long a reply is allowed to take, where a decision is recorded once it is made, what triggers a switch to a live conversation, and which exchanges are never going to work in writing. Skip any of the four and the result is the worst of both shapes, where nothing is answered quickly and nothing is written down either.
Synchronous means both people are present at the same time. Asynchronous means the sender does not wait. That is the whole distinction, and it is smaller than the cultural arguments built on top of it.
What follows from it is the part that matters. If the sender does not wait, the sender needs to know when an answer will arrive, because otherwise the only safe behaviour is to chase. A team that says it works asynchronously but has no agreed response window has not removed the waiting, it has made the waiting invisible. The person who needs an answer now will walk over, call, or send four messages, and the interruption everyone was trying to avoid comes back through a side door.
So the first artifact of an async team is not a tool. It is a written sentence about how long a reply may take, per channel. A comment on a task might be answered by the end of the next working day. A direct message might be same day. An alert channel might be within the hour. Whatever the numbers, the point is that they exist and everyone knows them, so waiting stops being a judgement about whether a colleague is ignoring you.
The reason this is worth the effort is that the time involved is not marginal. Atlassian's write up of async practice puts figures on both the meeting load and the cost of switching between things:
The average office worker joins up to 12 one-on-one calls per day and wastes one hour and 42 minutes each week on scheduling tasks. In the US, $1.85 billion a week is lost on unnecessary meetings and scheduling tasks. Source: atlassian.com
The same piece puts the cost of each context switch at an average of 20 minutes, which is the number that makes the meeting count matter. Twelve interruptions in a day do not cost twelve meeting lengths. They cost the meetings plus the recovery, and the recovery is where the work that needed concentration was supposed to happen. A change in how information is exchanged is therefore not a productivity tweak at the margins.
Most async initiatives fail because they treat all communication as one thing to be converted. It is not. There are four kinds of exchange and they behave differently in writing.
| Kind of exchange | Works async | Why |
|---|---|---|
| Broadcast: status, decisions made, information anyone might need later | Yes, and better than live | Reading takes a quarter of the time of listening, and it can be found again |
| A question with one correct answer | Yes | The answer is a fact, so nothing is lost by writing it |
| A decision with real trade-offs and more than two people affected | Partly | The options can be written; the choosing benefits from being live |
| Disagreement, difficult feedback, anything about a person | No | Tone is carried by things text does not have, and the cost of being misread is high |
The first two are where the hours are. A weekly status meeting where eight people take turns describing their week is broadcast, and it converts to writing with no loss and a large saving. A question about which branch to deploy from has one right answer and does not need a calendar entry.
The third one is where judgement is required. Writing the options, the constraints and the recommendation asynchronously is nearly always worth it, because it forces the thinking to be explicit and lets people who are not in the room contribute. The choosing itself often goes faster in fifteen minutes on a call, once everyone has read the same thing.
The fourth should be protected rather than converted. Delivering critical feedback in writing saves the sender discomfort and transfers it to the recipient with interest.
Write the response window down, per channel. Not as a value, as a number. Anyone waiting should be able to check whether they are owed an answer yet. Publishing the numbers also gives people permission to not answer immediately, which is what actually reduces the always on pressure.
Decide where a decision lives before you need one. This is the rule that gets skipped and it is the one that causes the most damage. A decision made in a chat thread is discoverable for about three days. After that it exists only in the memory of whoever was in the thread, and the same question gets asked again in a month. The fix is mechanical: when something is decided, it is written on the thing it affects. Not summarised in a weekly digest, not pinned in a channel, but attached to the task or the card the decision changes, where whoever picks that work up will see it without searching.
Name the escalation path. Async fails badly when something genuinely urgent is sitting in a queue with a next day response window. Every team needs one channel or one signal that means this cannot wait, and a shared understanding of what qualifies. Without it, people hedge by treating everything as urgent, and the windows stop meaning anything.
There is a fourth rule worth borrowing from published guidance on async practice, which is to settle the ground rules explicitly rather than letting them emerge. Slack's own write up on the subject recommends exactly the response window rule described above, phrased as a commitment that new messages are always answered by the end of the next working day, and pairs it with a separate space for conversation that is not about work so that off topic threads do not compete with the ones people are waiting on. It also makes a point that is easy to skip: because people read these channels on personal phones, the security arrangements need revisiting at the same time, and that is a decision for whoever owns the data rather than for the team adopting the practice.
The structural mistake in most async setups is that everything goes into chat. Chat is excellent at one thing, which is reaching people who are not looking. It is poor at the thing teams rely on it for, which is holding a record.
A useful way to hold the distinction is that chat is a river and the task is a shelf. Things in a river go past. Things on a shelf stay where they were put. A question about a task belongs in the river. The answer belongs on the shelf.
In practice that means three habits. Status goes on the card, as a field or a column position, not as a message. Reasoning goes in the card's comment thread, so someone reading the card in six weeks finds out why it was scoped the way it was. Only the nudge goes in chat, and the nudge points at the card.
This is also the point where tooling either helps or gets in the way. If the chat tool and the work tracker are separate products, moving the record onto the shelf is a copy and paste that somebody has to remember, and remembering is the first thing to go in a busy week. If a message can reference a card directly, and the card's comments are the same surface the team already reads, the record accumulates without anyone maintaining it. That is the difference between an async policy that survives a quarter and one that survives a fortnight. How a product connects conversation to the work is visible on its Features page, and the comparison set shows which products treat chat as part of the workspace and which leave it to a separate tool.
An async default is not a target of zero meetings. Four things are cheaper live and should be defended.
Anything where the goal is to reach a shared understanding of a problem nobody has framed yet. Early scoping conversations are fast in a room and slow in text, because the useful moves are interruptions.
Disagreement. Two rounds of written exchange is the point to stop and talk. Written disagreement escalates, because each side reads the other's brevity as coldness.
Feedback about a person's work. Always live, always with the written summary afterwards rather than instead.
Deliberate social time. Async teams lose the incidental contact that makes the rest of the communication cheap. Replacing none of it produces a team that is efficient and brittle.
Pick the recurring meeting with the most attendees and the least discussion, usually a status meeting. For two weeks, replace it with written updates posted on the relevant cards by a fixed time, and keep a fifteen minute slot at the original time for anything that came out of the reading.
Set two things down before the trial starts, or the result will be unreadable. The first is what counts as an update, because "post an update" without a shape produces either one line or an essay. Three prompts are enough: what moved, what is blocked, what somebody else needs to decide. The second is who reads them, named rather than assumed, because an update nobody is accountable for reading is a report filed into a drawer and the meeting will be reinstated on the grounds that writing did not work.
Two things will become clear quickly. The first is how much of the meeting was broadcast, which is the saving. The second is which exchanges genuinely needed the room, which is the list of things to stop trying to convert. Teams that run this test usually keep a shorter version of the meeting rather than deleting it, and that is the right outcome.
Write down the response window for each channel this week, then decide where a decision gets recorded and make that the same surface the work already lives on. If the record currently lives in a chat tool that nobody scrolls back through, moving it onto the cards themselves is the single change that makes the rest hold, which is why chat sits beside the boards in Pinateca rather than in a separate product.
There is no correct number, only a published one. A common pattern is same working day for direct messages, end of the next working day for comments on tasks, and within the hour for a named urgent channel. What matters is that anyone waiting can check whether an answer is overdue without guessing.
No. It means a meeting has to earn its place. Framing a problem nobody has defined yet, resolving disagreement, and giving feedback about someone's work are all faster and safer live. The meetings worth removing are the ones where people take turns reporting information that could have been read.
On the thing the decision affects, which is usually the task or card, rather than in a chat channel or a separate document. A decision in a chat thread is findable for a few days. A decision in a card's comments is found by whoever picks up that work, without anyone needing to remember where it was discussed.
Almost always because the record step depends on someone copying information from chat into the tracker, and that step gets dropped when the week gets busy. The second common cause is a missing escalation path, so genuinely urgent items sit in a queue, and people respond by treating everything as urgent again.
It works better there than anywhere, because the alternative is one side taking calls outside working hours. The requirement is stricter though: response windows have to be written in a shared reference rather than assumed, and handoffs need enough context that the next person does not have to ask a clarifying question and wait a full day for the reply.