How to Work With an Outsourced Team Across Five Time Zones

Distributed teams work when decisions are written rather than spoken, handoffs are structured, and the overlap window is reserved for things that genuinely need a conversation. Time zones cost money in one specific way: a blocked question that waits a full day for an answer. Almost everything else is manageable.

Why this matters

Most outsourced game development crosses time zones, and most of the friction attributed to distance is actually process.

A team that writes things down and structures handoffs can work across a large gap with little loss. A team that relies on real-time conversation loses a day every time a question arises.

The difference is a handful of habits.

The overlap window, and how to use it

Find the hours where both sides are working and treat them as the scarcest resource on the project.

Three rules.

1. Reserve overlap for decisions and demonstrations. Anything that can be written should not consume it.
2. Never use it for status. Status is the easiest thing to write and the most common way overlap gets wasted.
3. Publish an agenda beforehand. An unplanned overlap call becomes a status meeting by default.

If the overlap is very short, protect it absolutely. If there is no overlap at all, create a small one deliberately: one side shifting an hour, two or three days a week, is usually enough and is a reasonable thing to agree at the start.

An hour of overlap used for decisions is worth more than four hours used for updates.

Async handoffs that actually work

A handoff is the moment one side stops and the other starts, and it is where days are won or lost.

A good handoff contains four things.

• What was completed, with a link to the build or the branch.
• What is in progress, and where exactly it was left.
• What is blocked, with the specific question and everything needed to answer it.
• What you recommend they do next if the blocking question cannot be answered in time.

That fourth item is the one that removes most time zone cost. A blocked question with a proposed default lets the other side proceed rather than wait, and it converts a lost day into a decision to confirm or correct.

Attach a build to every handoff where possible. A running artefact answers more questions than a description.

What to put in writing every day

A short daily written update from each side, at the end of their day.

Keep it to five lines: done, doing, blocked, decisions made, and anything the other side should look at.

Two habits make it work.

Write decisions, not just activity. "We chose the shorter timer because the longer one made the fail state feel unfair" is far more useful than "tuned the timer".

Write the reason. Six weeks later the reason is what prevents the decision being reversed by somebody who was not there. This is the same decision log described in A Weekly Build Review Agenda.

Keep it in one place both sides can search. Decisions scattered across chat threads are effectively lost.

Review cadence across zones

Adapt the review rather than abandoning it.

Distributing the build a day early and collecting written feedback before the call is the single change that makes distributed reviews work. It also improves the feedback, since people write more carefully than they speak.

Reducing dependency on questions

The deeper fix is needing fewer answers.

• Front-load decisions. Resolve as much as possible in discovery, when it is cheap, rather than during the build.
• Write the scope precisely. Ambiguity generates questions, and every question costs a day.
• Empower a decision maker on each side for anything under a defined threshold.
• Keep a defaults document. Naming conventions, art specs, code style, tuning ranges. Anything documented is a question that never gets asked.
• Batch questions. One list at the end of a day is far cheaper than five questions spread across it.

The defaults document is undervalued. Most cross-zone questions are small and repetitive, and writing the answers once removes them permanently.

When time zones genuinely cost you money

Being honest about where the cost is real.

Live incidents. A production problem during your night needs somebody awake and authorised. This requires an explicit on-call arrangement, not goodwill.

Rapid iteration on feel. Tuning that needs a fast back-and-forth is genuinely slower across a large gap. Schedule this kind of work inside the overlap window, or in a short co-located block.

Crunch periods. When decisions need to happen hourly, the gap becomes the constraint. Plan launches and submissions so the critical days fall inside working overlap.

Cultural and language differences around directness. This is not a time zone issue and it shows up in the same conversations. Agree explicitly that raising problems early is expected, because in some working cultures it is not the default.

What we would do

Agree the overlap window, the handoff format, and the decision thresholds in the first week, before any work starts. All three take an hour to settle and they set the pace for the whole engagement.

Require the proposed default on every blocked question. It is the highest-value habit on this list and it takes seconds to write.

Then measure how often work waits. If the same category of question keeps blocking, the answer belongs in the defaults document rather than in another meeting.

The short version

• Reserve the overlap window for decisions and demonstrations, never for status.
• Every handoff needs done, in progress, blocked, and a proposed default.
• The proposed default is what stops a blocked question costing a full day.
• Write decisions with their reasons, in one searchable place.
• Distribute builds early and collect written feedback before any review call.
• Front-load decisions and keep a defaults document to reduce questions entirely.

Add a proposed default to every blocked question in your next handoff. If you want a studio that works this way by default, start a conversation.

Related reading: Working With a Remote Game Studio, A Weekly Build Review Agenda, and How to Give Feedback on Game Builds.