Managing Remote Teams Across Time Zones: Core Hours, Rotation and Handoffs

A team spread across time zones needs a few written rules more than it needs another tool: when people are expected to overlap, who takes the early or late meeting, how work is handed over between regions, and what happens when clocks change. Without them, the same people end up on the 7:00 call every week and nobody notices until they burn out or quit.

This guide covers those four policies with a worked team in San Francisco, Berlin and Sydney. Every time below was computed with the IANA time zone database. For the narrower problem of finding one meeting slot for a given set of cities, see how to schedule meetings across time zones.

Policy 1: define core hours per pair, not per company

"Core hours" only work when everyone's working day actually overlaps. For a New York and London team it does: 9:00 to 12:00 in New York is 14:00 to 17:00 in London for most of the year. That three-hour block can be protected for meetings and quick questions, with the rest of the day left for focused work.

For a team in San Francisco, Berlin and Sydney there is no hour when all three are between 9:00 and 17:00, in any season. A company-wide core hour would put someone at 1:00 or 3:00. The better rule is to define core hours for each pair that does overlap and leave the three-way conversation to async channels and a rotating meeting:

• San Francisco and Sydney overlap for 3 hours in January (14:00 to 17:00 in San Francisco, 9:00 to 12:00 the next day in Sydney) but only 1 hour in July.
• Berlin and Sydney share no core hours. Berlin's 8:00 is Sydney's 18:00 in January and 16:00 in July.
• San Francisco and Berlin share none either. San Francisco's 8:00 is Berlin's 17:00 all year, apart from a few weeks in spring and autumn.

Write the core hours down in each city's local time, because that is what stays constant for the people involved.

Policy 2: rotate the meeting nobody can attend comfortably

If the whole team must meet live, someone is outside working hours. A fair rotation spreads that cost. The schedule below uses three slots, each anchored to one city's morning so it stays at the same local time there all year, and cycles through them week by week.

Three details make a rotation work in practice:

• Anchor each slot to a city, not to UTC. Slot A stays at 8:00 in San Francisco through every clock change. If it were fixed at 16:00 UTC, San Francisco would be at 9:00 in summer and Berlin at 18:00.
• Watch which side of the date line people are on. Slot C is Wednesday morning in Sydney but Tuesday in San Francisco and Berlin. Put both days in the invite.
• Make the unsociable slot optional, with a recording and written notes. If attendance is compulsory, a rotation only spreads the problem around.

Notice that Sydney's bad slot moves from 3:00 in January to 1:00 in July, and Berlin's from 23:00 to 1:00. The seasons change who suffers most, which is one more reason to review the rotation twice a year.

Policy 3: design the handoffs, not just the meetings

Most work in a distributed team moves through written handoffs. If each office works 9:00 to 17:00, the three cities above almost cover a full UTC day, which is the idea behind "follow-the-sun" support and engineering. The gaps and overlaps shift with the seasons:

Where there is no overlap, the handoff note is the whole conversation. A useful note answers four questions:

1. What changed today? Links to the merged work, tickets or documents.
2. What is blocked, and on whom? Name a person, not a team.
3. What decision is needed, and by when? Give the deadline in UTC and in the receiver's city time.
4. What should the next region not touch? Half-finished changes, running jobs, customer conversations in progress.

Agree on a reply expectation too, for example "questions posted before your end of day get an answer before the asker's next start of day". That turns a time difference into a predictable 24-hour loop instead of a series of missed messages. Our guide to async SLA windows covers response targets in more detail.

Policy 4: plan for the daylight saving season

A team in three regions lives through six clock changes a year, on six different dates. Each one moves two of the three gaps by an hour.

For this team the rules to put in the shared calendar are, in calendar order (the date in brackets is the next one):

• Second Sunday in March (14 March 2027): the US moves forward, two or three weeks before Europe. San Francisco to Berlin shrinks to 8 hours and San Francisco to Sydney to 18.
• Last Sunday in March (28 March 2027): Europe moves forward. San Francisco to Berlin is back to 9 hours, and Berlin to Sydney drops from 10 to 9.
• First Sunday in April (4 April 2027): Sydney returns to UTC+10. Berlin to Sydney drops to 8 hours and San Francisco to Sydney to 17.
• First Sunday in October (3 October 2027): Sydney moves to UTC+11. Berlin to Sydney grows to 9 hours and San Francisco to Sydney to 18.
• Last Sunday in October (31 October 2027): Europe returns to standard time. San Francisco to Berlin shrinks to 8 hours for one week, and Berlin to Sydney grows to 10.
• First Sunday in November (7 November 2027): the US returns to standard time. San Francisco to Berlin is 9 hours again, and San Francisco to Sydney reaches 19 hours.

The week before each change, the meeting owner should check every recurring invite and post a short note: which cities move, which meetings shift for whom, and by how much. That five-minute message prevents most of the "I was waiting in an empty call" problems.

Write a one-page time zone policy

None of this works if it lives in one manager's head. A short shared page should state:

• Each person's city and normal working hours in local time.
• The core hours for each overlapping pair.
• The rotation schedule for all-hands meetings, and that late or early slots are optional with notes.
• The handoff note format and the reply expectation.
• The clock-change dates for the coming year and who checks the invites.

For a quick view of where everyone is, the World Clock lists 44 cities sorted by their current UTC offset, with a badge on those on daylight saving time, including Los Angeles (the same zone as San Francisco), Berlin and Sydney. Pin your team's cities to My pins to keep them together. Right now Sydney is 10 hours ahead of Berlin and 19 hours ahead of Los Angeles.

The short version

• Set core hours only where people genuinely overlap, and write them in local time.
• Rotate the meeting that is unsociable for someone, anchor each slot to a city, and make the bad slot optional.
• Treat the handoff note as the main channel between regions with no overlap.
• Put every clock-change date in the team calendar and review recurring invites the week before.

Frequently Asked Questions

How do you set core hours for a team in several time zones?

Find the hours when each pair of locations is between 9:00 and 17:00 at the same time, and protect those hours for meetings. If no hour works for everyone, set core hours per pair and use async updates and a rotating meeting for the whole team.

How should a global team rotate meeting times?

Use a few slots, each anchored to one city's morning, and cycle through them so each location takes the unsociable slot equally often. Make that slot optional, and record it or share written notes.

Why do time differences between offices change during the year?

The US, Europe and Australia change their clocks on different dates, and the southern hemisphere moves the opposite way. A San Francisco to Sydney gap, for example, varies between 17 and 19 hours over a year.

What should a handoff note between time zones include?

What changed, what is blocked and on whom, what decision is needed and by when (in UTC and the receiver's local time), and anything the next region should not touch.

Sources

1. Daylight saving time by country — Wikipedia
2. Daylight Saving Time Rules — NIST
3. Time Zone Database — IANA