Remote work has given us flexible hours, no commutes, and the freedom to work from anywhere. It has also given us the particular agony of trying to find a meeting time when your team spans from Lisbon to Tokyo.
When 9 AM in Amsterdam is midnight in Sydney and 3 AM in San Francisco, "let's find a time that works for everyone" starts to feel like a math problem with no solution. But it doesn't have to be this painful. Here's how to schedule team meetings across time zones without losing your mind.
Why Time Zone Scheduling Is So Hard
The obvious challenge is the clock math. Most people can hold two or three time zones in their head - their own, their company's headquarters, and maybe one colleague's. Beyond that, it gets messy fast.
But the real difficulty goes deeper:
People think in local time. When someone says "I'm free Tuesday afternoon," they mean their Tuesday afternoon. If you're eight hours apart, their afternoon is your midnight. Every availability statement needs to be mentally translated before it's useful.
Daylight saving time shifts. Twice a year, the time differences between regions change - and they don't all change on the same date. The US, Europe, and Australia all switch at different times. A meeting that worked perfectly in February might be an hour off in March.
"Reasonable hours" means different things. What counts as an acceptable meeting time varies by culture, by person, and by role. Some people are happy with an 8 AM call. Others consider anything before 10 AM cruel and unusual. When you're trying to find overlap between time zones, you're also navigating personal preferences.
Common Mistakes Teams Make
Mistake 1: Always favoring headquarters time
The most common pattern in distributed teams is scheduling everything during the headquarters' business hours. If HQ is in New York, meetings happen between 9 AM and 5 PM Eastern - and everyone else adjusts.
This works fine for the New York team. It's terrible for everyone else. Your colleague in Singapore is joining calls at 9 PM. Your teammate in London is losing their lunch break every day. Over time, this creates a two-tier culture: people near HQ who have normal schedules, and everyone else who makes sacrifices.
Mistake 2: Asking people to do the time zone conversion
"Does 2 PM UTC work?" Sure, if everyone on your team can convert UTC to their local time in their head. Most can't. And even those who can will occasionally get tripped up by daylight saving transitions.
Mistake 3: Scheduling by committee in a chat thread
"What times work for you this week?" when sent to a channel with people in five time zones produces a stream of responses that are almost impossible to reconcile. Each person states times in their local format. Someone has to manually translate, compare, and find overlap. It's a spreadsheet problem being solved in a chat window.
Mistake 4: Ignoring the problem entirely
Some teams just pick a recurring time and declare it permanent. This avoids the scheduling hassle but often means the same people are always inconvenienced. The person in the least favorable time zone silently suffers through 10 PM calls every week until they burn out or quit.
The Better Approach: Let People Vote on Their Own Time
The most effective way to schedule across time zones is to let each person evaluate options in their own local context. Instead of asking people to convert times and describe their availability in words, you present them with concrete options and let them say yes, no, or maybe.
This is exactly what a scheduling poll does. If you're new to this approach, check out our basic guide to group scheduling.
How to set it up with SyncWhen
Go to syncwhen.com and create a new poll. Give it a clear name - "Weekly Sync - Finding Best Time" or "Project Kickoff Meeting."
Select several date/time options across different parts of the day. If your team spans a wide range of time zones, include options at different hours. For example, you might offer slots at 8 AM UTC, 12 PM UTC, and 4 PM UTC - each will hit different parts of the day for different team members.
Share the link in your team Slack channel, email, or wherever you communicate. Since SyncWhen requires no signup or app install, everyone can vote immediately from their phone or laptop.
Everyone votes yes, maybe, or no on each option. The three-way vote is particularly valuable for time zone scheduling because it captures "I can do this but it's not ideal" - which is exactly the kind of trade-off distributed teams need to navigate.
Results appear in real time. You can see immediately which slots have the most "yes" votes and make a decision without waiting for everyone to reply to a thread.
Best Practices for Time Zone-Friendly Scheduling
Rotate meeting times
If your team spans enough time zones that no single slot is convenient for everyone, rotate. Have your weekly sync at a time that's morning for the US team one week, and morning for the Asia-Pacific team the next week. This distributes the inconvenience fairly.
A scheduling poll can help here too - run one every month or quarter to find the best rotation pattern. For tips on higher response rates, see our best practices guide.
Offer "maybe" as a real option
The yes/maybe/no voting model matters more than you might think. In time zone scheduling, there's rarely a perfect time. Most options require someone to stretch their hours a bit. "Maybe" lets people signal "this isn't ideal but I can make it work if needed" - which gives the organizer crucial information.
A time slot with five "yes" votes and two "maybe" votes is clearly better than one with four "yes" votes and three "no" votes, even though the first option has fewer enthusiastic supporters.
Consider async alternatives
Not every meeting needs to be synchronous. Before scheduling a cross-time-zone call, ask yourself:
- Could this be a recorded video update? One person records a 5-minute Loom, everyone watches it when they're online.
- Could this be a written update? A structured Slack post or document might convey the same information without requiring everyone to be online at the same time.
- Does everyone actually need to attend? Maybe only three of the six team members need to be on the call. Scheduling for three people across two time zones is dramatically easier than scheduling for six across four.
Save synchronous meetings for things that genuinely benefit from real-time interaction: brainstorming, decision-making, relationship-building.
Record everything
When someone does join a meeting at an inconvenient hour, make sure it counts. Record the meeting, take notes, and share both afterward. Nothing is more frustrating than dragging yourself to a 10 PM call and then discovering that the important decision was made in the last five minutes you had to miss because you needed to put your kids to bed.
Use clear time references
When discussing meeting times outside of a scheduling tool, always include the time zone. Not "Tuesday at 2" but "Tuesday at 2 PM CET / 8 AM EST / 10 PM AEST." Better yet, just share a SyncWhen link and let the tool handle it.
Making It Fair in the Long Run
The goal isn't to find the one perfect time - for many distributed teams, that time doesn't exist. The goal is to distribute the inconvenience fairly and minimize the total friction across the team.
A few principles to guide you:
- No one person should always have the worst time. If someone is consistently joining calls at 9 PM or 6 AM, something needs to change.
- Seniority shouldn't equal schedule privilege. It's tempting for managers to optimize for their own time zone. Resist this - it sends a message about whose time matters more.
- Check in regularly. What works in January might not work in April. Team members move, daylight saving shifts happen, personal situations change. Re-poll every quarter.
Getting Started
The next time you need to schedule a meeting across time zones, don't drop "when works for everyone?" into a chat channel. Open syncwhen.com, create a poll with a handful of time options, and share the link. You'll get your answer faster, with less back-and-forth, and with a clearer picture of what works best for the whole team - not just the people closest to headquarters.