Tips for working across time zones without living on calls

A team spread across San Francisco, London and Singapore has no hour of the day when all three are at their desks in normal working time. Somebody is always early, late or asleep. The teams that cope well with this have stopped trying to find the perfect meeting slot and started designing their work so that fewer things need one.

These tips are for team leads setting up how a distributed team works, and for individuals who’ve just joined one.

Map the real overlap first

Before changing anything, write down each person’s working hours in their local time, then convert everything to UTC. A simple table does it:

Now the shape is obvious. B and C share a three-and-a-half-hour window. A and B share five and a half. A and D overlap only at the very edges of their days. C and D share about half an hour.

That map tells you which pairs can collaborate live and which must hand work across. Pin it somewhere everyone can see, and update it when someone joins or moves.

Decide what actually needs overlap

Most work doesn’t. Status updates, reviews, feedback on documents and routine questions all work asynchronously if the messages are written well. Our guide to async communication for remote work covers how.

The things that genuinely benefit from real-time overlap are narrower: resolving disagreements that have stalled in writing, sensitive conversations, quick back-and-forth on a new idea, and helping someone who is stuck. Protect overlap hours for those, and keep them free of status meetings.

Standups are the usual first casualty. A written standup works across any spread of time zones; our async standup template has a format.

Rotate the inconvenient slot

If the whole team does need to meet, someone will be on at an awkward hour. The fair approach is to rotate who that is, rather than letting it settle permanently on the people furthest from head office.

A simple rotation: three meeting times that each favour a different region, used in turn. Record the meeting for anyone who can’t make it, and post written notes within a day. Nobody should have to attend at 23:00 to stay informed.

Write every time with a zone

“Let’s meet at 3” is meaningless in a distributed team. Always include the zone, and preferably use UTC for anything shared across regions: “Thursday 15:00 UTC”. Many people find it easier to add their own local time in brackets as a courtesy.

Calendar tools help. Google Calendar, for instance, can show a secondary and a tertiary time zone alongside your own, and has a world clock setting. Turn these on for the zones you work with most.

Plan for the clock changes

Daylight saving is where distributed teams quietly break, because different countries change their clocks on different dates.

In the US, NIST explains that daylight saving time starts on the second Sunday of March and ends on the first Sunday of November. In the UK, GOV.UK lists the clocks going forward on the last Sunday in March and back on the last Sunday in October. In 2027, that means:

• 14 to 28 March 2027: the US has moved its clocks, the UK hasn’t. New York is four hours behind London instead of five.
• 31 October to 7 November 2027: the UK has moved back, the US hasn’t. Again, four hours instead of five.

During those weeks, a recurring meeting set in one time zone moves by an hour for the other. Some people turn up early, some miss it entirely. Some countries don’t change their clocks at all, which adds more combinations.

The fix is boring and effective: put the changeover weeks in the team calendar each year, and post a reminder the Friday before with the affected meetings listed.

Write handoffs, not just updates

When work moves between time zones, the end-of-day note is the most important message of the day. A good handoff answers three questions:

1. What did I finish, and where is it?
2. What’s in progress, and what state is it in?
3. What does the next person need to decide or do, and is anything blocking it?

Five minutes spent on a handoff saves the next person an hour of reconstructing what happened. Put handoffs in a consistent place, such as a thread per project, so they’re searchable later.

Protect everyone’s evenings

Time zones make it easy for working hours to stretch, because there’s always someone online. A few habits keep that in check:

• Schedule messages for the recipient’s morning rather than sending at their midnight.
• Set a notification schedule in your chat tool, so you aren’t pinged outside your own hours.
• Make the urgent route explicit. If something really can’t wait, there should be a named way to reach someone (a phone call or an on-call alert) so ordinary messages never need to be treated as urgent.

The point isn’t to be precious about hours. It’s that a team permanently half-online at all hours gets tired and slow, and the people on the far side of the map usually pay the most. For the wider team rules this fits into, see remote team communication strategies.

Time zone rules for your handbook

TIME ZONE RULES

1. Everyone's working hours are listed in local time and UTC at [link].
2. Shared times are written in UTC, e.g. "Thu 15:00 UTC (your local time)".
3. Overlap hours ([window] UTC) are for live problem-solving, not status.
4. Standups and status updates are written, not live.
5. Team-wide meetings rotate between [3] slots; all are recorded with notes
   posted within 24 hours.
6. Every handoff answers: finished, in progress, what the next person needs.
7. Messages outside the reader's hours are scheduled for their morning.
8. Urgent = [phone / on-call route]. Nothing else is urgent.
9. Clock-change weeks are in the team calendar; reminder posted the Friday
   before (2027: 14-28 March and 31 Oct-7 Nov for US/UK).
10. The overlap map is updated whenever someone joins or moves.