Does this meeting actually need to be synchronous?

Posted 24 August 2026.

Why this question comes before the scheduling question

Most advice about scheduling across time zones starts from the assumption that the meeting is happening and the only question is when. On a team spread across eight or ten hours that skips the cheaper decision. Every recurring synchronous meeting spends someone’s overlap, and overlap is the scarcest thing a distributed team has.

So before working out whose morning takes the hit, it is worth asking whether the meeting needs everyone present at the same moment at all. Some do. Plenty do not, and those are the ones quietly consuming the hours you need for the ones that do.

When should a meeting be synchronous instead of async?

The useful test is not importance. Important things are often better written down. The test is whether the outcome is unknown at the start and depends on people reacting to each other.

Four questions, and one yes is usually enough:

• Is there real disagreement? Working through a decision people actually differ on is far faster live than in comment threads.
• Is the problem still being shaped? Early design and architecture work benefits from interruption, sketching, and half-formed ideas that nobody would write down.
• Does tone matter? Feedback, difficult conversations, anything about someone’s work rather than the work itself.
• Do people need to build a relationship? New joiners, new pairings, teams that have never met. This is a real reason and it does not need to pretend to be about throughput.

If the answer to all four is no, the meeting is probably a written update that has been given a calendar invite.

What kinds of meetings work better as async updates?

The clearest signal is turn-taking without reaction. If each person speaks in sequence and nobody responds to what the previous person said, the meeting is a series of monologues sharing a room. That format loses nothing in writing and gains a searchable record.

Common cases:

• Status rounds. The archetype. Three sentences each, no cross-talk, and half the attendees only need two of them.
• Information broadcasts. A decision already made, being announced. Live attendance adds nothing except a shared timestamp.
• Most demos. A recording is usually better: pausable, rewatchable, and available to people who were asleep.
• Recurring meetings nobody has questioned. Worth asking, once a quarter, what would break if each one stopped. The answers are informative.

How do you run an async update well?

Async is not automatically better. A written update nobody reads fails the same way a meeting nobody attends fails, and usually for the same reason: it was never clear who it was for.

What tends to work:

• One home. A single predictable place. Updates spread across three tools are the same as no updates.
• A deadline. Async does not mean whenever. A posting time keeps it a rhythm rather than a backlog.
• Structure. Same shape every time so people can skim for what concerns them.
• An explicit ask. Mark what needs a reply. Without that, everything reads as optional and gets treated accordingly.

Does going async fix time zone scheduling problems?

It reduces them. It does not remove them, and it is worth being straight about that, because “just go async” is often offered as a complete answer when it is a partial one.

Cutting the meetings that never needed to be live frees the overlap for the ones that do. But the ones that do still have to land somewhere, and on a wide spread that is still someone’s early morning or late evening. The decision does not disappear, it just gets made less often and with more room to make it well.

Which puts the weight back on the same question: when a meeting genuinely needs everyone live, who takes the inconvenient hour, and does that rotate? That is the pattern in why the same person always takes the early meeting, and the arithmetic for finding the least-bad hour is in the overlap window method.

A quarterly review that takes ten minutes

List every recurring meeting on the team calendar. For each one, mark which of the four questions above it answers yes to. Anything with no yes is a candidate for a written update. Anything with a yes stays, and deserves a properly chosen time rather than whatever slot it inherited.

Teams that do this usually find two or three recurring meetings that survived on inertia alone, and the hours they release are the hours that make the remaining meetings easier to place.

A note on what this isn’t

This is not an argument that meetings are bad or that async is a superior culture. Some teams over-correct into writing everything down and lose the fast, messy conversation that solves hard problems. The claim is narrower: on a distributed team, synchronous time is expensive in a way it is not for a co-located team, and it is worth spending deliberately.