Managing a Development Team Five or More Hours Away

Your India-based development team is asleep when your UK leadership is deciding what matters this week. By the time they come online, the decision has already half-formed in a Slack thread that no one person owns. Three days later, someone asks why the team built the wrong thing, and the honest answer is that nobody can point to where it was actually decided.

That is the real problem. It is not distance. It is that nothing was written down as a decision, so the gap in hours becomes a gap in accountability. The fix is not more communication. It is less communication, structured better: a short daily overlap window for the decisions that genuinely need two people live on a call, and a decision log for everything else.

This matters more as the gap widens. A UK team and an India team can still find three overlap hours most days. A US West Coast team and an India team often cannot find one. The system has to work whether you have three hours of overlap or none at all, which is why the log, not the call, has to be the backbone.

How many overlap hours do you actually need with an India-based team?

You need roughly three hours, not a full overlapping working day. Those three hours are for blockers, approvals and priority calls, the things that genuinely cannot be resolved by one person writing a clear note. Everything else, status, progress, routine questions, does not need two people awake at the same time.

The UK and India sit 5 hours and 30 minutes apart for most of the year, and 4 hours and 30 minutes apart during British Summer Time, because India does not observe daylight saving. That difference matters more than people expect when you are trying to fix a meeting time that holds for twelve months.

UK time (London)	IST (India)	Season
09:00	14:30	GMT, late October to late March
09:00	13:30	BST, late March to late October

If the India team works 9.30am to 6.30pm IST, and the UK team works 9am to 5.30pm UK time, the live overlap sits roughly between 9am and 1pm UK time, India's afternoon. That is the window you protect. Nothing else needs to be synchronous.

What if the gap is larger, like US to India?

The principle holds even when the overlap shrinks to nothing: the log carries the work the call cannot. A US East Coast team and an India team are roughly 10.5 hours apart in winter and 9.5 hours apart in summer, which leaves perhaps one workable hour, usually early morning US time against India's evening. A US West Coast team and an India team are 13.5 hours apart in winter and 12.5 hours apart in summer, which leaves effectively no shared working hours at all.

Pairing	Approximate gap	Realistic live overlap
UK and India	4.5 to 5.5 hours	3 to 4 hours daily
US East Coast and India	9.5 to 10.5 hours	0 to 1 hour, early morning US
US West Coast and India	12.5 to 13.5 hours	Near zero, occasional scheduled call

When live overlap disappears, the decision log stops being a supplement to the call and becomes the only mechanism that exists. A US West Coast company working with an India-based partner should expect to make almost every decision asynchronously, with a scheduled call once or twice a week for anything the log genuinely cannot carry, rather than daily, because a daily call at either end of a 13-hour gap means someone is permanently working outside their normal hours.

What should actually happen during the overlap window?

The overlap window is for decisions, not updates. If a status update needs a live call, the reporting is broken, not the timezone.

Use the window for three things only: unblocking something that has stalled, approving something that changes scope or cost, and resolving a disagreement about priority. A good test before anyone joins the call: could this have been answered by a well-written note in the decision log? If yes, it should have been.

This is also where how to evaluate an India-based transformation partner becomes relevant before you sign anything. A partner who cannot describe, specifically, what happens in their overlap hours is telling you they run on ad hoc calls, not a system.

What is a decision log, and why isn't the chat thread enough?

A decision log is a dated, single-line record of what was decided, who decided it, and what happens if nobody decides by a set time. A chat thread is a record of conversation. The difference matters the moment someone needs to check, three weeks later, why a feature was built a certain way.

	Chat thread	Decision log
Searchable by decision	No	Yes
Shows who had authority	No	Yes
Has a stated deadline	Rarely	Always
Survives staff turnover	No	Yes

Each entry needs five things: the decision stated as a question, who has the authority to answer it, the options that were considered and why one was rejected, what was decided, and what happens if the deadline passes with no answer. If the answer needs a phone call, it's not a system.

The log does not need special software to start. A shared spreadsheet or a pinned document works for the first few months, provided every entry has all five fields and nobody skips the log because a call felt faster. The format matters less than the discipline of using it before reaching for the phone.

What happens when a decision can't wait for the next overlap window?

It escalates to a named person with standing authority to decide alone, and that decision still gets logged afterwards.

Someone on your side, usually the product owner or the person commissioning the work, needs to be the named decision-maker for anything that cannot wait twelve hours. The partner's side needs an equivalent: a lead who can make a technical call without waiting for the next overlap window. Write both names into the engagement from day one. Without a named person, urgency becomes an excuse to skip the log entirely, and you are back to reconstructing decisions from memory.

In practice, most urgent decisions are not actually urgent, they are decisions someone postponed until they became urgent. A named decision-maker on each side makes that pattern visible, because now there is one person who has to explain why something sat unlogged for three days before it became a fire.

What does a working week actually look like with a five-hour gap?

It looks like a daily handoff, not a daily meeting. Each side reads the log before starting, works through the day, and leaves a clear entry for the other side to pick up.

A Tuesday, for example: the UK team starts at 9am, reads what India logged the previous evening, and has three hours of live overlap to approve a scope change raised overnight. India's afternoon continues after the overlap closes, working against what was approved, and the day ends with a fresh log entry stating what was built, what is blocked, and what needs a UK decision by the following morning. No one is waiting on a call that might not happen. No one is guessing what was agreed.

This rhythm only works if the cost model behind it is clear too. If you are still working out whether a fixed-scope project or a phased engagement suits the work, what digital transformation actually costs by engagement model is worth reading before you agree a structure, because the engagement model determines how often decisions need making in the first place.

How do you know the async system is failing?

The clearest sign is rework: the same decision gets made twice, differently, because the first one was never logged properly. A second sign is that every blocker becomes an urgent call, which means the log isn't trusted enough to be used. A third is that only one person on either side can explain why something was built the way it was, which means the decision never left someone's head.

None of these are solved by adding more meetings. They are solved by making the log the thing people actually check first, before they message anyone. If a new blocker appears and the first instinct on either side is still to open a chat window rather than the log, the system has not actually been adopted yet, regardless of what the engagement documentation says.

What to do next

If you are choosing a partner, ask to see what their decision log actually looks like on a live project, not a description of their process. If you already have a team and the gap feels chaotic, start with one rule this week: no decision is final until it is written in the log with a name and a date attached. We understand how your business actually works first, then we design the system around it. For the mechanics of setting one up properly, see our custom software development approach, and for the broader question of choosing and working with a transformation partner, the working with a partner hub covers the ground this post builds on.