team
A team becomes asynchronous the moment two people stop being at their desks at the same hour. That happens with a contractor two time zones away, with a parent who logs off at five and picks up again at nine, and with anyone who blocks out a morning to finish something hard. Most teams reach that point long before anyone decides to "go async", and the thing that starts to hurt is rarely the delay itself. It is that work stops moving while everyone waits for an answer that was already given somewhere nobody thought to look.
The useful version of async communication is narrower than the phrase suggests. It is not a policy about meetings, and it is not a preference for writing over talking. It is a set of habits that make a message readable hours later by someone who was not there, so the next person can act without asking for a summary first.
Picture the handover. Someone opens the laptop, sees forty unread messages across five channels, reads all of them, and still cannot answer one question: what changed since yesterday, and is anything waiting on them. Nothing in that pile was badly written. The problem is that a chat channel records the conversation, not the outcome. A thread with eleven replies ends with a decision embedded in message nine, phrased as "yeah let's do that then", and no one reading it tomorrow can tell whether that was agreement or thinking out loud.
This is why teams that add more channels feel slower rather than faster. The volume goes up, the searchable record of decisions does not. Three months later, when someone asks why the release date moved, the honest answer is that it moved in a thread that has since scrolled out of anyone's memory.
The correction is not more discipline in chat. It is deciding, once, which artifact holds the current state of the work. A board, a schedule, a task with an owner and a date. Chat then becomes the place where reasoning happens, and the board becomes the place where the result lands. Teams that get this right still send plenty of messages. The difference is that nobody has to read the conversation to know the state of the work.
Most sync versus async arguments come from treating all communication as one category. It is not. Sort each exchange by two questions and the answer is usually obvious.
The first question is whether anyone is blocked. If the next step of someone's work cannot start until an answer arrives, the exchange has a deadline, and that deadline has to be stated. The second question is whether there is real disagreement in the room. Aligning on something everyone already accepts is fine in writing. Resolving a genuine split between two people who each think the other is wrong is slow and corrosive in writing, because tone is the first thing text loses.
| Type of exchange | Live or written | Where the outcome belongs |
|---|---|---|
| Status of a task, no dispute | Written, no reply needed | The task itself, as a state change |
| Question blocking someone today | Written, with a stated deadline | The task, plus an answer in the thread |
| Choice between two workable options | Written first, live only if it stalls | A decision note on the task or board |
| Real disagreement between people | Live, small group | A written summary posted afterward |
| Feedback on unfinished work | Live or a recording | The revised work, plus the request |
| Anything about a person's performance | Live, one to one | Not in a shared channel |
The middle rows are where teams lose the most time. A choice between two workable options gets escalated to a meeting because writing it down feels like effort, and then six people spend forty minutes on something one person could have decided with a paragraph of context.
Unbounded waiting is the actual cost of async work. Someone asks a question at four in the afternoon, has no idea whether the answer comes in an hour or on Thursday, and either sits on the work or starts something else and loses the thread. The fix is cheap: say when the answer is needed and what happens if it does not arrive.
Three windows cover almost everything. No reply needed marks an update that exists so the record is complete. Next working day covers most questions that are not urgent, and gives the reader permission to finish what they are doing. Today, and here is what happens otherwise is the only form of urgency worth using, because it forces the sender to name a default: "if nothing comes back by five, the smaller scope ships and the rest moves to next week."
That last part matters more than the deadline. Naming the default converts a question into a decision that has already been made provisionally, which is a very different thing to hand someone. A question with a stated default stops being a blocker. The work proceeds on the default, the answer either confirms it or changes it, and nobody is idle in between. Teams that adopt only this one habit usually find that half of what they called urgent was not.
Fixed short events are the other half of the answer, and they are worth borrowing even outside software. The Scrum Guide describes the Daily Scrum as a 15 minute event for the developers on the team, held at the same time and place every working day. A short, predictable, non negotiable slot is what lets everything else be written, because there is always a known point at which anything stuck gets unstuck.
The most common async failure is a message that technically contains information but forces a round trip to become useful. "Quick question about the invoice flow" is one. A screenshot with no sentence attached is another. So is "any thoughts?" on a document that is nine pages long.
An update that does not create waiting has four parts, and they fit in a short paragraph. What changed since the last update. What is blocked, and on whom. What was decided, stated as a decision rather than as a discussion. What needs an answer, from whom, by when. Anything that does not fit one of those four slots is context, and context goes below, where the reader can skip it.
Two further habits do a lot of work. Name the person, not the channel, when an answer is needed from a specific human, because a question addressed to everyone is addressed to no one, and a channel of eight people will reliably produce eight people each assuming somebody else has it. And put the conclusion in the first line. Readers who are behind will read the first line of thirty messages before they read the third line of any of them, so a message that builds to its point gets filed as background.
Recordings help in one narrow case: showing something on screen that would take four paragraphs to describe. They hurt everywhere else, because a six minute video is six minutes for every viewer and cannot be skimmed, searched, or quoted. When a recording is the right call, the message around it still needs a written summary and a stated ask.
Async work does not mean fewer conversations. It means the conversation stops being the system of record. That separation is the difference between a team that can absorb a late reply and one that cannot.
In practice this means that when a task moves, the task moves, and the message about it is optional commentary. When a date changes, the date changes on the schedule, and the reason goes in a note attached to it. A team whose kanban, schedule and discussion sit in one place has an easier time here than a team stitching a chat tool to a separate tracker, because the second arrangement asks every person to update two systems and most people update one. The board view a team picks matters less than whether it reflects reality, and having several views of the same work available without a migration removes the usual excuse for not updating anything.
There is a related question about how much of this can be automated. Pulling a status summary out of a board on a schedule, or letting a person ask for one in plain language, removes the daily round of people asking each other where things stand. That is worth setting up once the board is actually current, and not before, because an assistant reading a stale board produces confident summaries of work that already changed.
Honest accounting matters, because the enthusiastic version of this advice sets teams up to fail. Writing takes longer than talking. A decision that takes eight minutes of conversation can take two days of messages, and for anything with real disagreement in it, those two days produce a worse decision as well as a slower one.
New people suffer most. Someone in their first month does not know what the team's shorthand means, which channel a question belongs in, or whether their question is stupid. A written culture that is comfortable for the people who built it can be close to unusable for the person who joined last week. Pairing them with one named person for the first weeks costs less than the alternative.
There is also a fairness question that hides inside the word flexible. If the team's real decisions happen in a window that suits one time zone, the people outside it are not working asynchronously. They are working late. Rotating the live slot, or accepting that some decisions get made without everyone, is a choice worth making on purpose.
Finally, distance accumulates. A team that never talks stops reading each other generously, and text is a poor medium for repairing that. A message that would have been read as dry in person reads as annoyed on a screen, and the reply comes back a little sharper, and within a week two people who agree about the work are having a conflict about tone. Keeping one recurring conversation that has no agenda is not a perk. It is maintenance.
None of these costs argue against working this way. They argue for naming which parts of the work are deliberately staying live, so that the written parts can be written properly rather than apologetically.
Pick the one artifact that holds the current state of the work, tell the team that this artifact is the answer to any question about where the work stands, and stop answering that question in chat. Then add the reply window to every request for a week and watch how much of the supposed urgency disappears. If the state of the work currently lives in three places, consolidating the board, the schedule and the discussion into one is the cheaper move, and Pinateca keeps kanban, Gantt, calendar and timetable views plus chat on the free tier for up to five people and ten boards.
Name one channel for genuine urgency, keep it narrow enough that people can leave notifications on for it, and require that every message in it states what breaks and by when. If the same person uses it three times a week, the problem is not the channel, it is that something upstream has no owner.
No. It means meetings carry the things writing is bad at: real disagreement, feedback on unfinished work, and conversations about people. A short fixed daily slot plus a weekly session for decisions that stalled in writing covers most small teams, and everything else can be a message.
Set the expectation in the message rather than in a policy. Most questions can carry a next working day window, urgent ones should state a default that lets the work continue without an answer, and anything with no deadline should say so explicitly so the reader can leave it until later.
Treating chat as the record. Decisions get made inside threads, nobody can find them a week later, and the team concludes that async does not work when the real problem is that no artifact was ever made responsible for the current state of the work.
Yes, and often for the same reason. Being in one room does not mean being interruptible, and a team that writes down decisions can give people long uninterrupted stretches without anyone losing track of what changed while they were heads down.