The Fair Rotation Formula: How to Split Bad-Time-Slot Meetings Across a Global Team

Every distributed team eventually hits the same recurring meeting problem: someone has to join at an hour that isn't working hours for them. The usual fix is "let's rotate it" — but most rotations are just round-robin by date, which quietly assumes every bad time slot is equally bad. It isn't. A meeting at 7am is a mild inconvenience. A meeting at 11pm is a different category of cost. Round-robin by date balances turns, not pain.

Below is a small scoring method that fixes this, plus a worked example across four real cities so you can see the arithmetic rather than take it on faith. If you haven't already sized up how much real overlap your team's specific city pairs actually have, start with golden overlap windows by time zone pair — the rotation only matters once you know there's no single slot that works for everyone.

Step 1: Classify every hour, not just "good" and "bad"

SyncHours' scrubber uses a three-tier model, and it's the right granularity for this: for any given person, a clock hour is either working (roughly 9am–6pm local), fringe (6–9am or 6–10pm — usable, but it costs something), or rest (10pm–6am — this is the one that actually damages sleep and goodwill). Treating fringe and rest as the same "not working hours" bucket is exactly what makes naive rotations feel unfair — a 7am call and a 1am call get scheduled with equal indifference.

Step 2: Assign a pain score

Give each tier a weight: working = 0, fringe = 1, rest = 3. The exact numbers matter less than the ratio — rest hours should cost meaningfully more than fringe hours, because the recovery cost isn't linear. A person who takes three fringe calls a week is mildly annoyed; a person who takes three rest-hour calls a week is sleep-deprived.

Step 3: Score every candidate time slot

Take a real four-person team: someone in San Francisco (PST, UTC-8), London (GMT, UTC+0), Bangalore (IST, UTC+5:30), and Sydney (AEST, UTC+10). There's no time that's "working" for all four — SF and Sydney are close to antipodal — so the team has three realistic candidate slots for a recurring call:

Notice none of the three slots is actually good for everyone — that's the honest reality of a 13–18 hour spread, not a failure of the method. You can check any of these live and drag through the day yourself: San Francisco ↔ London, San Francisco ↔ Bangalore, or London ↔ Sydney.

Step 4: Rotate to equalize cumulative pain, not turns

Instead of picking one slot forever, cycle through all three candidates — one per week. Here's what happens to the running total:

After one full cycle through all three candidate slots, cumulative pain lands exactly even at 4 for every person — not because it was forced to, but because rotating through every option you seriously considered, rather than just the two most "reasonable" ones, spreads the cost evenly by construction. This is the actual mechanism behind "just rotate it" advice — it only works if the rotation set includes the full spread of options, including the ones that feel like nobody's first choice.

Why this doesn't work with only two candidate slots

A common shortcut is to alternate between just two options — "early for us this month, early for you next month." It feels fair, but with only two slots the rotation can only average out the two slots you picked, not the full space of possibilities. In the worked example above, if the team had only ever alternated between the 14:00 and 22:00 UTC slots, Bangalore would end up carrying a cumulative pain of 4 while nobody had used the 06:00 slot that actually favors them — the fairness only shows up once the rotation set is wide enough to include everyone's best option at least once, not just everyone's least-bad option.

This is also why picking the rotation set matters more than picking the rotation order. Before you decide how often to rotate, spend five minutes finding every UTC hour where at least one person moves from rest to fringe, or fringe to working — those inflection points are your real candidate list. Anything in between two inflection points scores identically to its nearest neighbor, so testing every hour on the clock is wasted effort; testing every inflection point is not.

How often you actually need to rotate

Cadence should track how often the meeting recurs, not how bad the worst slot is. A weekly standup with a three-slot rotation completes a full fairness cycle every three weeks — short enough that nobody stays resentful for long, and predictable enough that people can plan around their bad week. A monthly all-hands is trickier: a three-slot rotation takes a full quarter to equalize, which is often too slow to feel fair in the moment even though the math works out. For low-frequency, high-attendance meetings like that, it's usually better to shrink the candidate set to two slots and rotate every single occurrence, accepting a slightly worse cumulative balance in exchange for everyone visibly taking their turn.

One more failure mode worth naming: rotation fatigue on small teams. A four-person team rotating through three slots is asking each person to remember which week is theirs; past six or seven people, that overhead disagrees with itself and it's worth automating the assignment rather than tracking it in a spreadsheet or a person's memory.

Applying this to your own team

1. List every teammate's city and add them to the SyncHours overlap planner — the working/fringe/rest classification is done for you as you drag through the day.
2. Pick 3–4 realistic candidate times and read off each person's tier at that slot.
3. Score them (working = 0, fringe = 1, rest = 3) and sum.
4. Rotate through the full candidate set on a fixed cadence — weekly for standups, monthly for all-hands — rather than defaulting to whichever slot has the lowest single-week total.

The point isn't to eliminate bad time slots — with a wide enough team spread, that's not possible. It's to make sure the same one or two people aren't quietly absorbing all of it every single week.