Follow-the-sun delivery: leading a team split across three time zones

The pitch promises progress around the clock. The real Tuesday is Bangalore waiting nine hours for a one-line answer. Closing that gap is the actual job.

The sales pitch is gorgeous. Three teams, three time zones, one product that never sleeps. Toronto builds and hands to Bangalore. Bangalore builds and hands to Warsaw. Warsaw hands back to Toronto, and your release moves around the clock while competitors crawl along on eight hours a day. There's always a diagram: a globe, some arrows chasing the daylight.

Now here's an actual Tuesday. At ten in the morning, Bangalore time, a developer hits a config question only Toronto can answer. She posts it and picks up something smaller. Toronto is asleep. Toronto wakes up, runs standup, clears email, and replies at 9:30 their time. One line: yes, use the staging values. It lands at seven in the evening her time. She's gone. She reads it tomorrow.

Nine hours for one sentence, and the task lost a full day. On the brochure, that work flows around the planet. On the board, it sat still while the planet rotated underneath it.

I've watched teams live in that gap long enough to decide follow-the-sun is a scam. It isn't. They were running it on default settings.

The model doesn't fail on time zones. It fails on handoffs.

Time zones are physics. You can't manage the Earth's rotation, and you don't need to, because rotation was never the problem. Look at that Tuesday again. At every hour of the day, somebody on the team was awake and working. The work still stalled. So the delay didn't come from when people work. It came from the seam where one zone stops and the next one starts.

Here's the uncomfortable truth: your process is only as fast as its slowest handoff. A relay team doesn't lose the race on the straights. It loses it in the exchange zone. Follow-the-sun promises three straights a day and quietly triples your exchange zones. Run those exchanges badly and you didn't buy 24 hours of progress. You bought three eight-hour teams, each spending its first hour figuring out what the last one meant.

So the job isn't "coordinate across time zones." The job is narrower and harder: make the seams carry weight. Four moves do most of the work.

The overlap hour is the most expensive real estate you own

Lay the three working days on one 24-hour line and the shape is blunt. Bangalore and Warsaw share a morning. Warsaw and Toronto share two afternoon hours. Bangalore and Toronto share nothing. Not one hour, ever. Everything between those two sites travels by handoff or it doesn't travel at all.

Those thin slices are the only moments when real-time conversation exists, which makes them the scarcest resource the team has. And most teams spend them on status.

Think about that trade. The one window where a disagreement can die in four minutes instead of four handoffs, booked solid with people reading Jira tickets to each other.

The rule I coach is simple: nothing lives in the overlap that could have been written down. Status is a document. Progress is a document. The overlap exists for decisions, disagreements, and unblocking, the three things that genuinely degrade over async. Run it like a court docket: a short list of calls to make, an owner named for each, done in 25 minutes. It feels abrupt for the first two weeks. It's also the hardest-working half hour on your calendar.

One more distinction, because it matters. Your two overlap windows aren't interchangeable. The wide morning window can afford working sessions. The two afternoon hours that touch Toronto carry every decision that crosses the Atlantic. Protect the scarce one hardest. When somebody parks a recurring status call in it, that isn't a calendar event. It's an outage.

The handoff note is infrastructure, not paperwork

Between overlaps, everything your team knows travels in writing. That's the part nobody puts on the brochure. In follow-the-sun, async writing stops being a nice-to-have and becomes the operating system.

The core artifact is the handoff note, and most teams write it like a diary entry. "Made progress on the payments API. Some issues with the test environment. Will sync tomorrow." That note transfers nothing. Warsaw reads it, learns nothing they can act on, and either guesses or waits. There goes the day the model was supposed to buy you.

A handoff that works answers three questions, in writing, every single day:

• What moved. Not "progress on payments." Which pieces finished, where the code sits, what changed since the last note.

• What's blocked, and by what, exactly. "Blocked on staging config: is the rate limit 100 or 500? Ticket PAY-212 has both values in the comments."

• What decision is needed, from whom, by when. "Need Toronto's call on the limit before 15:00 UTC or we ship the conservative one."

Write it like the next zone knows nothing, because functionally they do. They weren't in your hallway conversations. They can't tap your shoulder. The note is the only version of you that's awake when they are.

Teams push back because it feels like paperwork. It isn't. It's infrastructure, the same way an API contract is infrastructure. Ten disciplined minutes at the end of a shift routinely buy back a nine-hour round trip. I don't know another investment on a delivery team with that exchange rate.

Rotate the painful hour or lose the site that eats it

Every distributed team has one meeting that hurts. Somebody's 6 a.m., somebody's 9 p.m. On most teams the same site eats it every week, usually the one furthest from headquarters.

Watch what happens over a quarter. First the cameras go off. Then the questions stop. Then the far site quits pushing back in refinement and just builds whatever the ticket says. Congratulations. You no longer have three delivery teams. You have one team and two very expensive ticket factories.

People rarely quit the meeting. They quit the version of themselves that participates.

Rotation fixes it, and rotation isn't politeness. It's how you keep a site. If the review lands at 9 p.m. for Bangalore this month, it lands at 9 p.m. for Toronto next month. The hour still hurts. The difference is that everyone can see the pain is shared, and fairness you can see on a calendar buys more goodwill than any culture deck.

Give every decision a latency budget

Back to the nine-hour question. The real failure wasn't the nine hours. It's that the question needed Toronto at all.

Distributed leadership is mostly latency management, so budget latency the way you budget money. Every recurring type of decision goes into one of two piles:

• Can wait a cycle. Most can. Batch these into the handoff note and answer them in writing on the normal rhythm. No meeting, no ruined evening.

• Can't wait. These stall work mid-shift. For these, waiting for the joint call is malpractice. The authority has to already be in the room when the blocker hits.

The second pile is what pre-delegation is for: a named person in each zone with real authority and a written boundary. "Anything that doesn't change the API contract or add spend, Warsaw decides. Post the call and the reasoning in the thread. We review it in overlap, we don't re-litigate it." Notice what that boundary does. It doesn't hand out trust as a vibe. It hands out a decision surface with edges, which is why people actually use it.

The same blocker, hit at ten in the morning, now runs two very different races. Down the wait-for-the-meeting path it collects a night, a workday, and a calendar slot, and resolves 26 hours later. Down the pre-delegated path a named decider posts the call after lunch and the work never really stops. Speed in a distributed team was never about how fast people work. It's about how rarely work waits.

Why interviewers keep poking at this

Distributed delivery stopped being exotic years ago, which is why "tell me about leading a team across time zones" is now a standard probe in senior Scrum Master and delivery interviews. It isn't small talk. It's a judgment test wearing a logistics costume.

The weak answer says "we had daily syncs and really good communication." The interviewer hears: this person scheduled meetings at bad hours and hoped.

The strong answer names mechanics. What you protected the overlap for. What your handoff note forced into writing. Which decisions you pre-delegated, with what boundary, and how you kept the far site loud in reviews. You're describing a system you designed, not a hardship you survived. That's the gap between "I attended a global team" and "I led one," and interviewers hear it inside a minute.

If you're leading a split team right now, that answer is sitting in your calendar waiting to be built. Start at the seams this week. Rewrite one handoff note until the next zone can act on it without asking a single question. Pull status out of your next overlap and put a decision in its place. The sun part runs itself. The handoffs are where the team needs a leader.