The short answer: pick a small daily overlap window, protect it for the handful of conversations that genuinely need everyone live, and make everything else async by default. Most distributed teams settle on 2-4 hours of overlap. Then rotate the few unavoidable synchronous meetings so the same person isn't always taking the 6 a.m. or 10 p.m. call. Managing time zones isn't a scheduling trick you pull off once; it's a set of defaults you decide on and then enforce. Get the overlap window and the async habits right and a team spread from California to Berlin to Bangalore can ship faster than a co-located one, because work stops waiting on the next meeting to start moving.

Map the spread before you decide anything

Start by writing down each person's working hours in UTC, not in their local label. Local names mislead you: "9 to 5" in three cities can mean eight shared hours or zero, and daylight saving shifts the picture twice a year. Convert everyone to a single reference, then you can see the real overlap at a glance. UTC works as that reference because it never changes.

Next, sort people into bands by how far apart they sit. A team running from US Pacific to Central Europe spans roughly 9 hours; add an India-based teammate and you're at 12-13. The number that matters is your widest gap, because that decides whether a single overlap window is even possible. Up to about 8 hours of spread, one daily window usually works. Past 12 hours you're effectively running two partly-overlapping shifts, and you should design a handoff rather than chase a meeting that fits everyone.

A quick way to find your real overlap

How many overlap hours you actually need

There's no universal minimum, but here are honest ranges from how distributed teams operate. Fully async companies run on as little as 0-2 hours and lean hard on writing — GitLab and Zapier have both published detailed playbooks on doing exactly this. Most teams that still want some live collaboration target 3-4 hours of daily overlap. If your work is tightly interdependent — real-time pairing on a gnarly bug, live customer incidents — you'll want 4+ and may have to ask one band to shift their day to get it.

Rough guidance by overlap available

Whatever you land on, publish it. "Our core hours are 15:00-18:00 UTC, Tuesday through Thursday" is a sentence every new hire should read on day one. Ambiguity is what produces the 11 p.m. "quick sync" that quietly burns people out three months in.

Rotate meetings so the pain is shared

When a meeting genuinely needs people across a wide spread, someone is going to be uncomfortable. There's usually no magic slot that works for all, so don't waste a week hunting for one. Spread the discomfort fairly over time instead of dumping it permanently on whoever lives furthest east or west.

A rotation that actually feels fair

A common pattern for two far-apart bands: alternate an Americas-friendly time one week and an Asia-friendly time the next. Over a month everyone takes two convenient meetings and two awkward ones, instead of one band always eating the awkward slot every single time. Write the rotation into a shared calendar a quarter ahead so nobody has to renegotiate it every week.

Make async the default, not the fallback

The biggest unlock isn't scheduling — it's deciding that most communication doesn't need to happen at the same time. Async versus sync isn't all-or-nothing; the skill is matching the mode to the task. Spend synchronous time on things that are genuinely interactive: a contested decision with real disagreement, sensitive feedback, building rapport with a new teammate, a live incident. Push nearly everything else to async, especially status, code review, documentation, and brainstorming, where written ideas are easier to build on a day later.

Sync vs async, in practice

Habits that make async work

The tools worth using

You don't need a big stack. A handful of well-chosen tools covers scheduling, async communication, and the daily "what time is it for them" problem. The ones below are widely used as of 2026, but pricing and features change constantly — check current plans before you commit budget.

A starter playbook

Treat all of this as defaults you can bend, not laws. Some weeks a launch needs more live time; some teammates genuinely prefer a call. The point of fixing the overlap window, rotating the unavoidable meetings, and writing things down is that the exceptions stay exceptions — instead of every day quietly drifting back toward "let's just hop on a call" at a time that's miserable for half the team.