Working across time zones with an Indian team

The situation

A small product team in London has a web app in production and a backlog that keeps growing. They have worked with an offshore team before. It went badly: questions sat unanswered for days, work arrived that missed the point, and every call was spent working out what had happened since the last one. They are willing to try again, with a better routine.

Most of what went wrong there comes down to how the time difference was handled. A steady rhythm fixes most of it for a UK or US team working with a delivery team in India, and review and acceptance fit around it.

Know the hours

India Standard Time is UTC+5:30 all year. India does not change its clocks, so the gap moves when yours do.

• UK: India is 4.5 hours ahead during British Summer Time and 5.5 hours ahead in winter.
• US East Coast: India is 9.5 hours ahead during daylight saving time and 10.5 hours ahead in winter.
• US West Coast: the gap is 12.5 or 13.5 hours, so live overlap is very small.

The UK and the US change their clocks on different weekends, so for a few weeks each spring and autumn the gap is an hour off what you expect. Put both time zones in every meeting invite and let the calendar do the arithmetic.

Overlap with the UK

A team in India working a normal day overlaps with a London morning. In summer, 9:30 in London is 14:00 in India, which leaves a comfortable window of two to three hours. This is the easiest pairing, and most questions can be settled the same day.

Overlap with the US East Coast

Here the overlap is narrow. An early morning call in New York, around 8:00 or 8:30, lands in the Indian evening. That works for a short call two or three times a week. It is a poor fit for daily long meetings, so the written side of the routine carries more weight.

Write things down

The time difference punishes vague messages. A question asked at the end of your day is answered while you sleep, and if the answer is "which screen do you mean?", a full day is gone. Good written habits remove most of that.

Daily written updates

Ask for a short written update at the end of each Indian working day, posted where everyone can see it. Three headings are enough:

• Done today, with links to the work.
• Planned for tomorrow.
• Questions or blockers, each one specific enough to answer in a sentence.

Your side reads it first thing in the morning and answers the questions before the Indian team starts its next day. In practice that means a London team clears questions by early afternoon, and a US team clears them before the end of its own day.

Writing a good question

A good question names the screen, the ticket, what was expected and what happened, with a screenshot. It offers a default: "If we hear nothing, we will use the existing date format." That one line lets work continue overnight.

Written decisions

Agree that every decision that changes scope, behaviour or priority is written down in one place, with the date and the person who made it. A call can settle something quickly, but someone posts the outcome in writing straight after. When there is a disagreement weeks later, the decision log is the reference, and nobody has to rely on memory of a call held at an awkward hour.

Sync calls

Keep calls few, short and planned. A pattern that suits most teams:

• A weekly planning call, inside the overlap window, to agree the next week's work and any changes.
• One or two short check ins during the week for questions that are faster said than typed.
• A review call at the end of each increment, where the team shows the work running.

Send an agenda before each call and notes after it. If a call is cancelled, the written update still goes out.

On 2good terms, regular reporting is part of the work: progress updates, sync calls, and a report of hours and deliverables against the agreed scope. You can see what has been done, what it took, and what is left.

Review cadence and increments

Work is built in increments, each with its own part of the signed specification. The time difference can help here. The team can finish an increment at the end of its week and hand it over with written notes, and your reviewers can test it during their own working day.

Make the handover note do the work a call would do:

• What is in this increment, line by line against the specification.
• Where to test it, with test accounts and sample data.
• Anything known to be incomplete or out of scope.
• What changed since the last increment.

Your reviewers log every issue in writing, with steps to reproduce, what they expected and what happened. The team reads those notes at the start of its day and begins on fixes while you are offline. A good rhythm often has fixes ready to retest by the time you next sit down.

Acceptance across time zones

Acceptance works the same way wherever the team sits. You test the increment against the signed specification, accept it if it meets it, and record that in writing. If it falls short, you say which lines fail, the team puts them right and you test again. You pay after you accept. The review window and payment timing are set out in your specification or agreement. See pay after acceptance for how it fits together.

Two habits make acceptance smoother across time zones. First, name one person on your side who signs off, so the team knows whose word is final. Second, write acceptance down, even when it was agreed on a call.

Indian public holidays

India has three national holidays: Republic Day on 26 January, Independence Day on 15 August and Gandhi Jayanti on 2 October. Many other holidays, such as Diwali, Holi and Eid, follow the lunar calendar and move each year, and some vary by state. In Gujarat, where our team is based, Uttarayan in January and the Navratri season in autumn are important.

Ask the team for its holiday calendar at the start of the engagement and put it next to your own. Your bank holidays, Thanksgiving and the Christmas period will also affect review. Plan increment handovers so that neither side hands over work the day before a long break.

A short checklist

• Both time zones in every invite, with the clock change weeks noted.
• A daily written update with done, next and questions.
• Questions written with a default answer.
• One decision log, updated after every call.
• A weekly planning call and an end of increment review.
• Handover notes against the specification for every increment.
• One named person who signs off acceptance, in writing.
• Both holiday calendars shared at the start.

Trying it first

If you have been let down before, start small. Try us on one piece of work alongside your existing team and run this routine for one increment.