Why async-first beats meetings
Most distributed teams have inherited their meeting culture from in-office work and bolted Zoom on top. The result is the worst of both worlds: the cognitive overhead of meetings without the casual side-channel that made the meetings feel productive in the first place. People sit on video for hours, agree things verbally, then rediscover the same agreement two weeks later because no one wrote it down.
Async-first inverts the default. Writing is the primary medium. Meetings are reserved for the small set of conversations that actually need them: high-stakes decisions with unclear inputs, conflict, kickoff, and trust-building. Everything else is a doc, a thread, a recorded Loom, or a pull request comment.
The math is unfavourable to meetings before you even count the time. A one-hour meeting with six senior people costs roughly $600 to $1,200 in direct compensation, not counting context-switch tax. Conservative estimates put the context-switch overhead at 15% of the meeting time on either side, so the loaded cost is closer to $800 to $1,500 per meeting. Multiply by the number of meetings on a calendar in a week and you get a number that should be in any cost-of-goods conversation.
The case for writing is not that writing is cheap. Writing well is hard, slower than talking, and emotionally exposing. The case is that writing is leveraged. A well-written doc gets read by ten people instead of three. It gets re-read in six months when someone joins the team. It compounds. A meeting evaporates the moment it ends, leaving only the partial notes one person managed to take.
Try the calculation yourself with our meeting cost calculator. Most teams underestimate the bill by 2x.
The four message types
Every internal message you send falls into one of four categories. Labelling them explicitly — in the first line, before the body — is the single highest-impact change a team can make. It tells the reader what they owe you and when.
1. FYI
"FYI" means "no action expected". You are putting something on the record so people can search for it later. Examples: a customer escalation that you handled, a small architecture decision, a notable blog post you read. The reader scans it, decides if it is worth their attention, and moves on. They do not need to reply, and you should not chase them if they do not.
Failure mode: people post FYIs that are actually decision requests, then complain no one responded. If you want an answer, label it as a decision request.
2. Decision request
"Decision" means "I need a yes or no from a named person, by a deadline". The body should contain the recommendation, the alternatives considered, the reasoning, and the timestamp by which silence will be taken as approval. Tag the decision-maker explicitly.
Good example: "Decision: ship the new pricing page Monday. @rachel, please ack by Friday EOD London time. Alternative is to wait two weeks for the legal review, which I think is overkill given X and Y." The reader knows what they are being asked, by whom, and by when.
3. Status update
Status messages report progress. They go in the format: what shipped since last update, what is in progress, what is blocked. They are routine and they should be boring. The discipline of writing them weekly forces you to actually know your own state, which is more value than the message itself.
Status updates should not turn into discussion threads. If something in a status update requires a decision, break it out into a separate decision request.
4. Question
"Question" means "I am stuck and need help". Good questions explain what you are trying to do, what you tried, what you expected, and what you actually saw. They do not start with "quick question" — there are no quick questions if the answer requires the recipient to load context.
A question with bad context becomes a back-and-forth that eats half a day. A question with good context gets answered in one response. The asker carries the burden of providing context, not the answerer.
Writing better Slack and Discord messages
There is a craft to writing chat messages well. It is closer to writing telegrams than emails: you have one shot to be parsed, and your reader is scrolling past fifty other messages.
Lead with the ask. The first line is what the reader is being asked to do. Context comes second. Reasoning comes third. If your reader stops reading after line one, did they still know what they owed you?
One thought per message. Six rapid-fire messages in a channel is six notifications. Take thirty extra seconds and combine them into one well-structured message. Use line breaks inside the message instead.
Use threads aggressively. Channels are bulletin boards. Threads are conversations. Anything that needs more than one reply belongs in a thread. This stops a channel from becoming an unreadable wall.
Mention the deadline. "By Friday EOD your time" is more useful than "end of week". "In the next hour" is more useful than "asap". ASAP is a synonym for "I do not know when I need this" and it forces the reader to interrupt their day to ask.
Reference, do not retype. Link to the doc, link to the PR, link to the issue. Re-summarising kills the link between conversation and source of truth. Two weeks later, no one will remember which Slack message contained the latest spec.
Pick the right channel. If your team has not set up channels by topic — engineering, product, customer escalations, social — do that first. A single #general channel is a guarantee that important messages get missed.
When to escalate to a meeting
A meeting is the right tool in three situations and only three. Recognising them early saves you the meeting that should have been a doc.
Conflict resolution. If two people disagree and the disagreement has run for more than three rounds in writing, get them on a call. The bandwidth of voice — tone, hesitation, the small concessions that signal a shift — is much higher than text. Conflict in text tends to harden into entrenched positions because everyone is performing for the audience.
Unclear inputs to a high-stakes decision. If the decision matters, the cost of getting it wrong is large, and you cannot tell what people actually think from the doc comments, get the small group in a room. The goal of the meeting is to surface the uncertainty, not to vote.
Kickoff, retros, and trust-building. Some conversations need to happen face to face because the goal is relationship, not output. Project kickoffs where the team needs to start trusting each other. Retros where people need to say difficult things and feel heard. One-on-ones. These should be small, focused, and regular.
Everything else is doc-shaped, thread-shaped, or Loom-shaped. "Status meeting", "all-hands update", "quick alignment", "sync on the spec" — almost every recurring meeting on a calendar can be replaced by a written equivalent. If people refuse to read the written equivalent, the problem is not the medium, it is that no one is being held to the standard of reading.
A clean test: before scheduling any meeting, write the agenda as a doc. If the doc covers it, send the doc. If the doc requires real-time discussion to land, schedule the meeting and attach the doc as pre-reading. Attendees must arrive having read it. People who routinely show up without reading are not contributing proportionally to their cost.
Time-zone etiquette
Distributed teams across more than four hours of zone difference get most of the cost without most of the benefit unless the etiquette is right. A few load-bearing norms.
Rotate the awkward slot. If your team has a regular call that lands at 7am for one person and 7pm for another, rotate it every six weeks. The same person should not always take the bad hour. This is true for product teams, engineering teams, leadership teams, all of them. If you cannot rotate, ask whether the meeting is genuinely needed.
State the time zone every time. "3pm" on its own is useless in a distributed team. "3pm London / 10am New York / 7am San Francisco" is useful. Better yet, link to a shared meeting scheduler or include the time in everyone's zone in your message.
Respect the working window. If a colleague's last working hour is 6pm their time, do not send a decision request at 5:45pm and expect an answer same day. Either send it earlier, or accept the next-day reply. Be particularly careful with messages that look casual but secretly require a response.
Use "do not disturb" religiously. Every chat tool has it. Configure it for outside your working hours and trust that your colleagues will respect it. If they do not, escalate that as a team-norm issue rather than letting it slide.
Record the call. If you have one person who consistently cannot make the overlap window, record the meeting and post a written summary with the key decisions. The summary is the deliverable, not the recording — most people will not watch a one-hour recording even if it is there.
Default to handoffs, not parallel work, across big zone gaps. A team split between SF and Singapore has zero practical overlap. Trying to collaborate in the same hour will burn one side out. Better: structure the work so SF hands off to Singapore at their end of day, Singapore hands back at their end of day. The team ships 24-hour days.
Tools we recommend
There is no shortage of tools. The stack below is the small one we keep coming back to.
- Notion for docs, wikis, and shared specs. The team handbook lives here. Decisions get written up here. It is also the least bad solution for nested docs with embedded databases, which is what most team handbooks become.
- Loom or Riverside for short recorded videos. Sometimes a 90-second screen share is faster than a paragraph. Make this an available tool, not a replacement for writing — Looms are not searchable and they do not compound.
- Linear or Jira for tracking work. Linear is faster, opinionated, and built for engineering teams. Jira is more flexible but heavier. Whichever you pick, every meaningful unit of work should have a ticket, and every ticket should have an owner and a date.
- Slack or Discord for chat. Slack for most teams. Discord if you have a community alongside the team. Either way, build the channel taxonomy deliberately and clean it up quarterly.
- Calendly for scheduling. External meetings, recruiting calls, customer demos. Two-way calendar sync, time zone aware. Stops the dozen-message back-and-forth.
- Reclaim.ai for protected focus time. Auto-blocks deep work, rolls habits forward when meetings displace them, and reschedules conflicts. Pays for itself the first month.