Back to blog
Distributed Teams

Overlap Hours Distributed Team

5 min read
overlap hours distributed teamdistributed teamstime zonesasync workremote engineering

The short version

  • The number of overlap hours a team needs depends on how much work relies on live answers.
  • Reduce that dependency and a small window is plenty; keep it high and no window is ever enough.
  • Spend the overlap you have on real decisions, not on status you could have written.
  • Your StandIn answers from what you wrote down while you are off, and never guesses.

A distributed team needs only as many overlap hours as its work genuinely requires live answers for, which for most teams is a small window, not a large one. The size of the overlap matters far less than how many tasks cannot move without two people awake at the same time.

This reframes the usual planning question. Teams try to engineer more overlap, shifting hours until people are tired, when the better move is to reduce what depends on the overlap in the first place. The waiting that hurts a distributed team does not come from a short window; it comes from routing work that could have been written through a window that only opens for an hour. When your work answers from the record, the window can be short and the team still moves.

Why "how many hours" is the wrong question

Ask "how many overlap hours do we need" and you get an arms race: more hours always sounds safer, so people chase them at the cost of sleep and focus. But two teams with the same overlap can have wildly different experiences. One flows because almost nothing waits on the window. The other jams because every decision is funneled into it.

So the useful question is not how big the window is, but how much you are asking it to carry. A small window carrying only true decisions beats a large window clogged with status. We make the cost side of this concrete in the timezone tax, measured in whole nights, and the mechanics of the handoffs that keep work out of the window in engineering handoffs: what breaks and why.

What genuinely needs live time

Only a few kinds of work truly need people awake together. Being honest about the list is how you free up the rest.

  • Open-ended design debate: when the shape of a solution is still contested and needs fast back-and-forth.
  • Live pairing on something gnarly: a bug that needs two sets of eyes and quick iteration.
  • Decisions with real trade-offs and stakeholders: where reading tone and reacting in the moment matters.
  • Relationship and trust building: the human glue that keeps a distributed team a team.

Almost everything else, status, routine questions, handoffs, "why did you do it this way", can be written. If it can be written, it should not be spending your scarce overlap. The rhythm for keeping it out of the window is an async handoff process nobody has to be awake for.

How to spend the overlap you have

Treat the overlap window as your most expensive resource, because it is. Protect it. When Sarah in Tokyo and Alex in Amsterdam share only a short window, filling it with a status readout is a waste; both could have read that in their own time. Use the window for the design argument that would take a week to resolve in writing, and push the status into the record where it belongs.

The day-to-day discipline for this is in working across time zones without the 8 PM ping. The habit to build is simple: before you put something in the live window, ask whether it could have been a written note instead. Most of the time it could.

Shrinking the dependency itself

The real lever is not scheduling, it is reducing how often anyone needs a live answer at all. Every answer that lives in the record is one the team does not have to wait for the window to get. That is what your StandIn does. It answers for you when you are off, on your behalf, from your brief and your team's record, so a colleague in another zone gets your answer without needing you awake. When the record holds the answer, it gives it in your words. When it does not, it says so, rather than guessing, so nobody acts on an invention while you sleep.

The more your team writes down, the smaller the overlap you need, because fewer questions require a live person to resolve. A team that onboards this way barely notices thin overlap, which is why onboarding a remote engineer when nobody is free to explain works the same way.

Common Questions

Is there a minimum overlap every distributed team needs?

There is no universal number, because it depends entirely on how much of your work depends on live answers. A team that writes things down well can function with very little; a team that does not will feel starved no matter how much it has.

Should we ask people to shift their hours to create more overlap?

Only as a last resort. Shifting hours moves the cost onto individuals in the form of odd schedules and lost sleep. It is usually cheaper to reduce the dependency on live time than to manufacture more of it.

How do we know if our overlap is being wasted?

Look at what fills it. If your shared window is mostly status updates and routine questions, it is being wasted, because both of those can be written and read on each person's own schedule.

Can a team work with zero overlap?

It is hard but possible for stretches, if the record is strong and there is an escalation path for emergencies. Most teams do better with a small deliberate window reserved for the few things that truly need it.

The right amount of overlap is however much your true live-only work needs, and no more. Shrink the dependency by writing your work down and letting your StandIn answer from it, and a short window stops feeling short. Check your team's real overlap with the timezone overlap tool.

Get async handoff insights in your inbox

One email per week. No spam. Unsubscribe anytime.

Ready to retire your daily standup?

Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.

You might also like