How remote-first companies actually handle time zones

Search "remote team overlap hours" and you'll find plenty of advice repeating a tidy "2 to 4 hours a day" rule as though it's an industry standard. It isn't, at least not among the most transparent, longest-running remote-first companies. What they actually document is more interesting, and more useful.

Why "2-4 hours of overlap" isn't a real rule

We looked at the public handbooks of some of the best-known all-remote companies, and none of them mandate a fixed daily overlap window company-wide. GitLab's meetings handbook talks about structuring meetings around regional overlaps between adjoining clusters of time zones, not one number that applies everywhere. Automattic, fully distributed since 2005 with no central office, sets no fixed schedule at all beyond what individual teams agree among themselves.

What real companies actually do

• GitLab recommends pairing adjoining regions, EMEA with APAC, APAC with the Americas, the Americas with EMEA, rather than expecting every meeting to fit one global window.
• Automattic has no company-wide required overlap. Scheduling is negotiated at the team level, based on who's actually on that team.
• Zapier operates async by default, with live-overlap expectations reserved for specific collaborative roles rather than applied as a blanket company policy.

A practical method for your own team

Rather than importing someone else's rule, it's more useful to map your actual team:

1. List each person's real working hours in their own local time, not an assumed 9-to-5.
2. Convert everyone to one reference time and find where the ranges genuinely intersect.
3. Protect that specific block for anything that truly benefits from being live.
4. Push everything else to async by default, rather than trying to stretch the live window to cover it.

What about companies that do suggest a number?

A few secondary sources describe Doist, the makers of Todoist and Twist, aiming for new hires to have at least some meaningful overlap with the wider team, sometimes cited as roughly half the working day. That figure isn't confirmed on Doist's own site, so treat it as a data point rather than a rule, but it's a useful sanity check: even the softest guidance skews toward "some overlap is healthy," not "zero overlap is fine," and not "you need eight hours either."

The absence of a universal number isn't an oversight, it's the actual lesson. A rule that works for a two-region team (say, US and UK) would be meaningless for a three-continent one, and vice versa. That's exactly why none of these companies' public handbooks commit to a figure: any single number would be wrong for most of their own teams.

Seeing it, instead of calculating it

The step most teams skip isn't the policy, it's actually seeing the overlap. Atlas shades each teammate's working hours on a live map, so the block where everyone's genuinely available is visible at a glance, instead of a spreadsheet you built once and never update.