If you've ever stared at a meeting invite for 6:45am and wondered why your week always seems to start with regret, you already understand why time zones are the hardest part of distributed work. The team is brilliant. The product is shipping. But the calendar is a slow accumulation of compromises that nobody quite agreed to.
This guide is for people who run, or are part of, teams spread across more than two time zones. It covers the math, the operational defaults, and the specific decisions that separate teams that thrive across zones from teams that quietly burn out.
The first question: how spread are you really?
A "distributed team" can mean anything from two cities in the same continent to twelve countries spanning eighteen hours. The right answer to every question below depends on which one you actually are.
The single number that matters is your overlap window: the daily span where every team member's standard working hours overlap. Calculate it once and write it on a sticky note. If it's six hours or more, you have room to be sloppy and still operate sync-first. If it's two to four hours, you have to make every overlap minute count. If it's less than two hours, you're an async-first team whether you've admitted it or not.
A quick rule of thumb. If your team includes:
- US West Coast and Western Europe: overlap is about 1 hour.
- US East Coast and Western Europe: overlap is about 4 hours.
- US East Coast and India: overlap is about 2 hours.
- US West Coast and India: overlap is essentially zero.
- Europe and India: overlap is about 4–5 hours.
- Europe and East Asia: overlap is about 1–2 hours.
- US and East Asia: overlap is essentially zero outside of brutally early/late hours.
If you only know two of those three regions, your team is operable on sync defaults. If you have all three, you've crossed into the territory where the meeting culture you grew up with no longer works, and trying to force it will quietly cost you your best people.
Sync vs async is a false binary
The conventional advice is "be async-first." That's mostly right, but it's an oversimplification that gets people in trouble.
What actually works is a mixed approach:
Async is the default for everything that doesn't need real-time decisions. Code review, status updates, design feedback, documentation, planning iterations, retrospectives. These should happen in writing, in tools that surface the change history, on the participant's own schedule.
Sync is reserved for things that are genuinely harder async. Conflict resolution, creative brainstorming, customer crises, performance conversations, team bonding. These should be scheduled tightly and recorded for anyone who can't attend.
The trap is using sync as the default and then bolting "async-friendly" practices on the side. That's how you end up with three meetings a day that everyone reluctantly attends because nobody's brave enough to cancel them.
The four operating modes for distributed teams
In practice, distributed teams settle into one of four modes. Most teams oscillate between them depending on the project phase.
Mode 1: Follow-the-sun
Work is passed from one time zone to the next as each one closes out for the day. Common in customer support and operations. Less common in product work because handovers add coordination cost that usually exceeds the time saved.
Works well for: 24/7 operations, security response, NOC-style work. Falls apart for: anything requiring continuity of context, design, or judgment.
Mode 2: Hub-and-spoke
One time zone holds primary decision-making, the others contribute on their own schedule. The hub gets the comfortable meeting times. The spokes accept that some meetings will be inconvenient.
Works well for: small teams with a clear majority in one region. Falls apart for: teams that are spread evenly across continents. The hub becomes a bottleneck and the spokes feel second-class.
Mode 3: Core hours
The team picks a daily window where everyone is available, regardless of local time. Often 2–4 hours. Outside the window, people work on whatever's local-time-appropriate.
Works well for: teams of 5–30 where overlap is 2–6 hours. Falls apart for: teams where the overlap is less than 2 hours, which forces someone to take 6am or 10pm meetings daily.
Mode 4: Fully async
No required meetings. All decisions happen in writing. Real-time conversations are opt-in, recorded, and asynchronous-by-default in their follow-up.
Works well for: large, mature teams. Engineering teams with strong written culture. Open-source-style operations. Falls apart for: early-stage teams still figuring out what they're building, and teams with a high proportion of relationship-driven work.
Pick deliberately. Most teams default to Mode 2 without realising it and then wonder why their European colleagues keep quitting.
The meeting audit
If you haven't audited your team's meetings in the last 90 days, do this first. It's the single highest-leverage thing you can do.
For every recurring meeting, ask:
- Could this be a written update with comments? Most status meetings can.
- If it must be live, does everyone in the room actually need to be there live? Make it optional and record it.
- Is the time fair? If the same two people always get the 5am or 10pm slot, rotate. Annually, not monthly, so nobody has to keep track.
- What decision does this meeting produce? If you can't name one, kill the meeting.
A small team — let's say ten people across three time zones — probably has 5–8 recurring meetings on the schedule. After an honest audit, expect to keep 3–5. The rest become written documents, Loom recordings, or just stop happening.
The async writing standard
Async work only works if the writing is good. Bad writing — long, vague, full of "let me know your thoughts" — makes async slower than sync. Good writing makes it faster.
A short standard that's worked for several teams:
- First line: the decision being asked for, or the conclusion. Not the context.
- Second paragraph: the relevant context.
- Third paragraph: the options considered or the proposed action.
- Closing: explicit deadline for response and explicit consequence if no response.
If you can't write the first line in twelve words, your decision isn't ready yet. Go back and figure out what you're actually asking.
The DST trap
Daylight saving time is the single most common cause of "wait, why was my meeting an hour earlier today" panic.
The brutal facts:
- The US, Canada, and most of Europe observe DST, but on different schedules. UK and EU clocks go back the last Sunday of October. US clocks go back the first Sunday of November. For one week each year, the US-UK time gap is one hour smaller than usual.
- The southern hemisphere is six months out of phase. Australia (where applicable), New Zealand, parts of Brazil shift in opposite directions to the northern hemisphere.
- Japan, China, India, South Africa, most of Asia, most of Africa do not observe DST at all.
- Within countries, observance can vary by region. Arizona doesn't observe DST. Most of Saskatchewan doesn't. Parts of Western Australia don't.
What to do about it:
- Never schedule by local time alone. Always use a calendar tool that shows the other person's time too.
- The week before any DST transition, post a reminder. Especially before the October UK-vs-US gap.
- Build your time-zone tooling on a properly-maintained zoneinfo database. Don't roll your own DST logic. (This is a particular note for engineering teams.)
- Pin recurring 1:1s in the calendar of whichever person is more likely to forget. Auto-shifting "local time" rules in most calendar tools handle DST correctly, but only if you trust the timezone setting.
How to handle holidays you don't observe
Public holidays are where good distributed teams quietly excel and bad ones get caught flat-footed.
A short checklist:
- Maintain a shared team calendar that includes every team member's local public holidays. Surface it in any planning conversation.
- Don't schedule launches the week before a major regional holiday unless you can absolutely guarantee staffing through the period.
- Be aware of holidays that affect work for a whole week or month, not just a day. Ramadan affects working hours in many countries. Diwali in India and the Nepal Tihar period both have multi-day impact. Chinese New Year shuts down entire industries for two weeks. School summer holidays in Europe span July and August.
- Don't ask people who don't observe a holiday to cover for those who do, unless you'd ask the reverse. The fairness signal matters more than the immediate coverage.
Tools that actually help
A short, opinionated list. None of these are sponsored.
- Calendar with multi-timezone view. Google Calendar's secondary timezone is fine. Fantastical and Cron (now Notion Calendar) are nicer for power users.
- A scheduling link tool. Calendly, Cal.com, SavvyCal. Pick one, standardise across the team. The benefit isn't booking — it's removing timezone math from external scheduling.
- A timezone overlap visualizer. besttimefor.io for one-off planning, World Time Buddy for the broader use case.
- An async video tool. Loom, Vidyard, or built-in if your platform has it. Replaces 60% of meetings that could have been a 3-minute recording.
- A document tool with proper threaded comments. Notion, Google Docs, Coda. Slack threads don't count — they're disposable, hard to find later, and don't preserve context.
The tool stack matters less than the discipline. A team with rigorous writing standards and Google Docs will outperform a team with Notion AI and no standards every time.
What to copy from teams who've done this well
A few public examples worth studying:
GitLab has documented their distributed working playbook in extreme detail. Their public Handbook is the closest thing to a textbook on this. The headline practice: every decision is documented in writing in the relevant Handbook page. New hires read the Handbook for the first two weeks. Cite GitLab when you need to convince your team that documentation isn't bureaucracy.
Automattic (WordPress.com, Tumblr) has been distributed for over a decade. Their default is async-first, with annual in-person team retreats. Their "P2" blog system — every team has an internal blog where decisions are debated in comments — is worth studying. The lesson: chat tools are not decision tools. You need a slower, more durable medium.
Buffer writes openly about salaries, decisions, and operational practices. Their public discussions about how they handle async standups, deep work blocks, and async-only sprints are useful reading.
The common thread: in each case, the team has explicit, documented norms that they revisit. The norms aren't perfect, but they exist. Most teams suffer not from bad practices but from unexamined ones.
The first three things to change this month
If you read this far, you probably want to do something. Three specific actions:
- Calculate your team's overlap window and write it down. If you're using besttimefor.io to do this, add each team member's home city and share the link with the team. Make sure everyone knows what the overlap actually is.
- Cancel one meeting and replace it with a written update. Start with the meeting where the same person always gives the same status report. That one's the easiest to kill. See if anyone misses it.
- Write a one-page "how we work" document. Cover your operating mode, your overlap window, your async writing standard, and the holidays you collectively observe. Share it with new hires. Revisit it every six months.
None of this is glamorous. But the teams that do this work consistently end up doing the best work, with the lowest turnover, in the most enviable conditions. You don't need to be GitLab. You need to be intentional.