How to run a global all-hands across time zones

A global all-hands has one unavoidable problem: somewhere on Earth, someone will be asked to log on outside their working day. You cannot make that vanish. What you can do is pick a format that minimises it and make sure the burden does not always fall on the same people.

Why there is no perfect time

If your team is split across the Americas, Europe and Asia-Pacific, the awake-hours of those three regions barely overlap. When it is a reasonable mid-morning in San Francisco, it is already evening in London and the middle of the night in Singapore. A genuine three-way overlap during everyone's working hours simply does not exist. Accepting that early saves a lot of wasted calendar tetris. According to Microsoft's Work Trend Index, nearly a third of meetings now span multiple time zones, up 35% since 2021, so this is a problem more teams are running into, not fewer.

So the real question is not "what time works for everyone?" It is "which format spreads the cost most fairly?" There are three good answers.

The three formats, compared

Each format trades off reach, effort and how much it asks of people. Here is how they stack up.

Option one: one live session at the least-bad time

For most teams, the least-bad single slot is a late-morning Americas time, roughly 9 to 11 AM US Eastern. That catches the Americas mid-morning, Europe in the afternoon, and the early evening in much of Asia. It is genuinely awkward for Australia and New Zealand, who land late at night, which is exactly why this option only works well if your APAC headcount is small.

Pick the slot by reading everyone's real local time rather than doing the arithmetic in your head. A world clock that shows each region's working hours side by side, like Atlas, makes the least-bad window obvious at a glance.

Option two: two regional sessions

If you have meaningful headcount in Asia-Pacific, one session cannot serve them at a civilised hour. Splitting into two is the honest fix:

• Session A: Americas + Europe, run at a time that suits both (late Americas morning works well).
• Session B: Asia-Pacific, run at their morning, which is the previous evening for the West.

The cost is real: presenters deliver the same content twice, and you must keep the message consistent across both. Use the same slide deck and a short script for the core announcements so nothing drifts between rooms.

Option three: record once, take questions async

For information-heavy all-hands, a tight recording plus an asynchronous Q&A thread is often the most respectful option. People watch when they are alert, pause to take notes, and ask questions without staying up late. Post the recording, open a channel or doc for questions, and have leaders answer there within a day or two. Many teams combine this with a live session: record the live one and treat the recording as the primary artefact for everyone who could not attend.

Tips that work for any format

1. Always record. No matter the format, a recording means nobody is ever forced to attend at 2 AM. This is the single highest-leverage habit.
2. Rotate the live slot. Share the awkward hour across regions over time rather than letting it land on the same people every session.
3. Collect questions in advance. An open doc or thread before the call lets people in any time zone contribute without being live.
4. Keep it short. Thirty minutes of crisp content respects everyone, especially those joining outside their working day.
5. Publish the time clearly. State the time in UTC plus two or three local equivalents so nobody miscalculates and misses it.

Choosing the right one

Use a simple rule. If your team is mostly in the Americas and Europe, run one live session and record it. If you have a real Asia-Pacific contingent, run two sessions. If the all-hands is mostly information rather than discussion, lean on record-plus-async and keep any live element brief. Whichever you pick, the format matters less than the fairness: record everything, rotate the burden, and write the time down in a way nobody can misread.