The rule: meet live (sync) when the work needs real-time back-and-forth or carries emotional weight: debate, brainstorming, sensitive conversations and relationship-building. Go async for everything else: status updates, FYIs, and simple decisions with a clear owner. On a distributed team, live time is the scarce resource, so reserve it for what only a meeting can do.
"Should this be a meeting?" is one of the highest-leverage questions a distributed team can ask. Get it right and your calendar empties out while the work keeps moving. Get it wrong and you burn your few precious overlapping hours reading a status report aloud.
What do async and sync actually mean?
Synchronous communication happens at the same time: a video call, a huddle, a live discussion. Everyone is present at once, so it is fast, expressive and good at resolving things that need real-time give and take.
Asynchronous communication happens on each person's own schedule: a written document, a threaded message, a recorded walkthrough, a pull-request comment. The message carries its own context, so a colleague nine hours away can read it, think, and reply without anyone joining a call at midnight.
When should you meet live?
Reach for a meeting when the value comes from being in the same moment. There are four reliable cases:
- Debate and disagreement. When opinions diverge and the path is genuinely unclear, real-time back-and-forth resolves it far faster than a 40-message thread.
- Brainstorming and creative work. Ideas build on each other's energy. Interruption and tangents are a feature, not a bug.
- Sensitive or emotional topics. Feedback, conflict, bad news. Tone and presence matter, and text is easy to misread.
- Relationship-building. Trust on a remote team is not free. The occasional unstructured face-to-face is what makes the async work flow smoothly the rest of the week.
When should you go async?
There is plenty of room to move work out of meetings: in a survey of 632 workers across 20 industries led by UNC Charlotte professor Steven Rogelberg, respondents said they didn't need to be in 30% of the meetings they attended (CBS News). Default to writing it down when the information is one-directional or the decision already has enough context to make itself:
- Status updates. Progress, blockers, what is next. A short written post is searchable, skimmable and does not require a shared clock.
- FYIs and announcements. If nobody needs to respond in real time, nobody needs to be in a room.
- Simple decisions with an owner. When one person can decide and just needs input, collect that input in a thread and let them call it.
- Anything that can wait. If a reply tomorrow is fine, async is almost always the better tool.
The decision table
When you are unsure, the answer usually comes down to two questions: does this need real-time back-and-forth, and is it sensitive or high-stakes? If yes to either, meet. Otherwise, write it down.
| Situation | Best mode | Why |
|---|---|---|
| Weekly status update | Async | One-directional; better written and searchable |
| Open-ended design debate | Sync | Needs fast, branching back-and-forth |
| Sharing a finished doc for review | Async | People read and comment on their own time |
| Giving difficult feedback | Sync | Tone and presence matter; text misreads easily |
| Brainstorming new ideas | Sync | Energy and tangents build on each other |
| Simple decision with a clear owner | Async | Gather input in a thread; owner decides |
| New-hire welcome or 1:1 catch-up | Sync | Relationship-building needs real presence |
Why defaulting to meetings wastes the scarce overlap
On a co-located team, a meeting is cheap: everyone is awake and nearby. On a distributed team it is not. The hours when London, New York and Singapore are all online at once might be only two or three a day, and for some teams none at all. That window is the rarest thing the team owns.
If you fill it with status updates and FYIs, you have spent your only shared time on the exact things that did not need it, and pushed the real-time debates into someone's 6 AM or 11 PM. Treat live time as a budget. Protect it for conversations that genuinely require everyone present, and the team's core collaboration hours stay free for the work only a meeting can do.
Open most topics in writing. If a thread stalls, loops, or starts to feel tense, that is the signal to book a short call. You will hold far fewer meetings, and the ones you do hold will have a clear reason to exist.
Make async genuinely work
Async is not just "send a message instead". For it to replace a meeting, the message has to do the meeting's job. A few habits help:
- Front-load the context. Assume the reader has none. State the decision, the options and the deadline up front.
- Name an owner and a by-when. Async without a clear owner drifts forever. "Sarah decides by Thursday" keeps it moving.
- Default to writing, reach for video for nuance. A two-minute recording can carry tone that a paragraph cannot, without forcing anyone onto a shared clock.
When you do need everyone live
Some meetings are unavoidable and that is the point: those are the ones worth protecting your overlap for. When you book one, schedule it inside hours that are reasonable for everyone, not just the largest office. That means reading each person's real local time and their working hours before you pick a slot, which is exactly what Atlas does: it finds the overlap, shades each person's working hours, and adds the meeting to your calendar in everyone's correct local time in one tap.
Frequently asked
When should a distributed team meet live instead of going async?
What does async communication mean for a remote team?
Why does defaulting to meetings hurt a distributed team?
How do I decide async vs sync quickly?
Stop doing timezone math
Atlas finds the time everyone's awake and adds it to your calendar in one tap.
One-time purchase, yours forever.