Almost every fast-growing software company eventually has to schedule a single recurring all-hands meeting that spans four regions: the United States, Europe, India, and somewhere in APAC (typically Singapore, Tokyo, or Sydney). The default solution is to pick the time that is least bad for headquarters and accept that one or two regions will dial in late at night. That is the path of least resistance, and it is also the path that produces a quiet, persistent grievance among the people who consistently absorb the inconvenience.
This post walks through how to design the meeting properly. The four-region case is interesting because it has no clean answer — there is no single time that is good for everyone — but there are several configurations that distribute the cost honestly. Picking one of those, deliberately, is half the battle.
The constraint, stated honestly
For a four-region group, the maximum overlap between everyone's working day is zero. There is no UTC moment at which all four regions are in their 09:00–18:00 working window, because the four regions span more than 16 hours of clock time:
| Anchor city | Working day in UTC (winter) | Working day in UTC (summer) |
|---|---|---|
| San Francisco | 17:00 – 02:00 UTC | 16:00 – 01:00 UTC |
| New York | 14:00 – 23:00 UTC | 13:00 – 22:00 UTC |
| London | 09:00 – 18:00 UTC | 08:00 – 17:00 UTC |
| Bengaluru | 03:30 – 12:30 UTC | 03:30 – 12:30 UTC (no DST) |
| Singapore | 01:00 – 10:00 UTC | 01:00 – 10:00 UTC (no DST) |
San Francisco and Singapore do not share a single working hour. New York and Singapore overlap only from 13:00 UTC to 14:00 UTC in winter (San Francisco is still asleep at that hour). Adding Bengaluru as a fourth region constrains the overlap further but produces a wider working-hours band on the EMEA + India side.
The conclusion is the constraint: there is no fair time. Any meeting time chosen falls outside someone's working day. The right question is not "what time is fair" but "which inconvenience pattern do we choose."
Three configurations and what they cost
Configuration A: anchor on EMEA + India, both Americas dial in early or late
The slot at 13:00 UTC works inside the working day for London (13:00 / 14:00 in summer), inside the working day for Bengaluru (18:30 IST), and at the edge of the day for Singapore (21:00 SGT). New York is 08:00 ET in winter (early but acceptable). San Francisco is 05:00 PT — a 5am call.
This is the configuration where the West Coast US absorbs the pain. It works if your San Francisco contingent is small and the Bay Area office is willing to start their day with a shared meeting. It does not work as the only configuration if the West Coast is more than a quarter of headcount.
Configuration B: anchor on Americas + EMEA, APAC and India watch the recording
The slot at 16:00 UTC works for London (16:00 / 17:00) and the Americas (08:00 PT / 11:00 ET). It is 21:30 IST in Bengaluru — late but doable. It is 00:00 SGT in Singapore — midnight.
This is the most common default in companies whose centre of gravity is North America. The implicit choice is that APAC does not attend live; the meeting is recorded and APAC employees watch it asynchronously the next morning. That is fine if it is acknowledged. It is not fine if leadership keeps insisting "we want everyone live" while implicitly making it impossible.
Configuration C: rotate the anchor
Rotate the meeting through three slots over a six- or eight-week cycle: a configuration A slot (early for Americas), a configuration B slot (late for APAC), and a configuration C slot (mid-evening for the Americas, before-work for APAC). The third slot — say, 02:00 UTC, which is 18:00 PT / 21:00 ET / 10:00 SGT — is brutal for India and EMEA but fair for the other three regions.
Rotation produces no good slots and several bad ones. The benefit is that no single region absorbs the badness. The cost is that rotation requires discipline (people forget which week is which) and that anyone who joins mid-cycle is confused. If you choose rotation, document the cadence prominently — in the meeting description, in the team handbook, in the slack pinned message — and treat the rotation rule as immutable. Changing it because one slot is "easier" undoes the point.
What rotates and what does not
Even within a rotation, some elements should stay fixed. The meeting length should not vary: 45 minutes works, 30 minutes is too short for cross-region context, 60 minutes is unkind to whichever region is dialling in late. The meeting format should not vary: if some weeks are Q&A and other weeks are presentations, attendees cannot decide rationally whether to dial in live or watch the recording.
What rotates is only the time slot itself, on a published cadence. The simplest cadence is three slots over six weeks, alternating: week 1 slot A, week 2 slot B, week 3 slot C, week 4 slot A again, and so on. Whatever cadence you pick, post the next four meeting times in the meeting description so that nobody has to compute the schedule themselves. TimeZoneMeet's Schedule tool can help you find the exact wall-clock times in each region for each rotation slot.
The recording question
For any four-region all-hands, at least one region will be sleeping during any given live slot. The question is not whether to record — you should always record — but how to design the meeting so that the recorded version is useful.
The pattern that works: the front half (20–25 minutes) is structured presentation, and the back half (15–20 minutes) is live Q&A. The recording is useful for the front half, since it is essentially the same content for everyone. The Q&A is useful only for the people who are live, because their questions are time-sensitive and the answers may not generalize. Asynchronous attendees can read the Q&A as text in a follow-up summary, posted within 24 hours of the meeting in a known place.
What does not work: trying to do "live Q&A across two time slots" by holding a second meeting later. The same content cannot be delivered twice with the same energy by the same people. It produces a B-tier meeting that the recorded-attendee region quickly learns to skip.
Cadence: monthly, biweekly, weekly
The four-region all-hands is most often monthly. Weekly is too frequent given the fairness cost; biweekly is sometimes used during periods of rapid change. Going below monthly (to quarterly) tends to mean each meeting is too long, contains too much content, and feels disconnected from the day-to-day rhythm.
If your team is at the stage where you want a weekly cross-region touchpoint, use a different format: a written async update that everyone reads on their own time, supplemented by a monthly all-hands for face-to-face context. The async update is read in everyone's working day; the all-hands handles the things async cannot — body language, leadership tone, real-time questions.
What to put in the invite
Four pieces of information, every time:
- The UTC time of this specific instance.
- The wall-clock time in each of the four regions, with city names.
- The next three rotation slots (if you are rotating), with their UTC and regional times.
- A link to the recording from the previous instance.
Resist the temptation to put a single regional time in the title and trust people to convert. The four regions are large enough that several attendees will get it wrong every month. The few extra characters in a clear meeting title pay for themselves immediately.
Verify before each instance
- Run the upcoming instance's UTC time through TimeZoneMeet for each anchor city to confirm the wall-clock times printed in the invite.
- If the upcoming instance is within two weeks of a DST transition (see DST and meeting planning for dates), recompute the regional wall-clock times explicitly.
- Re-confirm the recording URL the day before. Recording links from the previous month go stale on some platforms.