Why Cross-Team Projects Stall Across Timezones

The feature was maybe four days of actual work. It shipped three weeks later.

Nobody dropped the ball. The PM in San Francisco wrote the spec on a Monday. The designer in London picked it up Tuesday her morning, had a question about an edge case, and asked it. The PM answered Tuesday his morning, which was already Tuesday evening for her, so the mockups came Wednesday. The backend engineer in Bangalore started Thursday, found the spec didn't cover what happens when the payment provider times out, and asked. That question crossed a night to reach the PM, and the answer crossed another night coming back. Then QA in Sydney found two bugs, filed them, and waited for Bangalore to wake up and fix them. Each of those exchanges was somebody being perfectly responsive, answering the same day they saw the message. The feature still took most of a month, and if you'd asked any single person on the chain they'd have honestly told you they never sat on anything.

That's the thing about work that passes through several hands. The delay doesn't live in any one person. It lives in the gaps between them, and on a distributed team those gaps are made of nights.

The chain is where the time goes

Most advice about distributed work treats latency as a two-person problem. You and a reviewer. You and the person you're handing off to. And a lot of it is: an open pull request waiting on one reviewer is the classic case, one queue, one round-trip priced in a sleep cycle.

But real work is rarely one handoff. A feature threads through a PM, a designer, one or two engineers, QA, sometimes a security review or a legal sign-off before it ships. Each of those is a person, and each boundary between them is a place the work can wait. When your team sits in one office, those boundaries are close to free. You lean over, you catch someone at lunch, the designer and the engineer hash out the edge case in four minutes at a whiteboard. The chain has five links but none of them cost anything, so you never notice the chain is there.

Spread those five people across four timezones and every link becomes a wall the work has to be thrown over. The chain didn't get longer. It got expensive, one boundary at a time, and now the shape of the chain matters more than the difficulty of the work.

Latency stacks, it doesn't average

Here's the part teams consistently underestimate. When you have one handoff that crosses a night, you feel the one-day cost and you plan around it. When you have five handoffs in a row, each crossing a night, the costs don't average out. They add up, and then they multiply, because a single unanswered question at link three doesn't just delay link three. It stops the whole line behind it.

Think about what actually happened to that feature. The designer's question cost a day. The engineer's edge-case question cost two, because it went out and came back. The QA bugs cost another cross-night round-trip each. None of these was a big delay on its own. Strung together, serially, with a night between each, they turned four days of work into fifteen. The math isn't four days plus some overhead. It's four days of work wrapped in a dozen sleeps, and the sleeps are the project.

This is why "everyone was responsive" and "the project was slow" are both true at the same time, and why the usual fix of asking people to reply faster does almost nothing. You cannot reply faster than the next morning if the question arrives after you've gone to bed. The lever isn't the speed of each reply. It's the number of times the work has to cross a night before it's done.

The person who picks it up can't ask you a question

Once you see it that way, the first fix is obvious, even if it's uncomfortable. Every question that crosses a night costs you a day, so the work is to eliminate the questions before they get asked.

In an office you can write a thin spec and backfill the details in conversation. The designer will find you. The engineer will Slack you and get an answer in a minute. That habit is lethal across timezones, because the person who picks up your work next is doing it while you sleep, and the only thing they have to go on is what you wrote down. If it's ambiguous, they have exactly two options: guess, or stop and wait a full day for you to wake up. Both are bad. The guess might be wrong and surface as rework later. The wait is the delay we just walked through.

So the spec has to answer tomorrow's questions today. When the PM writes the ticket, the job isn't to describe the happy path, it's to think through what the designer and the engineer and QA will each need and to have answered it in advance. What happens when the payment provider times out. What the empty state looks like. Which of these three behaviors is actually required. This is writing things down as the thing that lets the next timezone function, applied at every seam in the chain, and it's also just a good handoff note repeated at each boundary instead of only at the end of a shift. It feels like over-engineering when you write it. It saves a day every time it stops a question from crossing a night.

Stop scattering one project across four hemispheres

The deeper fix is structural, and it's the one most teams never reach for because it feels like it's not their call. But it usually is.

You do not have to build every feature with a chain that happens to span the whole planet. That configuration, PM in California, design in London, backend in Bangalore, QA in Sydney, wasn't chosen. It fell out of wherever people happened to sit, and then a project got routed through all of them because those were the people free that week. The result is a delivery chain where every single link crosses a timezone, which is close to the worst case you can build.

The alternative is to cluster the chain. When you're staffing a project, try to keep the people who'll hand work back and forth inside a band of timezones that actually overlap, so most of the boundaries are cheap and only the occasional one crosses a night. A PM, designer, and engineer within three or four hours of each other can run the tight, iterative middle of a project at nearly office speed, and then hand a finished thing across the wide gap once, deliberately, instead of ping-ponging half-built work across it a dozen times. Some teams formalize this as a pod: a small delivery group deliberately kept in adjacent timezones. You don't need the ceremony. You need to stop assigning the five people on a project as if their locations were free.

Run the steps in parallel, and batch the round-trips

Two smaller moves take the edge off the chains you can't cluster.

The first is to stop running steps in series when they don't have to be. A lot of the chain is falsely sequential. Design and the backend scaffolding often don't actually depend on each other for the first few days, so start them together instead of making the engineer wait for pixel-perfect mocks. The API contract can be agreed up front, in writing, and then both sides build against it in their own hours. Every step you move from serial to parallel is a night you delete from the total.

The second is to batch the exchanges that are left. When QA finds problems, the worst pattern is a slow drip: one bug filed, a night's wait, a fix, another bug filed, another night. That's the same code crossing the ocean five times. Far better to review the whole thing in one deliberate pass and hand back every issue at once, so the fix round-trip happens a single time. It's also why putting a real date and a named clock on each interface beats a vague "when you get to it" that quietly adds another day nobody planned for.

None of this is about working harder or replying faster. The people in that three-week story were already doing both. It's about seeing the chain the work travels through, counting how many times it crosses a night, and then attacking that number directly: by answering questions before they're asked, by keeping the people who trade work most inside a shared band of hours, and by refusing to let a four-day feature get wrapped in two weeks of sleep just because nobody looked at the shape of the handoff. Do that and the timezone gap stops being a tax on every project and goes back to being what it should be, an advantage you spend on purpose.

Keep the Handoffs From Crossing the Wrong Night

Most of the cost in a cross-team project is the arithmetic nobody does out loud: when your reply actually lands for the person waiting, and whether the deadline you set falls on their Tuesday or their Saturday. Timely converts every time mentioned in Slack to each person's own clock automatically, so when you write "I'll have the spec to you by 2pm" or "let's sync at 9," everyone down the chain sees exactly when that is for them. Less guessing about whose morning it is, fewer questions bouncing across nights, more of your project spent moving instead of waiting.

Add Timely to Slack — Free · See how it works