Designing a fair meeting rotation when no single time works for everyone
When your team spans three or more continents, no single weekly slot is fair to everyone. A documented rotation, applied honestly, is the difference between a team that scales and a team that quietly resents whoever runs the calendar.
Fairness in a globally distributed team is not the absence of inconvenience. Inconvenience is unavoidable. Fairness is making sure that the inconvenience is shared in a way the team can see, predict and trust.
Below is a working playbook drawn from real distributed teams, including engineering, product, recruiting and operations groups. Where we recommend a specific pattern, we have seen it work at least three times across teams that had nothing else in common.
Why this matters
Distributed teams pay a coordination tax that co-located teams do not. Every synchronous meeting that crosses a coastline costs someone an hour of their evening or morning. When that tax is invisible, it gets paid by the same people every week — usually the most junior, the newest hires, or the people in the time zone furthest from the team's centre of gravity.
Making the tax visible is the first step. Allocating it deliberately is the second. The rest of this article covers the patterns we have seen work, and the patterns that look elegant on paper but reliably break in practice.
A baseline structure that almost always works
Pick one anchored overlap window of two hours per working day. Treat that window as the only time the team is allowed to schedule synchronous internal meetings. Everything else — code review, design feedback, decision documents, project status — happens asynchronously.
The anchored window does not have to be ideal for everyone. It has to be predictable. A predictable, slightly inconvenient window is better than an unpredictable, supposedly perfect one. People plan around predictability; they cannot plan around optimisation.
Inside that window, you can run a daily team sync, weekly leadership reviews, design critiques, planning sessions, and one-on-ones if the schedule allows. Outside that window, treat synchronous time as a scarce resource: a one-off, justified, calendar-blocking exception.
Documenting the shape so people can plan their lives
Write the anchor window down in the team handbook. Include the local time it falls at for each team member, the assumed working hours of each region, and the explicit policy on how meetings outside the window are scheduled. This document is not bureaucracy — it is the contract that lets people plan school pickups, gym slots, and family dinners without worrying that next Tuesday will be different.
When new hires join, walk them through the document on day one. When the team grows into a new region, revisit the document before the first hire in that region starts. The document is what turns a vague intent ("we are async-first") into something a new joiner can actually follow.
Patterns that look elegant and reliably break
A daily standup that rotates time zone weekly sounds fair on paper. In practice it makes everyone's personal calendar unpredictable, doubles the number of "wait, is the standup on today?" Slack messages, and hides whichever week is the worst for any given person behind a fog of "well, it is only one week in four". Don't do this. If a single time is too unfair, replace the daily standup with an asynchronous one.
A "no-meetings Wednesday" sounds great on paper. In practice it pushes meetings to Tuesday and Thursday, which then fill up. The honest version is to cap the team's synchronous time per week (say, 8 hours) and trust managers to allocate it.
A team-wide all-hands at 16:00 UTC sounds equitable. For someone in Sydney that is 03:00. There is no cultural performance you can put on top of a 03:00 meeting that makes it fair. Either record the all-hands and let people watch async, or rotate genuinely.
Calendars, IANA identifiers and the daylight saving cliff
All modern calendar systems can store events against an IANA time zone identifier rather than a fixed UTC offset. Use that capability. When the IANA identifier is the source of truth, your recurring meetings move correctly across daylight saving transitions. When the offset is the source of truth, they do not — and the resulting bug is invisible until the morning of the transition, when half your team logs on at the wrong time.
Twice a year, on the Monday after a daylight saving transition, send a single message to the team confirming the post-transition meeting time in each region. It costs nothing and prevents the most common scheduling mistake in the global calendar.
A short, opinionated checklist
- Pick a single anchored overlap window. Document it.
- Cap synchronous meeting hours per person per week.
- Treat written documents — not meetings — as the place decisions happen.
- Use IANA identifiers everywhere a tool will let you.
- Confirm the post-DST meeting time on the Monday after every transition.
- Rotate the inconvenient slots transparently. Never hide rotation.
- Record everything that scales beyond the room.
Putting it into practice this week
If you are reading this and managing a team that is already underwater on synchronous meetings, the most useful thing you can do this week is audit your team's recurring calendar and ask, for each meeting, whether the same outcome could be reached with a written document, a Loom, or a tagged comment thread. The answer will be yes more often than you expect.
The goal is not zero meetings. The goal is meetings that earn their place on the calendar — and a team that trusts the time it has been given to do focused work.
Where to go next on ZoneShift
Use the ZoneShift time zone converter to test specific meeting times against your team's real distribution. The meeting planner lets you pick a list of cities and find the best shared business window. Per-city pages — for example London, New York or Tokyo — show the best meeting windows against the other major hubs that distributed teams typically include.