Managing a remote team in India from the UK

India Standard Time doesn’t change. The UK moves its clocks on the last Sunday in March and the last Sunday in October, so your overlap with an Indian team changes twice a year, and the winter overlap is an hour shorter. In 2027 those dates are 28 March and 31 October.

Here is the overlap with a UK day of 09:00–17:30, for three different start times in India. All three assume a nine-hour day in India, so the last column shows the time that team finishes.

Look at the last column before you ask for more overlap. A later start in India means a later finish, and that affects commuting, family life and who stays. It’s a real cost, so agree the hours openly and don’t quietly expect them. We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. Our office hours are Mon–Fri 09:00–18:00 IST; meetings outside hours by prior booking.

The overlap is the only time you can have a conversation, so protect it. In a UK morning, that’s roughly from when you sit down until lunchtime. A workable rhythm looks like this.

• First 15 minutes of your day: a short call, by which time the team has done several hours’ work. Yesterday’s questions get answered first.
• Next couple of hours: pairing, design decisions and code review with discussion. Keep this free of your own internal meetings if you can.
• Your afternoon: the team has usually finished. Write tickets, answer questions in writing and review pull requests, so that everything is waiting for them in the morning.

Used this way, the time difference gives you a day that runs longer than a UK-only one. Used badly, a question asked at 14:00 UK time waits until the next morning, and a day is gone. Most of what follows exists to stop that happening.

The test for a ticket is whether a developer could start it at 09:00 in India, with you asleep, and still be working on the right thing by the time you wake up. For that, every ticket needs:

• what should be true when it’s finished, in terms a tester could check
• why it matters, so the developer can make sensible small decisions alone
• what’s out of scope
• who decides if it turns out to be harder than it looked, and what to do meanwhile

Give developers a standing instruction for when they’re blocked: make the most reasonable assumption, write it on the ticket, carry on, and flag it. You lose much less by reversing the occasional wrong assumption than by losing a day every time.

Time tracking tells you little about whether software is getting built. These tell you more, and none of them depends on being awake at the same time.

• Small, frequent pull requests. A two-week silence followed by a huge change is the warning sign to watch for.
• Automated tests on every change. They let you accept work without being online when it lands, and they make sure knowledge of how things should behave lives in the repository.
• A staging environment you can open at any time. Seeing the feature beats reading about it.
• A regular demo of working software. Pick a slot within the overlap and keep it.

• Holiday calendars don’t match. India’s public holidays differ from the UK’s and vary by state. Ask for the calendar at the start of the year, and plan releases around both.
• “Yes” may not mean “understood”. Anywhere, people can be reluctant to tell a client that a plan won’t work. Ask “what could go wrong with this?” rather than “is this okay?”, and thank whoever raises a problem early. Do this until raising problems becomes normal.
• Treat them as your team. Include them in the product context and the customer feedback, not just the tickets. People make better decisions when they know what the product is for.
• Access and data. Give the least access that lets the work happen, and remove it when someone leaves. If personal data is involved, the ICO’s guide to international transfers explicitly uses a UK business giving an Indian service provider access to personal information as an example of a restricted transfer.
• Visit if you can. A few days in the same room early on can make later calls much easier.

1. Week 1: access, the local setup, and one small real change released. That first release tests the whole path, from ticket to production.
2. Week 2: agree how tickets are written, how code gets reviewed and who decides what. Write it down, briefly.
3. Weeks 3–4: give them something that needs judgement, then look at where they got stuck. What they had to ask you shows what your documentation is missing.
4. End of the month: ask them what’s slowing them down, and fix one thing on the list.

We ran a team of 14–15 developers in Kerala for a Dubai technology company for about three years, handling recruitment, employment, workspace and line management. Before you start, check what the rates look like and what the contract should cover.