There's a number you can use to predict, with surprising accuracy, whether a distributed team will work or quietly fall apart.
The number is four. As in four hours.
If every person on your team is awake and at their desk during the same four-hour window each day, you have enough real-time bandwidth to operate as a coordinated team. You can hold one meeting, run a quick decision, answer a question, unblock someone. Four hours is just long enough for the team to be a team.
If the overlap is less, you're a distributed group that occasionally synchronises. That can absolutely work, but it requires a completely different set of operating defaults. Teams that don't make that switch consciously tend to fail in ways that look like personality problems but are actually math problems.
This guide is about that number. Where it comes from, how to find yours, and what to do if it's smaller than you'd like.
Where the four-hour figure comes from
Nobody published a research paper proving four hours is the right number. It's the consensus that distributed-team operators have arrived at by trial and error.
Why four and not three or five?
Working backwards from a typical day:
- One hour for a daily standup or check-in, plus its informal aftermath.
- One hour for ad-hoc questions and conversations.
- One hour buffer for unexpected things — a customer escalation, a design review that has to happen now.
- One hour for one scheduled meeting.
That's four. Three works for many days, but the moment you have a busy week, you start cutting into someone's personal time. Five is a luxury most globally distributed teams can't afford.
When teams describe their overlap as "two or three hours and it's fine," what's usually true is that one or two team members are quietly extending their working day to make it possible. Sometimes that's sustainable. Often it's not. The ones quietly stretching are the ones most likely to leave.
How to calculate your team's actual overlap
Here's the math, simplified.
For each team member, write down their local working hours. Use a conservative 9am–6pm by default, or the actual norm in their country if it differs. Don't use 8am–8pm "I'm always available" hours — use the hours you'd want them to actually keep.
Convert all of those to a single reference time zone (UTC is easiest, or whichever zone your largest cohort lives in).
The overlap is the range where every person's working hours simultaneously include the same time.
A worked example. Say your team includes:
- A team member in San Francisco (Pacific time, UTC-8 in standard time). Working hours: 9am–6pm PT = 5pm–2am UTC.
- A team member in New York (Eastern time, UTC-5). Working hours: 9am–6pm ET = 2pm–11pm UTC.
- A team member in London (UTC+0). Working hours: 9am–6pm GMT = 9am–6pm UTC.
- A team member in Bangalore (IST, UTC+5:30). Working hours: 9am–6pm IST = 3:30am–12:30pm UTC.
The overlap is the intersection of all four ranges:
- San Francisco: 5pm–2am UTC
- New York: 2pm–11pm UTC
- London: 9am–6pm UTC
- Bangalore: 3:30am–12:30pm UTC
The intersection is from 5pm UTC (when San Francisco starts) to 12:30pm UTC (when Bangalore ends). Which is to say, it doesn't intersect at all in the conventional direction — 5pm is later than 12:30pm.
This team has zero hours of natural overlap. To make it work, somebody has to be out of their standard hours every single day. That's a real team many companies operate. It's also one of the most common reasons distributed teams fall apart silently.
If you'd like to skip the math, you can drop your team's cities into besttimefor.io and it'll show you the overlap window visually.
What to do if your overlap is less than four hours
This is the conversation distributed teams need to have explicitly and don't.
You have three options, and only three:
Option 1: Shrink the team's geography
The simplest answer. Hire only in time zones that maintain a four-hour overlap with your existing team. If you're a US East Coast team, you can hire across the US, in South America (especially Brazil and Argentina), and in Western Europe. You probably can't sustainably hire in East Asia or Australia for sync-default roles.
This isn't a popular answer because it limits the talent pool. But it's the option that preserves the most "normal" working day for everyone.
Option 2: Designate a "stretch" zone
One geography agrees to extend their day to make overlap work. This is the implicit default in many companies — usually the team member furthest from the centre of gravity, often a non-US team member working with a US-centric team.
Make this explicit. If a team member is regularly working until 9pm or starting at 6am to maintain overlap, that should be acknowledged, compensated where appropriate, and rotated where possible. The unfairness of the "stretch zone" is the second most common reason distributed teams fail.
Option 3: Go async-first
The team accepts that real-time conversation will only happen occasionally and operates almost entirely in writing. Decisions are made in documents with explicit deadlines. Meetings are rare, scheduled days in advance, and recorded.
This is the option most likely to work for teams with zero natural overlap, but it requires a culture shift. Sync-first teams that try to bolt async practices on top fail more often than they succeed.
The myth of "I'll just work flexible hours"
A common pattern: the team has uncomfortable overlap, and the leader says "we operate flexibly, just take meetings when they work for you, and don't worry about being online at all hours."
This sounds healthy. In practice, it punishes the conscientious. The team members most likely to take that flexibility at face value are the ones who already feel secure. The ones who are newer, or in countries with different professional norms, or just more anxious, will quietly shift their schedule to accommodate the team's centre of gravity. They'll burn out faster.
The kinder approach is to be explicit about hours and protect them. Say: "Bangalore office hours end at 6:30pm local. We won't schedule a meeting after that without explicit consent." Then enforce it.
Two specific protocols for protecting overlap
If you have an overlap window and you'd like to keep it useful, two protocols help.
The 30-minute decision window
Reserve one specific 30-minute slot in the middle of your overlap, every working day, for decision-making conversations. Nobody is required to attend, but the slot exists. If you have a thing that needs a real-time discussion, it goes there.
Two effects:
- People stop scheduling decision meetings throughout the overlap. The window opens up.
- People stop trying to escalate decisions via chat with 12-hour gaps between messages.
After a few months, the decision window becomes the only meeting most days. You've reclaimed the rest of the overlap for ad-hoc collaboration.
The "no surprise meetings outside overlap" rule
If a meeting needs someone to attend outside their normal working hours, the meeting is scheduled at least 48 hours in advance, and the person being inconvenienced has explicit veto. The exception is genuine emergencies (a customer escalation, a security incident), which are clearly emergencies and not "we forgot to plan."
This rule sounds bureaucratic, but it ends the pattern where well-meaning managers ping someone at the start of the day with "got 30 minutes now?" and the person feels they can't say no.
When more overlap is the right answer
Sometimes the right answer isn't to optimise the schedule — it's to optimise the team. If you're hiring and you have the choice between two strong candidates, one in a zone that adds two hours of overlap and one in a zone that subtracts two, the answer is often the first one.
This isn't about being unfair to international candidates. It's about being honest with them. If a role requires four hours of overlap and the candidate's zone makes that impossible, they will struggle to succeed in that role no matter how good they are.
Some companies handle this by having explicit "this role requires overlap with X timezone" in job posts. It feels blunt, but it's kinder than offering the role and then watching the new hire burn out.
The check-in to run with your team
Once a quarter, ask each team member two questions:
- What's the latest meeting you've taken in the last three months, in your local time?
- How many times in the last month have you adjusted your personal schedule to accommodate a meeting?
If you see a pattern — one or two team members consistently taking meetings after 8pm or before 7am, or adjusting their personal schedule more than weekly — your overlap is too thin and the cost is being absorbed by the same people every time.
Fix that before it becomes a resignation.