I lead engineering teams across three cities.
The question I get asked most is some version of "how do you manage the timezones?" I've started answering it with a different question: why does your team need you to manage the timezone at all?
Most distributed leadership advice is synchronization advice in disguise. Better tools. More overlap. Earlier standups. These things are fine but they're aimed at the wrong problem.
Most distributed leaders don't have a timezone problem. They have a dependency problem, and the timezone just exposes it.
Their team in China can't make a decision at 12pm without waiting for Toronto to wake up. That's not a timezone problem. That's a design problem that was already there. The gap just made it visible.
Clarity Is the Only
Timezone That Matters
Every month I publish a priorities list for the entire organization. The purpose isn't to tell people what to work on - they know their jobs. The purpose is to answer, in advance, every question about competing demands: Is this new thing worth my time? Does this initiative matter right now?
When an engineer in Shanghai gets pulled toward something at 12pm, they don't need to email Toronto and wait eight hours. The list tells them what I would say if they could ask me. This works because the organization has real layers - managers and leads at every level with the authority to act, not just escalate.
Clarity isn't a leadership virtue at 12 hours apart. It's a physical requirement. Every ambiguity you leave in a goal or a priority gets multiplied by the gap. You cannot clarify at 3am, so you clarify before anyone needs it.
One Culture.
Three Cities.
Here's where I'll probably disagree with most of what you've read on this topic.
The conventional wisdom says adapt to local culture. Be sensitive to how different geographies work, communicate, and relate to hierarchy. I don't follow it.
I insist on one culture across all three cities. Not Toronto culture exported everywhere - one culture that belongs equally to everyone, regardless of where they sit.
What that culture actually is:
Culture isn't a values poster. It shows up in how you work and what you actually do together.
The reason this works across three cities: if culture is implicit, you need proximity to absorb it. If it's explicit - a set of principles everyone has agreed to - it travels. An engineer in Belgrade and an engineer in Toronto can operate from the same playbook without being in the same room because the playbook isn't stored in the building. It's stored in the team.
None of this eliminates hard cross-site collaboration. When a critical debug problem spans weeks - two syncs a day, Canada handing off to China, China handing back - it's brutal. What we do: minimize the coordination surface. Delegated leads from each site gather information internally, then meet with each other. You compress the cross-timezone interaction to the smallest viable interface. It helps. It doesn't solve it.
The priority list, the culture, the delegation - none of it works unless you build it before the problem appears. It's unsexy work. It happens before anything breaks. It doesn't make a good war story.
But the timezone is honest. It will show you exactly what you built.
you built something.
If it waits for you,
you haven't.