How to Schedule Meetings Across Time Zones (Without the Slack Back-and-Forth)
Cross-timezone scheduling fails because teams treat it as a calendar-comparison problem. It's actually a fairness problem. Here's the working system.
By Blake Johnston
A four-person team is trying to find 30 minutes for a meeting next week. One person is in Sydney, one in London, one in New York, one in San Francisco. Someone posts in Slack: "When works for everyone?" Three days later the thread is forty messages long, two people are asleep at any given moment, and the meeting hasn't been scheduled. By Friday afternoon someone has DMed a poll. By Monday the poll has six votes. The meeting will, eventually, happen. It will not happen well.
This is the cross-timezone scheduling problem. Most teams treat it as a calendar-comparison problem and try to brute-force it in chat. It is not a calendar-comparison problem. It is a fairness problem dressed up as a calendar one, which is why throwing more Slack at it just makes it last longer.
The actual problem has three jobs that need to happen, in this order, every time:
- Decide whether the meeting needs to happen at all. Most cross-timezone meetings are status updates, decisions, or async work that someone has accidentally booked into a synchronous slot. The cheapest cross-timezone meeting is the one you don't have.
- Find the times where everyone could plausibly join. Working hour overlap, DST-aware, with edges flagged. This is the part the timezone overlap tool does.
- Distribute the unfair-hour cost fairly. Across enough time zones, no slot is good for everyone. Someone will be on the edge of their day. If it's always the same person, you have a fairness problem, not a scheduling one.
Most teams skip job 1, half-do job 2 in Slack, and never do job 3. Predictably, the meetings that come out the other end are bad in three different ways at once.
The first move: ask whether it needs to be a meeting
Before any tool comes out, ask the question nobody asks: does this need to be a synchronous meeting? Across more than four time zones, the bar for "yes" should be high.
Three honest tests:
Is the output a decision? If yes, the meeting can probably be a written proposal with a 24-hour async voting window. The team gets context, asks questions in writing, votes. The decision lands without a calendar slot.
Is the output information transfer? If yes, write the doc, post the doc, let people read it on their own time. A live "walkthrough" of a doc at 3am for two attendees is worse than three people reading the same doc at 9am their time.
Is the output a real-time conversation? Some conversations only work live: brainstorming, hard interpersonal conversations, sensitive feedback. Those deserve a synchronous meeting. Most cross-timezone "meetings" don't pass this test, and people pretend they do because nobody wants to be the person who said "let's just do this in writing".
The cost math from the meeting-cost post is even harsher across time zones, because half the room is paying with sleep. A 30-minute meeting at 7am Pacific and 11pm Singapore costs the team 30 minutes plus a fragmented day on each side. If it could have been a doc, the doc was the right answer.
When you do need to meet: the three patterns
For the meetings that survive job 1, there are three patterns that work, depending on how spread your team is.
Pattern 1: Pick the overlap (small spread). If your team spans about six hours of timezone or less, say London to New York, a clean overlap exists somewhere in the eastern afternoon and western morning. The job is to find the green band on the grid and pick a slot that's fair on both sides. Drop the team into the timezone overlap tool, look at the emerald row, click the slot, copy the invite. Two minutes.
Pattern 2: Rotate the pain (medium spread). If your team spans seven to about nine hours, San Francisco to Berlin, the clean overlap is small or non-existent. Someone will be on the edge of their day. The fairness move is to rotate which "someone" carries it: 8am Pacific / 5pm Berlin one week, 10am Pacific / 7pm Berlin the next. Both sides take turns absorbing the unfair hour. The team agrees on the rotation; nobody draws the short straw permanently.
Pattern 3: Split the meeting (large spread). If your team spans more than nine hours, Sydney plus San Francisco, there is no slot where everyone is awake during working hours. The intersection is empty. Stop trying to force one. Run it twice for each half of the team with the owner attending both, or run it once with a recording and let the other half participate async. Forcing a single slot across nine time zones is how someone ends up taking a meeting at 4am.
The mistake teams make is using Pattern 1 logic on a Pattern 3 spread. They keep narrowing working hours, asking people to "just stretch a bit", and producing meetings nobody enjoys. Pick the pattern that matches the actual spread.
The unfair-hour tax
Even within Pattern 1 and Pattern 2, fairness is the part most teams handle worst.
Cross-timezone meetings get scheduled by whoever sends the invite, and the invite-sender is usually someone in the dominant timezone (HQ, the most senior person, whoever organised the team in the first place). The dominant timezone gets the comfortable hour; everyone else stretches. Over six months this compounds: the Sydney engineer takes seventeen meetings at 8am or 7pm, the London engineer takes seven, all in the comfortable afternoon. Nobody designed this; it just happened.
A few rules of thumb that fix this without a spreadsheet:
Default to a rotation, not a fixed slot. Recurring cross-timezone meetings should rotate every two to four weeks. The slot that's comfortable for the west coast one month is the slot that's painful for them the next. The slot the east coast inherited gets reciprocated. The team carries the cost together.
Don't put the unfair-hour person on camera at full energy. If someone is taking a 7pm meeting, that's their evening. Don't expect peak performance, sharp questions, or active facilitation from them. Run the meeting, ship it, let them log off.
Move recurring meetings before they ossify. A weekly that's been at "Tuesday 4pm London" for six months is invisible to everyone in London. Move it. See if anyone notices. If only one person is upset, that's the person whose timezone has been silently dominating the schedule.
Write meeting times in everyone's local time when you communicate them. "Tuesday 9am Pacific / 12pm Eastern / 5pm London / 6pm Berlin" is six more characters than "Tuesday 9am Pacific" and saves three Slack messages from people doing the math. The timezone overlap tool copies this format with one click for whatever slot you pick.
Daylight saving time, and the planning-two-weeks-out trap
DST is the worst ambush in cross-timezone scheduling.
The US, Europe, and Australia shift on different weekends; India, Japan, and most of Asia don't shift at all. Twice a year, offsets you've been working with for six months change quietly under your feet, and recurring meetings now sit an hour off relative to the people who shifted.
Two practical defences:
When booking anything more than a week out, use the actual date, not the current offsets. A meeting scheduled today for "next Tuesday at 3pm London / 10am New York" might be 3pm London / 11am New York after the DST shift falls between today and next Tuesday. Tools that compute offsets from the IANA database and let you pick a future date will catch this; people doing the math in Slack will not.
On DST week, send a calibration message. Something like "this week's London/NYC meeting moves to its post-DST slot, the calendar invite has been updated." The five seconds of typing prevents an hour of confusion.
The small operational kit
For teams running more than two cross-timezone meetings a month, the kit that keeps it manageable:
A shared timezone roster. Even if it's a Notion page, every team member's local timezone written down. Nobody should be asking "what timezone is Priya in?" three times a year.
A rotation policy in writing. Whose timezone the meeting defaults to, and how often it rotates. Written down so the answer doesn't depend on whoever sent the invite that week.
A working-hours norm. What "working hours" actually means for the team. 9-to-6 local? 8-to-5? With or without lunch? The grid is only as useful as the working hours it's checking against, and most teams have never explicitly agreed.
A no-meetings-after-X norm. A floor for what counts as "stretching". Most teams should set 7pm local as the hard floor; some teams need 6pm. Below the floor the meeting either rotates or splits. The floor exists so the most agreeable person on the team isn't always the one taking the 8pm slot.
The kit lives in a single team-norms doc that new joiners read once. The meetings scheduled inside it are dramatically less painful than the ones scheduled outside it, and the difference is the half-hour someone spent writing the doc.
The recipe
The whole sequence for a new cross-timezone meeting: decide whether it needs to be synchronous, open the timezone overlap grid and pick the pattern that matches the spread, then send the invite with the time in every attendee's local zone and the rotation cadence if it's recurring. Two minutes of structure now saves a week of "when works for everyone" later.
Most cross-timezone meetings are decisions or status updates wearing a meeting costume. Both work better as docs. The meetings that genuinely need to happen across nine time zones are rare; when they do, the best teams treat the unfair-hour cost as something the team carries collectively, not something one person carries silently. Halftime is a 2-minute team game and prompt that runs async by default. Daily glue for distributed teams, no overlap required. Free for teams up to 6.