Delivery & operations
Running distributed delivery teams across time zones
Three cities on a standard 9-to-5 give you 3 hours of overlap in one pair and 1 in another. Two small schedule shifts turn that into 4 and 2 — and the rest is written handover.
·5 min read
The reason distributed agency teams feel slow isn't the time difference. It's that a question which takes ninety seconds to answer in a room takes 24 hours when it has to wait for someone's morning — and a project that hits three of those in a week has lost most of a week.
The fix is arithmetic first, then habits. Work out exactly how much overlap you have, buy a little more of it cheaply, and then design the work so that most questions never need the overlap in the first place.
Calculate your actual overlap
Put everyone's working day in UTC and look at the intersections. A hypothetical team with people in Lisbon (UTC+0), New York (UTC-5) and Singapore (UTC+8), all working a standard local day:
| Location | Local hours | In UTC |
|---|---|---|
| Lisbon | 09:00–17:00 | 09:00–17:00 |
| New York | 09:00–17:00 | 14:00–22:00 |
| Singapore | 09:00–18:00 | 01:00–10:00 |
Which gives:
| Pair | Overlap | Hours |
|---|---|---|
| Lisbon ↔ New York | 14:00–17:00 UTC | 3 |
| Lisbon ↔ Singapore | 09:00–10:00 UTC | 1 |
| New York ↔ Singapore | none | 0 |
| All three | none | 0 |
That's the real constraint, and it's worth writing down because most agencies have never made it explicit. There is no hour of the week when all three people are awake at work. Any process that assumes a full-team meeting is impossible without someone giving up an evening.
Buy overlap with small shifts
The cheapest intervention is moving start times by an hour, which people will usually accept if it's their choice and it's permanent rather than ad hoc.
Move New York to 08:00–16:00 local (13:00–21:00 UTC) and Singapore to 10:00–19:00 local (02:00–11:00 UTC):
| Pair | Before | After |
|---|---|---|
| Lisbon ↔ New York | 3 hours | 4 hours |
| Lisbon ↔ Singapore | 1 hour | 2 hours |
Lisbon doesn't move at all, and one hour of change in each of two cities produces a third more overlap on one pair and double on the other. New York and Singapore still never meet, and no schedule shift short of something unreasonable will fix that — so stop trying and design around it.
Nominate a hub time zone. Whoever sits in the middle becomes the routing point. Not a manager necessarily — just the place where information passes through. Everyone else optimises against the hub rather than against each other.
Protect the overlap ruthlessly
The overlap window is the most valuable capacity you have, and it gets eaten by exactly the things that don't need it. Internal updates, admin, reading a document together, watching someone share a screen while they explain something they could have written.
Two rules:
- The overlap is for things that need two brains at once. Decisions, disagreements, reviewing something ambiguous, anything with emotional weight. Everything else goes in writing.
- Nothing that can be a document becomes a meeting in that window. If someone can read it and respond in their own hours, they should.
An agency with a four-hour overlap that spends three of them on status updates has a one-hour overlap.
Written handover is the actual skill
The teams that work well across zones aren't the ones with the best video setup. They're the ones where people write clearly enough that the next person can act without asking a question.
A handover note at the end of each person's day, in the project channel, two minutes to write:
[NAME] — end of day — [DATE]
DID: [What moved. One line.]
NEXT: [What I'll pick up tomorrow.]
BLOCKED ON: [What I need, from whom, and by when.
If nothing: "nothing".]
DECIDED: [Anything I decided on my own that others should know.]
FYI: [Anything the client said or did that matters.]
The BLOCKED ON line is the one that pays for the whole practice. A blocker posted at the end of the Singapore day is answered during the Lisbon morning and cleared before Singapore wakes up. The same blocker raised in a call that never happens costs a full day, then two.
Make questions answerable without you
Every question that requires a specific person is a question that waits for a time zone. So reduce the number of questions that require a specific person.
Write briefs that survive absence. If a brief only works when its author is online to explain it, it's a brief for a co-located team.
Keep a decision log per project. Newest first, one line each, including the options that were rejected. Most cross-zone questions are actually "why did we do it this way?" and a log answers them at 3am.
Default to over-communicating in writing. In a shared office, context leaks through proximity. Distributed, it doesn't leak at all — it has to be pushed, and someone has to do the pushing on purpose.
Give people real authority within a defined boundary. If every decision above trivial has to wait for approval from another continent, you've built a system where the time difference is a tax on everything. Define what each person can decide alone and let them.
Client coverage is a separate question
There's a real benefit here that agencies rarely sell: a client in New York can send feedback at 5pm and have it actioned before their next morning, because Singapore has been working on it. That's genuinely valuable and worth being explicit about in a proposal.
But it only works if the client's questions can be answered by whoever is awake, which brings you back to written context. If the Singapore team can't answer the New York client's question without waking someone in Lisbon, the client experiences a distributed agency as slower than a local one, not faster.
Set explicit response expectations with clients — "we reply within one working day, and here are our working days" — rather than letting them discover the pattern by being disappointed.
The meeting that has to include everyone
There will be one or two a quarter. Accept that someone will be inconvenienced and handle it fairly rather than pretending it away.
Rotate which region takes the awkward slot. Record it, always, with a written summary rather than only a two-hour video nobody will watch. And keep it rare — if you need everyone in a call weekly, the problem is that your written practices are too weak, not that your calendar is.
Do this week
Build the first table above for your own team: everyone's working hours converted to UTC, and the overlap for each pair. It takes fifteen minutes and it's usually smaller than people assume.
Then post it where everyone can see it, and start the end-of-day handover note with one project. The teams that do this stop having the argument about responsiveness, because the constraint is visible to everyone rather than being experienced privately as somebody else being slow.
Keep reading
- Structuring projects so handoffs don't lose contextEvery handoff loses something. The question is whether it loses the decisions. A one-page handoff format and four structural habits that make any project survivable when the person leaves it.
- Agency capacity planning: can you actually take the next project?A team with 35 free hours a week can still be unable to start a project that needs 30. Here's the role-level capacity calculation that tells you yes or no before you sign.
- The weekly operating rhythm that prevents client surprisesMost client blow-ups were visible two weeks earlier and nobody was looking. A 45-minute weekly agenda, with time boxes, that surfaces problems while they're still cheap.