Our team spans five time zones: US Pacific (UTC-8), US Eastern (UTC-5), UK (UTC+0), Central Europe (UTC+1), and India (UTC+5:30). The spread between our earliest and latest person is 13.5 hours. There is no single meeting time that’s reasonable for everyone.
This isn’t a unique problem — any team spread across more than 3-4 time zones faces it. But most teams solve it badly: they schedule meetings at a “compromise” time that’s actually just convenient for the majority and miserable for the minority. Or they rotate meetings but do it inconsistently, so the same two people always end up with the 7am calls.
Here’s the system we use for scheduling, overlap hours, and async-first communication that accounts for time zone spread. It’s not perfect — nothing is, with a 13-hour gap — but it’s fair, documented, and sustainable.
Step 1: Map your overlap
Before you can schedule anything, you need a clear picture of when people are actually available. We maintain a simple spreadsheet (it’s in Notion, but a Google Sheet works fine) with each person’s working hours in their local time, converted to UTC.
For our team:
| Person | Location | Local hours | UTC |
|---|---|---|---|
| Alex | Portland, OR | 9am–5pm | 17:00–01:00 |
| Sam | New York | 9am–6pm | 14:00–23:00 |
| Priya | London | 9am–5:30pm | 09:00–17:30 |
| Marcus | Berlin | 9am–6pm | 08:00–17:00 |
| Aisha | Mumbai | 10am–6:30pm | 04:30–13:00 |
The overlap between all five people: 14:00–17:00 UTC (2pm–5pm UTC). That’s three hours where everyone is within their working day. In local time:
- Portland: 6am–9am (early, but workable)
- New York: 9am–12pm (ideal)
- London: 2pm–5pm (ideal)
- Berlin: 3pm–6pm (fine)
- Mumbai: 7:30pm–10pm (late — this is the problem zone)
Full-team overlap is tight, and it’s not fair to Aisha. This is where rotation comes in.
Step 2: Establish overlap bands, not a single window
Instead of one overlap window, we define two:
Band A (Europe + Americas): 14:00–17:00 UTC — good for Sam, Priya, Marcus, okay for Alex, hard for Aisha.
Band B (Europe + Asia): 09:00–13:00 UTC — good for Priya, Marcus, Aisha, early for Sam, very early for Alex.
Our rule: meetings that require all five people rotate between Band A and Band B on alternating weeks. This means nobody is always stuck with the worst time. Aisha takes a late evening every other week. Alex takes an early morning every other week.
Meetings that only need a subset of the team are scheduled in the band where all participants have reasonable hours. A meeting with Sam, Priya, and Marcus? Schedule it in Band A. A meeting with Priya, Marcus, and Aisha? Band B.
Step 3: Make the rotation explicit and automated
We use World Time Buddy for quick visual scheduling and Google Calendar with a rotation system for our recurring meetings.
The rotation works like this:
- Odd weeks (Week 1, 3, 5…): Full-team meeting at 15:00 UTC (Band A)
- Even weeks (Week 2, 4, 6…): Full-team meeting at 10:00 UTC (Band B)
Both times are in the calendar as recurring events. Team members know the pattern and plan their weeks accordingly. The facilitator for each meeting (which also rotates — see our weekly sync format) confirms the time in Slack on Monday morning.
We tried using a scheduling tool like Doodle or When2meet for each meeting individually. This creates too much friction — people don’t fill in the poll, or the “best” time changes week to week. A fixed, alternating schedule is predictable and low-maintenance.
Step 4: Protect boundaries with explicit rules
The rotation system only works if you enforce boundaries. Our rules:
No meetings outside working hours without explicit consent. If a meeting falls in someone’s evening or early morning, they can decline with no questions asked. The team will record the meeting and share notes in Notion. This happens about twice a month and is treated as completely normal.
Async is the default for everything except the weekly sync and 1:1s. Project discussions, code reviews, document feedback, status updates — all of these happen in writing. The only recurring synchronous meetings are the weekly sync (alternating bands), biweekly 1:1s (scheduled in each pair’s natural overlap), and occasional ad hoc calls for high-bandwidth discussions.
Calendar blocking is expected. Everyone blocks out their core focus hours on their calendar. This means a Portland-based person might block 9am–12pm Pacific as “Focus — no meetings” and be available for scheduling only in their overlap hours. The calendar is the source of truth for availability.
Time zone is displayed in Slack profiles. Every team member’s Slack profile shows their local time zone and their working hours. This takes five seconds to set up (Slack automatically shows local time once the zone is set) and prevents the most common scheduling mistake: assuming everyone is in your time zone.
Tools that help
We’ve tried a lot of time zone tools. Here’s what stuck:
World Time Buddy — Free web tool for visualizing overlap across multiple time zones. We use this for one-off scheduling and for the initial overlap mapping exercise. Keep a bookmark with your team’s cities saved.
Google Calendar time zone features — Google Calendar supports a secondary time zone display (Settings > Time zone > Display secondary time zone). If you frequently schedule with one other zone, this is useful. For multiple zones, World Time Buddy is better.
Slack’s built-in time display — Hover over anyone’s name in Slack to see their local time. This is the most-used time zone feature in our workflow because it’s zero-effort.
Every Time Zone — A clean visual tool for seeing the current time across zones. Good for a quick “is it reasonable to ping someone right now?” check.
We evaluated Clockwise and Reclaim.ai for automated calendar optimization. Both are impressive, but they add complexity and cost that we haven’t felt necessary with a team of five. If your team is 15+ people across many zones, they’re worth looking at.
What doesn’t work
Things we tried and stopped:
“Core hours” that don’t account for spread. We initially set “core hours” of 10am–2pm Eastern and expected everyone to be available. This was 3pm–7pm in London (fine) and 8:30pm–12:30am in Mumbai (not fine). Core hours only work if the team’s time zone spread is ≤4 hours.
Permanent meeting times. Before the rotation, our weekly sync was always at 15:00 UTC. Aisha was always the one taking a 8:30pm call. After three months she flagged — correctly — that this was unsustainable. The rotation fixed it.
Async-only with no synchronous touchpoints. We tried going fully async for one quarter as an experiment. It worked operationally but hurt team cohesion. People felt disconnected. The weekly sync, even though it’s just 25 minutes, provides a regular human touchpoint that async updates can’t replace.
Expecting people to shift their working hours. Some companies ask remote workers in “inconvenient” time zones to shift their schedule (e.g., start at 12pm instead of 9am to increase overlap). This works for some people but breeds resentment for most. We don’t ask anyone to shift — the system adapts to people’s natural working hours, not the other way around.
Making async carry the weight
The real solution to time zone challenges isn’t better scheduling — it’s reducing the need for synchronous time in the first place. When your team communicates well asynchronously, the scheduling problem shrinks because fewer things need everyone in the same room at the same time.
Our communication stack — documented in our async-first guide — handles about 90% of team coordination without a meeting. The weekly sync handles decisions. 1:1s handle relationships and feedback. Everything else is written.
For a five-timezone team, this means most people attend one group meeting per week (25 minutes) and two 1:1s per month (30 minutes each). Total synchronous time: about 85 minutes per week. The rest is async — written updates, Notion docs, Loom recordings, Slack threads — happening on each person’s own schedule.
That’s the system. Map your overlap, define bands, rotate meetings between them, protect boundaries, and lean hard on async for everything else. The time zone problem never fully goes away, but it becomes manageable — a scheduling constraint rather than a daily source of friction.