Running a Team Across Time Zones

The time zones that let you hire a great engineer in Bangalore are the same ones that put your standup at 6 AM for someone in Sydney. That tradeoff is real and it doesn't go away. What changes is how much it costs you, and that depends almost entirely on whether you've built your working habits around the spread or against it.

What Actually Goes Wrong

Spread a team across San Francisco (UTC-8), New York (UTC-5), London (UTC+0) and Singapore (UTC+8) and there is no hour of the day when all four are awake and working. Everything downstream follows from that:

• A question asked at 5 PM in San Francisco isn't answered until the next working day, so a task that needs three exchanges takes three days
• Every synchronous meeting puts somebody outside their working hours, and it's usually the same somebody
• Handoffs lose the details that would normally get sorted out in a two-minute conversation, because there is no two-minute window to have it in

None of these are time zone problems exactly. They're what happens when a team keeps operating as though everyone is in one office.

Communication

1. Get good at not needing an answer right now

If a global team depends on quick replies, it will move at the speed of its worst overlap window. Working asynchronously well is the thing that makes the rest possible.

• Write it down. A decision made in a meeting that half the team slept through hasn't really been communicated. The document is the record, not the call
• Send the whole question. "Can you check this?" costs a full day when the answer depends on a follow-up. Include what you need checked, why, and what happens next
• Make status updates readable cold. What you did, what you're blocked on, what you need from whom
• Record anything that matters. Somebody will always miss it live

Notion, Confluence, a GitHub wiki — the specific tool matters less than whether knowledge is searchable by someone who wasn't there.

2. Agree on response times explicitly

Without a stated norm, people invent their own. One person answers Slack at midnight, another leaves urgent messages for two days, and both think they're behaving reasonably. Write down:

• Which tool carries which kind of message
• Expected response windows — say, 24 hours for normal, 4 hours for important, and a separate channel for genuine emergencies
• What actually justifies interrupting someone outside their hours
• How to mark something urgent, and the understanding that overusing it stops it working

The point is that nobody should have to guess whether an 11 PM message needs an 11 PM reply.

Meetings

1. Hold fewer of them

A meeting across six time zones costs several people their evening or their early morning. That price is worth paying sometimes, but it's worth asking first:

• Could this be a document people read and comment on in their own hours?
• Are we deciding something, or discussing whether to decide it?
• Who actually needs to be here, rather than who'd be mildly annoyed to be left out?

Collaboration doesn't require simultaneity. A written proposal with comments often produces better thinking than a call, because people get time to actually consider it.

2. Rotate who takes the bad slot

When a meeting genuinely has to be synchronous, somebody is going to be inconvenienced. Make sure it isn't the same person every week:

• One week the Asia-Pacific members get the comfortable hour
• The next, Europe does
• The next, the Americas

A permanent 5 AM call is the kind of thing people quietly tolerate for months and then leave over, and the rotation costs you nothing but a recurring calendar edit.

3. Use the spread deliberately

A wide spread means work can move around the clock — Asia hands off to Europe, Europe to the Americas, the Americas back to Asia. It's genuinely useful, but it depends entirely on the quality of the handoff. Without clear "done" criteria and written context, follow-the-sun just means each region spends its first hour working out what the last one left behind.

4. Protect the overlap you have

Most distributed teams have a narrow window where enough people are awake at a civilised hour. Find it and guard it:

• Keep everyone's time zone visible somewhere shared, and update it when people travel
• Look for windows that don't require anyone before 7 AM or after 10 PM
• Don't spend that window on status updates that could be written down
• Save it for the discussions that genuinely need everyone thinking at once

TimeZonder's meeting planner will find those windows for you, which is faster than working them out by hand every time somebody relocates.

Keeping a Team Together

1. Build in the social contact that used to happen by accident

You lose the hallway conversations and the "grabbing coffee, want anything?" moments once everyone's remote, and losing them across time zones is worse, because there's no overlap window where those moments could even happen by accident. You have to build them on purpose:

• Virtual coffee or lunch sessions between compatible time zones
• Asynchronous social channels — #random, #pets, whatever people actually use
• Optional games or team activities
• Occasional in-person retreats, where budget allows

It sounds soft, but it isn't: people cut each other more slack during a rough sprint when they actually like each other, and that matters more, not less, when your only interactions are scheduled.

2. Make the time difference visible

Most time zone friction isn't malicious, it's just invisible — nobody means to schedule over someone's dinner, they just forgot dinner exists in Berlin right now. Make the invisible visible:

• Show local times in shared tools and email signatures
• Keep world clocks on the team dashboard
• Track holidays and cultural observances across every region you employ in
• Give deadlines in more than one time zone, or in UTC

None of this is complicated. It just has to be someone's actual job, instead of everyone assuming someone else already did it.

3. Set boundaries and have leadership keep them

When your team spans time zones, a "quick question" sent at your 2 PM can land in someone's 11 PM — and if there's no norm against answering it, someone eventually will, and then everyone will feel like they have to. Draw the lines on purpose:

• Have people state their working hours, and record them somewhere visible
• Treat do-not-disturb and time off as real
• Watch for the implicit expectation of always being reachable
• Expect leadership to model it, because the team reads behaviour over policy

People who aren't dreading a 10 PM Slack ping do better work at 10 AM. That's really the whole argument.

Tools

None of this works on goodwill alone. Here's what actually holds it together:

• Time zone converters: TimeZonder, World Time Buddy, or Google Calendar's world clock
• Asynchronous video: Loom or similar, for explanations that would otherwise be a call
• Documentation: Notion, Confluence, or GitHub wikis
• Project management: Asana, Trello, Jira or Monday.com, with status kept current enough to read cold
• Collaborative design: Figma, Miro or FigJam

Favour tools that default to asynchronous and escalate to real-time when needed, rather than the reverse.

A Worked Example

To make the scheduling concrete, take a hypothetical five-person team:

• San Francisco (UTC-8) — Product Manager
• New York (UTC-5) — Frontend Developer
• London (UTC+0) — Backend Developer
• Bangalore (UTC+5:30) — QA Engineer
• Sydney (UTC+11) — DevOps Engineer

A 9 AM standup in New York is 6 AM in San Francisco, 2 PM in London and 7:30 PM in Bangalore — workable, if early on one end and late on the other. It's 1 AM in Sydney, which is not workable at all, so that role joins asynchronously and the team accepts it rather than pretending otherwise. Sprint planning splits into two sessions, one for the Americas and Europe and one for Asia-Pacific. Code review follows the handoff pattern, moving roughly every eight hours.

The specific times matter less than the principle: work out where the genuine conflicts are, then decide deliberately who absorbs them and how often.

The Short Version

Running a team across time zones is never effortless — you're working against geography, and geography doesn't care about your sprint deadlines. But most of the pain isn't the time difference itself. It's scheduling meetings and hoping people show up, leaving decisions undocumented and hoping nobody needed them, treating constant availability as commitment rather than as the thing that burns people out.

Write things down. Rotate who has to wake up early. Protect the few hours when everyone's genuinely online. Do that consistently and the distributed team becomes the better arrangement, because you get to hire people you'd never have found within commuting distance of one building.