Distributed engineering gets blamed on time zones. Time zones are the visible constraint and rarely the binding one — plenty of co-located teams deliver badly, and plenty of teams eight hours apart deliver well.
What actually separates them is how quickly a decision can be made and how much context is written down.
Decision latency is the real cost
An engineer hits an ambiguity. In an office they turn around and ask, and it costs thirty seconds. Distributed, the person who can answer is asleep, and the question waits until tomorrow's overlap — or the engineer guesses.
Neither outcome is a time-zone problem. Both are authority problems.
The fix is not more meetings. It is pushing decision rights down to the team: a technical lead on the offshore side who can settle architectural questions without escalating, clear boundaries on what genuinely needs a client decision, and a default of "make the call and document it" for anything reversible.
Teams that escalate every ambiguity are not being careful. They are being slow in a way that compounds twice a week.
The overlap window, committed rather than promised
"We're flexible on hours" sounds accommodating and produces the worst outcome — nobody knows when the other side is available, so everything waits for a scheduled meeting.
What works is a fixed window, three to four hours, treated as protected time. The second half of the Indian working day reaches UK and Gulf mornings comfortably and US East Coast mornings at the edge.
Inside it: standups, reviews, decisions, anything needing two people. Outside it: deep work, uninterrupted, on both sides.
For US West Coast the honest answer is to shift part of the team rather than asking everyone to stay late. A rota built on goodwill degrades in about a quarter, and the people who leave first are the ones you least want to lose.
Context that lives in one hemisphere
The subtle failure. A decision gets made in a conversation, everyone in that room understands the reasoning, and it is never written anywhere. Six weeks later the other half of the team implements something inconsistent with it, and the response is that they should have known.
Three practices, in order of value:
- Decisions written down with their reasoning, including the alternatives rejected. Short is fine. The reasoning is the part that matters, because it is what lets someone else apply the decision to a case it did not anticipate.
- Asynchronous by default for anything that can be. If a decision only exists in a meeting, half the team is structurally disadvantaged.
- Recordings and notes for the meetings that must be synchronous, so absence is not exclusion.
What to measure
Not hours or activity. Three numbers that actually diagnose:
- Time from question to answer. If the median is over a day, decision authority is in the wrong place.
- Cycle time from start to production, which surfaces handoff friction that standups hide.
- Blocked time. How long work sits waiting on someone else. This is where distributed teams lose most, and it is almost never tracked.
The first three months
Onboarding is where distributed engagements are usually won or lost, and it is worth over-investing.
Someone from the offshore side on site early, if it is at all possible — a fortnight of co-location buys months of context and, more importantly, relationships that make asynchronous communication work later. People who have met each other write differently.
Then a measured ramp: a first meaningful merge inside the first fortnight, on something real. A team whose first month is reading documentation has spent its own value.
The thing that fixes most of it
Give the distributed team ownership of something end to end — a module, a service, a domain — rather than tasks from someone else's board.
Ownership makes most of the coordination unnecessary, because the decisions that were being escalated are now internal to a team that has the context to make them. Task-based distribution maximises the number of handoffs, which is precisely the thing distance makes expensive.