ShipZume
Guide

Running a team across time zones

A distributed team either designs around its time differences or is quietly damaged by them. The teams that work well are not the ones with the smallest spread; they are the ones that decided in advance what happens synchronously and what does not. Here is what that looks like in practice.

Open a converterSkip to questions

Core hours, and everything else

The single most useful structure is a short band of core hours where everyone is expected to be reachable, and an explicit agreement that everything outside it is asynchronous. Two to three hours is usually enough. Anything longer starts to require someone to work unsociable hours permanently.

Everything outside core hours needs to work without a live conversation, which changes how people write. Decisions get recorded rather than announced verbally. Questions include the context needed to answer them, because the person replying is eight hours away and a follow-up costs a day. Handover notes replace the corridor conversation.

The failure modes are predictable. The first is a permanently disadvantaged region — one office always taking the 10pm call — which shows up as attrition rather than as complaints. The second is meeting creep, where the core band gradually fills with calls until nobody has focused time. The third is invisible waiting: a question asked at the end of one person's day blocks the other for a full cycle, and nobody measures the delay because no meeting was involved.

None of these are fixed by better conversion tools. They are fixed by writing down which hours are shared, rotating the awkward slots, and treating a written answer as the default rather than the fallback.

Key facts

Two to three core hours

Enough for coordination, short enough to protect focus time.

Rotate the awkward slot

A permanently disadvantaged region loses people, not arguments.

Write decisions down

In a distributed team, an unwritten decision effectively did not happen.

Question latency is the real cost

One badly framed question can block a colleague for a day.

Handover notes beat handover calls

They are searchable and survive holidays.

Watch the transition weeks

Core hours shift in March and October if zones change on different dates.

How to get it right

1

Publish the core band

One short window, stated in every participant's local time.

2

Default to written

Meetings need a reason; documents do not.

3

Structure handovers

A short written summary at the end of each region's day.

4

Audit twice a year

After each daylight saving transition, check the core band still holds.

Questions people ask

Comfortably, about eight hours of spread with a shared core band. Beyond twelve hours you are effectively running two teams that hand over, and it is better to design it that way deliberately.

Keep reading

Daylight saving explained

Which countries change their clocks, when they do it, and why the same two cities can be five hours apart one week and six the next.

UTC, GMT and Zulu time

What UTC actually is, how it differs from GMT, why aviation says Zulu, and when the distinction matters.

Scheduling across time zones

A practical method for booking meetings across zones: finding the overlap, rotating the pain, and stopping recurring calls from drifting.

Find your team's overlap

The meeting planner shows shared working hours across several cities.

Open the converters