Most advice about distributed teams stops at "find your overlap hours," as if the only problem time zones create is scheduling a meeting. The bigger problem shows up after the meeting ends: decisions made while half the team was asleep, and no clean way for the people who weren't there to catch up or push back.

Overlap hours solve the wrong problem

A two-hour overlap window is enough for a meeting. It's not enough to run a team, because it quietly trains everyone to treat that window as the only time real decisions can happen — which means the people outside it either stay up late to be included or get left out of things that affect them. Teams that handle this well treat the overlap window as one input, not the whole system.

What actually works

  • A default 24-hour response window, not an expectation of instant replies. Written down explicitly, so nobody has to guess whether a slow reply means something's wrong.
  • Decisions get written down before they're final. A short doc — the question, the options, a deadline for objections — gives someone in a different time zone a real chance to weigh in before the decision is locked, instead of finding out about it after the fact.
  • Meetings rotate who has to stay up late. If the same region always takes the inconvenient time slot, resentment builds quietly and shows up later as disengagement. Rotating the discomfort, even imperfectly, signals that everyone's time is being weighed the same way.
  • Recordings and notes are the default, not a favor. A meeting that isn't documented effectively didn't happen for anyone who wasn't in the room. This should be built into how meetings are run, not something someone remembers to do occasionally.

The goal isn't to make everyone available at the same time. It's to make sure decisions don't require it.

The overlap window is still worth protecting

None of this means overlap hours don't matter — they're where relationship-building, fast back-and-forth, and genuinely hard conversations happen best. The mistake is treating that window as the only place work can move forward. Protect it for the things that actually need real-time conversation, and build the rest of the system so it doesn't depend on everyone being awake at once.

A simple test

If someone on the team went offline for four days with no notice, would the decisions made during that stretch still make sense to them when they got back — and would they have a real way to raise a concern? If the honest answer is no, that's usually a sign the team is over-relying on synchronous overlap and under-investing in the async layer underneath it.