A distributed team delivers when three things hold: the people in the team can decide without waiting for a manager in another time zone, decisions are written down with their reasons, and a fixed daily window exists for the conversations that need two people live. Time zones set the size of that window. They are rarely the reason a team is slow.
Decision latency is the main cost
An engineer meets an ambiguity. In one office they turn and ask, and it takes a minute. Across time zones, whoever knows the answer is asleep. The question waits a day, or the engineer guesses.
Neither result comes from the clock. Both come from where decision rights sit. Three changes help:
- Name a technical lead inside the distributed team who can settle design questions without escalating.
- List what needs a client decision, such as budget, scope and anything that touches a contract. Everything else is the team's call.
- Default to "decide and write it down" for any choice that can be reversed.
A team that escalates every doubt looks careful. In fact it loses a day each time, and it does this several times a week.
How much overlap you get
Overlap is the shared working time between the two sides. The table uses two assumptions: the Indian team works 10:00 to 19:00 IST, and the client's office works 09:00 to 18:00 local time. India is on UTC+05:30 all year and does not use daylight saving time. Source: Time in India.
| Client location | Their 09:00 in India | Shared hours, winter | Shared hours, summer |
|---|---|---|---|
| UK | 14:30 (GMT) or 13:30 (BST) | 4.5 | 5.5 |
| Gulf (UTC+04:00) | 10:30 | 8.5 | 8.5 |
| US East | 19:30 (EST) or 18:30 (EDT) | None | Half an hour |
| US West | 22:30 (PST) or 21:30 (PDT) | None | None |
The table gives the arithmetic for a standard day, not a promise from any supplier. Two things follow.
First, the UK and the Gulf have enough overlap for daily live work without a change of hours. Second, the US needs a shifted shift on the Indian side. A late start for part of the team, with a stated end time, gives the US East coast a few hours. For the US West coast, assign a smaller group on a rota with a compensating arrangement. A rota that rests on goodwill wears out within a few months, and the first to quit are the people you wanted to keep.
Commit to a window
"We are flexible on hours" sounds helpful and creates confusion. Neither side can tell when the other is free, so every question waits for a booked call.
Fix a window and protect it. Inside it: stand-up, reviews, decisions and anything that needs two people. Outside it: work that needs concentration, on both sides. Choose the window from the table, then publish it in the working agreement.
Context that stays in one half of the team
A decision made in a call is clear to everyone on the call. If nobody records it, the people who were absent build something that conflicts with it six weeks later, and are told they should have known.
Write each significant decision in a short note where both sides will see it:
| Field | Content |
|---|---|
| Decision | One sentence |
| Date and who decided | Names |
| Reason | Why this and not the alternatives |
| Alternatives rejected | One line each |
| Review date | When to revisit it |
The reason is the valuable part. It lets a newcomer apply the decision to a situation nobody foresaw.
Two supporting habits keep the record useful. Work asynchronously by default, so a decision does not live only in a meeting. Share notes or a recording of any call that had to be live, so absence does not mean exclusion.
Three measures that diagnose the team
Do not measure hours or activity. These three show where the work stalls:
- Wait between a question and its answer. If the typical wait exceeds a working day, decision rights sit in the wrong place.
- Days from starting a task to releasing it. This exposes handoff friction that stand-ups hide.
- Blocked time. The hours work waits on someone else. Blocked time is a common place for distributed teams to lose days, and it is rarely tracked.
The first weeks
Onboarding decides much of the outcome, so spend on it.
- Meet in person early. A short period together, even a week, builds working relationships that make written communication easier afterwards. People who have met write to each other differently.
- Ship something real in the first fortnight. A first merge on a live task teaches more about the codebase and the release process than a month of reading.
- Write the working agreement: the window, the channels, who decides what, response times for questions, and how to escalate.
Give the team a whole piece
Task-by-task assignment from someone else's board maximises handoffs, and distance makes handoffs expensive. Give the distributed team an end-to-end area instead: a module, a service or a domain. Decisions that used to travel up and down become internal to a team with the context to make them.
This also makes a team easier to measure. You can ask one team what shipped from one area and why it was late. For how the engagement models differ on ownership, see ODC, staff augmentation, BOT and GCC compared, and for the cost of the lightest model, see what staff augmentation costs to manage.
Questions buyers ask
How many hours of overlap does a team need?
Enough for stand-up, reviews and decisions: a few hours is common. Fix them as a window and keep the rest of the day free of meetings.
Should the client visit the offshore team, or the reverse?
Either works. What matters is that the people who write to each other have met in the first weeks.
Which tools matter most?
A shared repository, a tracker both sides read, and one place for written decisions. Fancy tools add less than the habit of writing.
How do we handle a team on US West hours?
Assign a small group, set a fixed end time, agree compensation, and use written decisions for everything else. See choosing a software development company in India for questions to ask a supplier about working hours.
Where Brihat Infotech fits
Brihat Infotech's dedicated development pods work in your repositories, CI and ticketing, with a first meaningful merge in the first fortnight. For the whole subject, see the offshore engineering models guide.