Marcus pings Sarah at 4:47 PM: “quick sync tomorrow?” No agenda, no context, no hint at what he needs. Sarah spends the rest of her evening quietly guessing whether she’s in trouble, then rearranges her morning around a 30-minute call that turns out to be a two-paragraph update she could have read in ninety seconds.
That message cost about an hour of two people’s time and delivered nothing that writing couldn’t have delivered better. Most teams have a dozen of these a week and never count them.
The real cost of always-on communication
Microsoft’s research on what it calls the infinite workday found that the average knowledge worker is interrupted by a meeting, an email, or a ping roughly every two minutes during core hours. The same analysis clocked 117 emails and 153 Teams messages per person, per day. That’s not a communication problem you can solve by responding faster. It’s a volume problem.
Distributed teams bend the shape of it further. Microsoft also found meetings starting after 8 PM up 16% year over year, driven by cross-time-zone collaboration, with 30% of meetings now spanning multiple time zones. When a team runs from London to San Francisco, every “quick sync” costs somebody their evening.
Managers already suspect most of it is waste. When Leslie Perlow and her co-authors surveyed senior managers for Stop the Meeting Madness, 71% said meetings are unproductive and inefficient. And the teams that have gone furthest in the other direction report the opposite: in GitLab’s Remote Work Report, 52% of remote workers said they are more productive than they were in an office. GitLab runs one of the largest all-remote companies on the planet, and it publishes the async handbook it uses to do it.
So the diagnosis is easy and everybody agrees on it. The hard part is the next sentence, and almost nobody says it out loud: most of this needs to be written well, not held live. People already believe in async work. What trips them up is that nobody ever actually taught “just post an update” as a skill, so a badly written update ends up generating more meetings than it prevents.
If your team is distributed, the failure compounds. Our guide to the challenges of managing remote teams covers the wider set of problems, and effective communication with remote teams covers the broader remote-communication picture. This post is narrower on purpose: it’s about the specific written artifacts that replace specific meetings.
Which moments should be async, and which need a live conversation
Every vendor with a chat product will tell you to move more work into their channel. Take that advice with the appropriate suspicion. The honest version is that async is the right default for a large share of workplace communication and exactly the wrong choice for a small, high-stakes share of it, and the skill is knowing which is which before you type.
Default to async when the work is informational, reversible, or needs a trail
Three conditions push a moment toward writing. The first is that the content is informational: you’re transferring facts, status, context, or a record, and the receiver’s job is to understand, not to negotiate. The second is that the decision is reversible. If choosing wrong costs you a week and a rollback rather than a quarter and a lawsuit, you don’t need everyone in a room to feel safe.
The third condition is the one teams underrate. If the thing you’re saying will need to be remembered, cited, or re-checked later, it belongs in writing regardless of how convenient a call would be right now. Verbal decisions have a half-life of about two weeks. Teams that make a call on a Zoom and never write it down tend to re-litigate the same call a month later, with two people confidently remembering opposite outcomes and neither of them wrong.
Default to sync when there’s disagreement, irreversibility, or a relationship at stake
Now the other side, and this is the part the tool vendors structurally cannot tell you. Close the laptop and get on a call when any of these are true:
- There’s real disagreement to work through. Two people who genuinely see a problem differently will not converge in a thread. They’ll escalate in tone, harden their positions, and generate forty comments that a twenty-minute call would have resolved. The moment you notice a thread going in circles, the thread has already failed.
- The decision is expensive and hard to undo. Restructuring a team, killing a product line, changing someone’s comp. If being wrong costs a quarter, spend the hour.
- The relationship needs attention. Performance concerns, conflict between teammates, disappointment, apology, anything where the other person’s emotional state matters as much as the information. Text strips tone, and tone is the entire payload.
- The other person is new, junior, or stuck. Async assumes shared context. When there isn’t any yet, writing just moves the confusion into a document.
The pattern underneath all four: async is for transferring information, sync is for changing minds and repairing trust. When your goal is the second one, the oral communication skills that carry tone, pause, and real-time reading of the room do work no document can replicate. The mark of a healthy async culture is which live conversations survive: only the ones that genuinely needed to happen live, with everybody showing up awake because their calendar isn’t full of status meetings.
One practical test before you send: if a reasonable teammate could read what you’re about to write and act on it without asking you a single follow-up question, it can be async. If they’d have to ask, either fix the writing or book the call.
That test is really a test of one skill. Assess your written communication skills to see how clearly your updates land before you ask a whole team to run on them. The nine templates below are that skill, pre-loaded.
9 templates for the moments that actually recur
Each of these exists to prevent a specific way async communication breaks. Copy the block, fill the brackets, delete the fields that don’t apply, and send. Brackets are prompts, not sacred structure.
1. The async status update
Most status updates are written to prove work happened, which is why nobody reads them. This one is written so a busy stakeholder can find the one line that changes their plans.
Subject: [Project name] status, week of [date]
Status: [On track / At risk / Blocked]
Shipped this week:
- [specific thing, one line]
- [specific thing, one line]
In progress: [what you're working on, with expected finish date]
Changed since last update: [scope, timeline, or owner changes. Write "No changes" if none.]
Blocked on: [what you need, from whom, by when. Write "Nothing" if nothing.]
Needs a decision from you: [the specific question, or "Nothing this week"]
Full detail: [link to doc or board]Fill tip: Readers skim for what’s different, not for what’s the same. Put the delta above the accomplishments; that’s the job the “Changed since last update” line is doing.
2. The project handoff
You’re going on leave, switching teams, or passing a project to someone else. The receiver will spend their first two weeks either productive or archaeological, and this document decides which.
Handoff: [project or task name]
From: [your name] To: [receiver's name] Effective: [date]
What this is: [one sentence a stranger could understand]
Current state: [what's done, what's half-done, what hasn't started]
Your next action: [the single next thing to do, and by when]
Where everything lives: [links to docs, repos, boards, folders]
People to know: [name, role, what they care about]
Decisions already made, please don't reopen:
- [decision] because [one-line reason]
- [decision] because [one-line reason]
Known traps: [the thing that will bite you, and how to avoid it]
Open questions: [anything unresolved, and who can answer it]
I'm reachable for questions until [date].Fill tip: Skip “Decisions already made” and the receiver will cheerfully reopen a debate the team spent six weeks closing. Include it, and you save them a month.
3. The decision doc
A call has been made. This template is backward-looking: it exists to create the record, not to gather opinions. Write it within 24 hours of the decision, while the reasoning is still in your head.
Decision: [the decision, stated as a completed choice]
Date: [date] Decider: [name] Status: DECIDED
Context: [what problem forced this call, 2-3 sentences]
Options considered:
1. [option] - not chosen because [reason]
2. [option] - not chosen because [reason]
3. [option] - CHOSEN
Why we chose it: [the reasoning, including the tradeoff we're accepting]
What this means for you: [concrete changes, by team or by person]
Objection window: If you think this is wrong, reply in this thread by [date and time]. After that, we're moving.
We'll revisit this if: [specific, observable condition]Fill tip: The objection window is the whole point. It gives dissent a real door and then closes it, so the decision stops being quietly relitigated in DMs for the next month.
4. The async standup
If your daily standup is fifteen people listening to thirteen updates that don’t affect them, you’re paying a real salary cost for a ritual. Post this instead, in a channel, before you start work.
[Your name] - [date]
Yesterday: [what actually moved, not everything you touched]
Today: [the one thing that matters most, plus anything else]
Blocked: [what, who can unblock it, how long you've been stuck. Write "Nothing" if nothing.]
Confidence in my current deadline: [High / Medium / Low] because [reason]Fill tip: Nobody volunteers “actually, I’m going to miss this” out loud in a live standup. Writing it down is what the confidence line is for. If you’re curious why the live version dies in the first place, we’ve written about why stand-up calls get boring and what to do about it.
5. The blocker escalation
Blockers rarely go unspoken because people are lazy. They go unspoken because raising one feels like admitting failure, so people wait, hoping it resolves itself. Give the team a format that makes escalation feel procedural instead of personal.
Blocker: [one-line description]
Raised by: [name] Blocked since: [date] Project affected: [name]
What I'm trying to do: [the goal, not the symptom]
What's stopping me: [the specific obstacle]
What I've already tried:
- [attempt]
- [attempt]
What I need: [the exact ask: a decision, an access grant, 30 minutes of someone's time, a budget approval]
Who I think can unblock this: [name]
Cost of waiting: [what slips, and by how much]
If I don't hear back by [date], I'll [your fallback action] and keep moving.Fill tip: Leave out “What I’ve already tried” and three helpful colleagues will suggest the thing you tried on Monday. The fallback line does similar work: it converts a plea into a plan, which is why people answer it.
6. The async feedback message
Read this boundary before you use the template, because it matters more than the template does. Async feedback works for specific, low-stakes, work-product feedback: a doc review, a design critique, a factual correction, a piece of praise. It does not work for performance concerns, repeated behavior patterns, or anything with a relationship inside it. Those go sync, in a one-on-one, every time. Sending “some feedback on how you’ve been showing up lately” as a Slack message is how you lose a good employee.
With that fence in place, for a doc or a draft:
Re: [the specific artifact: doc, deck, PR, draft]
What worked: [the specific thing, and why it worked]
What I'd change: [the specific thing, stated as an observation, not a verdict]
Why: [the effect it has on the reader, the user, or the outcome]
What better could look like: [a concrete alternative]
How firm this is: [Blocking / Strong suggestion / Take it or leave it]
Happy to talk it through live if that's easier.Fill tip: Without “How firm this is,” a line like “I’d change the intro” reads as either a nitpick or a rejection, and the receiver assumes whichever one ruins their afternoon. Naming the stakes yourself removes that anxiety spiral.
7. The meeting decline and replace
Someone has invited you to a meeting that shouldn’t exist. Declining is a distinct social act from writing an update, and most people fumble it by either going silently absent or grudgingly attending. Do neither. Decline, propose the written version, and name the deadline.
Hi [organizer's name], I'm going to decline [meeting name] on [date].
My read on what it's for: [the goal, in one sentence].
I think we can get there in writing instead. Proposal:
- I've posted [the update / doc / thread] here: [link]
- It covers: [the agenda items the meeting was going to cover]
- What I need from attendees: [read it and respond in the thread]
- Responses by: [date and time]
- If anything still needs a live conversation after that, I'll book 20 minutes with only the people it affects.
If you'd rather keep the meeting, say so and I'll be there. No hard feelings either way.Fill tip: Never decline empty. The decline only works because it arrives attached to a written replacement and a deadline, which is what makes it a proposal rather than a snub.
8. The request for input
This one is forward-looking, and the difference from template 3 is not cosmetic. There, the decision was made and you were creating a record. Here, the decision is genuinely open, you need input to make it, and you need it by a date.
Input needed: [the question, phrased as a question]
Decision owner: [name] Status: NOT YET DECIDED
Responses by: [date and time]
The situation: [2-3 sentences of context]
The question: [the actual thing you want an opinion on]
Options on the table:
A. [option] - upside: [x] / risk: [y]
B. [option] - upside: [x] / risk: [y]
What I need from you: [a vote, a concern, or a consideration I've missed. Not a discussion.]
Who I'm asking: [names]. Everyone else can ignore this.
If I hear nothing by [date]: I'll go with [option A / the status quo] and write it up as a decision.Fill tip: Silence becomes consent instead of a stall the moment you name what happens by default. That’s the forcing function, and when the window closes, you paste the outcome straight into template 3.
9. The async project kickoff
The kickoff meeting is the one most teams defend hardest, and it’s often the one that survives worst as a meeting: an hour of talking, three different memories of what was agreed, and no artifact. Write the brief, circulate it, and use live time only for the questions the brief couldn’t answer.
Project: [name]
Owner: [name] Contributors: [names] Target date: [date]
Why we're doing this: [the problem or opportunity, in plain language]
What "done" looks like: [an observable outcome, not an activity]
Explicitly NOT in scope: [the things people will assume are included but aren't]
How we'll know it worked: [the metric or signal, and who's watching it]
Timeline:
- [milestone] by [date]
- [milestone] by [date]
Who decides what: [name] owns [decision area]. [name] owns [decision area].
How we'll communicate: [where updates go, how often, who writes them]
First checkpoint: [date]. By then, [what will exist].
Read this and leave questions as comments by [date]. If nothing blocking comes up, we start [date].Fill tip: Four people quietly building four different projects for three weeks is the most expensive kickoff failure there is. “Explicitly NOT in scope” is what prevents it.
Why async communication breaks down, and how these templates prevent it
Templates are only worth the paper they’re not printed on if you know what they’re defending against. Three failure modes account for most of it, and each of the nine blocks above is aimed at one of them.
Ambiguity without tone cues
A message that would be perfectly friendly out loud can read as cold, curt, or threatening on a screen. “Can we talk?” is the canonical example. The reader supplies the missing tone from their own anxiety, and they usually supply the worst available option.
Templates fix this by making intent explicit instead of leaving it to be inferred. The “How firm this is” field in the feedback template, the “Status: DECIDED” versus “Status: NOT YET DECIDED” line separating templates 3 and 8, the “No hard feelings either way” close on the meeting decline: each of those is a tone cue rebuilt in text, deliberately, because the medium deleted it. This is one instance of a wider set of barriers to effective communication that get sharper, not softer, when you take the face out of the conversation. Sharpening the writing itself helps too, and our guide to improving written communication covers the underlying habits.
Decisions that get made and then lost
This is the expensive one. A team debates something for two weeks, reaches a real conclusion on a call, and writes nothing down. A month later the same question comes back, usually raised by the person who was on holiday, and the team either re-argues it from scratch or discovers that two people have been operating on opposite assumptions the whole time.
The decision doc, template 3, exists for exactly this. It costs ten minutes to write and it’s the single highest-return thing on this list. The objection window is what makes it more than minutes: it converts “I never got a say” into a documented choice not to use one.
Blockers that go silent
Sync standups surface blockers by force, which is the one genuine thing they do well. Move to async without a replacement and blockers vanish, because nothing in a written channel obliges anyone to admit they’re stuck, and admitting it in writing feels permanent in a way that saying it out loud doesn’t.
The blocker escalation, template 5, is the forcing function that replaces the meeting. The “Blocked since” field makes the duration visible, the “Cost of waiting” field makes the stakes legible to whoever can fix it, and the fallback line reframes the ask: instead of pleading for rescue, the writer is simply setting a faster deadline than the one they would default to anyway.
Where to start
Don’t roll out nine templates on Monday. Pick the meeting on your calendar that generates the least new information per minute, usually the weekly status meeting or the daily standup, and replace exactly that one with template 1 or template 4. Run it for three weeks. Watch whether anyone actually misses the meeting.
The templates are the easy part. The hard part is the judgment: knowing when a thread has stopped working and needs a call, writing an update so clear that nobody has to ask a follow-up, telling someone their draft has a problem without them reading it as a verdict on them. Those are skills, and they get better with practice and honest feedback, which is what coaching is for. Merlin can coach you through the async update your team will actually read: bring a real message you’re stuck on, and work it until it’s clear enough to send.