In short
- The time difference between the United States and India is an advantage when handoffs are designed, not improvised.
- Use the short daily overlap for decisions. Everything else moves in writing.
- One backlog, one definition of done and one on-call rota make two locations work as one team.
- Treat the handoff note as a product, because the next shift depends on it.
When the working day ends at our US hub, it’s the middle of the night in India, and the India team starts its morning while the US team sleeps. The two hubs are ten and a half hours apart in summer and eleven and a half in winter, because US Central Time changes its clocks and India doesn’t.
That gap can work two ways. Badly run, it means slow answers, late-night calls and work that waits a day for a decision. Well run, it means a platform that moves forward around the clock, with problems handled while the other hub sleeps.
These are the habits we’ve found make the difference.
Use the overlap for decisions
The two hubs share a short window each day: early morning in the US is evening in India. At 8:00 a.m. US Central Time it’s 6:30 p.m. in India in summer, and 7:30 p.m. in winter.
That window is precious, so protect it:
- Use it for decisions and unblocking, not status updates. Status belongs in writing.
- Keep it short and regular. The same time every day is easier to plan around than ad hoc calls.
- Share the inconvenience. If one hub always takes the late or early call, rotate it. Fairness keeps people for the long term.
- Record what was decided, in the same place every time, so people who couldn’t join know by their morning.
Make the handoff a product
At the end of each day, one hub hands the work to the other. A good handoff note means the next shift starts working, not asking questions.
| Section | What goes in it |
|---|---|
| What changed | Work finished, deployed or merged today, with links |
| In progress | What’s half done, where it stands and the next step |
| Blocked | What’s stuck, why, and who can unblock it |
| Decisions needed | Questions only the other hub can answer, with a deadline |
| Watch list | Alerts, risks or fragile areas to keep an eye on |
Keep the format the same every day, write it where the whole team can see it and make writing it part of the definition of done for the day.
One team, not two
The biggest risk in a two-hub setup is drifting into two teams: one that decides and one that delivers. To stay one team:
- Keep one backlog and one set of priorities, owned jointly.
- Share one definition of done, one set of tools and one way of reviewing code.
- Split work by feature, not by location, so both locations build, test and release.
- Pair across hubs when the overlap allows, especially on new or tricky work.
- Meet in person when you can. A visit early on builds the trust that makes the written handoffs work.
Running a platform around the clock
For platforms that can’t stop, two time zones make follow-the-sun support possible: each hub covers its own daytime, so nobody is woken up for routine issues.
That works when:
- the on-call rota covers both hubs, with a clear handover between them;
- runbooks are written down and kept current, so whoever is on call can act without waiting for the original author;
- alerts go to whoever is awake, not to whoever built the service;
- incidents are handed over like any other work, with what’s known, what’s been tried and what’s next; and
- reviews after incidents are blameless and shared across both hubs, so both learn from every one.
What the client sees
For the enterprise, a well-run two-hub team should feel simple. Our US team, the Client & Leadership Hub, works in North American hours and is the day-to-day point of contact. The engineering teams in India, our Engineering & Delivery Hub, carry the work forward overnight. Each morning starts with a clear summary of what moved, what’s next and what needs a decision.
Habits that make it work
- Write first, meet second.
- Keep decisions in one place everyone can find.
- Make every handoff note complete enough to act on without a call.
- Rotate the inconvenient hours.
- Measure how long work waits between hubs, and work to shorten it.
How ManyaIT works
ManyaIT runs this way every day, with client leadership in the United States and engineering teams in India working as one team for each enterprise. If you’re planning a platform that runs across time zones, tell us the outcome you’re targeting and we’ll show you how we’d run it.
