🌍 Time-Zone Overlap Windows: Picking a Core Hours Window That Works
Distributed teams need a few hours of shared overlap to function. The window you pick determines whether your team thrives or quietly burns out on one side of the world.
The dirty secret of distributed teams is that "we work across time zones" usually means "the engineers in India come on at 8 PM their time so they can overlap with San Francisco." For a while everyone smiles through the misalignment. Eventually the engineers in India quit and you wonder why retention is bad in your APAC office.
Core overlap hours are how mature distributed teams avoid this trap. The window you pick — and the rules around it — determine whether the team functions or quietly grinds down the people in the worst-positioned time zone.
What "core hours" actually means
Core hours are a window each weekday when everyone on the team is expected to be reachable for real-time conversation. Outside core hours, work continues asynchronously. The narrower the window, the more freedom employees have to structure their day; the wider the window, the more synchronous coordination the team can do.
The mistake everyone makes the first time is to pick core hours that work for the location with the most people, on the assumption that "the others can flex." Two outcomes: either the minority location actually flexes and gradually burns out, or they pretend to and you lose the benefit of having distributed coverage at all.
The fairness calculation
The non-negotiable rule: no employee should regularly work outside their local 8 AM – 7 PM window because of core hours. That is the band where you can reasonably have a family life, eat dinner at a normal time, and avoid the chronic sleep displacement that destroys long-term productivity.
Within that constraint, you maximize the overlap. For a US-EU team that usually means 9 AM – 12 PM Eastern, which corresponds to 2 PM – 5 PM London. For a US-India team that almost always means a narrower window — maybe 8 AM – 10 AM Pacific / 8:30 PM – 10:30 PM India Standard Time. Anything more than that and one side is up too late or up too early.
Worked examples
San Francisco + New York + London
Core hours: 9 AM – 12 PM Eastern (6 AM – 9 AM Pacific, 2 PM – 5 PM London). This works because Londoners are still in their workday; Californians start a little early but not painfully so.
New York + Bangalore
Core hours: 8 AM – 10 AM Eastern (5:30 PM – 7:30 PM India). The window is narrow because the time difference is so large. Use it for real-time decisions; do everything else async.
Berlin + Singapore + Sydney
Core hours: 3 PM – 5 PM Berlin (9 PM – 11 PM Singapore, 11 PM – 1 AM Sydney). Sydney is the squeezed party here — Berlin has to give a little or you cannot include Australians at all. The honest answer is often "Sydney joins one shared call a week; everything else is async."
Three or more zones spanning more than 11 hours
You probably cannot have universal core hours. Pick "anchor pairs" instead: two zones share core hours with each other, the third zone gets weekly written briefings. Do not pretend.
The role of meeting hygiene
Core hours work because they are not a meeting block. They are a reachability block — most of the window is regular work, with the option to grab someone for a quick conversation. If your team turns core hours into "the time when all the meetings happen," you have eliminated the productive overlap you were trying to create.
A reasonable target is that no more than 25% of core hours are scheduled meetings. If you blow past that, kill or async-ify some meetings before extending the window.
What workforce-analytics data tells you
If you use monitoring or activity-tracking tools, the actual-work-hour distribution data is a useful sanity check on your core-hours policy. If a meaningful share of your APAC team consistently shows active work past 10 PM their local time, the policy is broken, not them. Adjust before the resignations start.
The 4-day-week conversation
Several distributed companies have moved to a 4-day workweek partly to compensate for the burden of cross-time-zone work. The argument is not "we work 32 hours a week" but "we work focused, async-heavy 32 hours a week and reclaim the rest." It is not a fit for every team, but it is worth raising if your distribution is heavy in one direction.
Closing thought
Time-zone overlap is one of the few areas of distributed work where the policy is more important than the tooling. Pick the window your worst-positioned employees can sustain for years — not weeks. DeskTrust includes time-zone-aware work-hours reporting so you can verify that policy and reality match.
See DeskTrust in action
Trusted by teams that need real visibility without the surveillance feel.