Managing an offshore development team across time zones

Managing an offshore development team across time zones comes down to a few habits. Protect a block of shared working hours and use it for decisions. Put everything else in writing, in tools both sides can see. End every day with a handoff note, so nobody starts their morning waiting for an answer.

We work with clients worldwide from Rajkot, India, so the time difference is part of every delivery plan we make. India is 4.5 to 5.5 hours ahead of London and 9.5 to 10.5 hours ahead of New York, depending on the time of year. The advice below comes from the delivery side of that gap.

What the time difference really costs

The gap itself is rarely the problem. The problem is a decision that waits. With little shared time, a question asked at the wrong moment can cost a full working day, and a few of those a week will sink a sprint.

A nearshore team, a few hours from you, shares most of the day, so small questions get answered quickly. An offshore team shares less of it. Both can work well. The offshore team just needs stronger written habits and a clear rule about who decides what.

Protect the overlap hours and spend them on decisions

Every Coretus team keeps at least four hours of overlap with the client's working day. That is enough time for the conversations that need to happen live, as long as it isn't filled with status meetings. Use it for:

• Unblocking work. Questions about product behaviour, priorities or access that would otherwise stall a developer.
• Planning and reviews. Sprint planning, demos and design reviews, where back-and-forth matters.
• Working through hard problems together. A tricky bug or integration is often quicker to solve on a call than in a long thread.
• A short stand-up. Focused on blockers and on decisions the team needs from you.

Put the overlap in both calendars as a standing block. Then check it again whenever the clocks change. India does not use daylight saving, and the US and the UK change their clocks on different dates. A meeting that suited everyone in February can be an hour off in March.

Write updates people will actually read

Anything that doesn't need a live conversation should go in writing. A written update can be read at the start of someone's own day, and it leaves a record. A daily update from the team can follow the same four headings every time:

• Decisions needed: a clear question, the options and the date the answer is needed by.
• Blocked: anything waiting on someone, with the name of the person it is waiting on.
• Done: what was finished, with links to the tickets or pull requests.
• Next: what each person is picking up.

Decisions and blockers go first, because they are the items that cost a day if someone misses them. Keep the whole update short enough to read in a couple of minutes. For the weekly picture, see our post on software project status reporting.

End each day with a handoff note

The handoff note is the most useful habit a team in another time zone can have. Before they sign off, the team writes down what the other side needs to know before its day starts:

1. Questions that need an answer before the team starts again.
2. Anything waiting for your review or testing, and by when.
3. What changed today and where to see it: a staging link, a build or a pull request.
4. Risks spotted today, even if they aren't confirmed yet.

We report risks as quickly as wins, and the handoff note is where that happens day to day. A risk raised on Tuesday evening gives you a full working day to react. The same risk raised at Friday's demo gives you none.

Handoffs work in both directions. If your product owner reviews a build in their afternoon, a few lines of feedback in the shared channel let the team act on it first thing next morning.

Decide in advance who decides

Time zones punish unclear authority. If only one person can approve a change and that person is offline, the team either waits or guesses. Agree these points before the first sprint:

• One product owner on your side who can answer product questions during the overlap.
• A named deputy for the days that person is away.
• Which decisions the team can make on its own, such as technical choices that don't change behaviour or cost, and which need your sign-off.
• One shared place where decisions are written down, with the date and the person who made the call.

A one-line decision log saves a lot of repeated conversations, especially when someone new joins either team.

Which meetings are worth the shared time

Offshore teams more often have too many meetings than too few, and each one uses up overlap. Keep the meetings where people need to think together: planning, demos, retrospectives and a weekly check-in on risks and scope between your product owner and the delivery lead. Replace the rest with writing.

Good candidates to move into writing are status meetings, progress reports read aloud, information-only briefings and stand-ups where people recite their tickets. If you run Scrum with an outside team, our post on agile with an external development team covers the ceremonies in more detail.

Use one set of tools

The tools matter less than both sides using the same ones. Our teams work in the client's own Slack, Jira and GitHub. There is no second set of tickets to keep in step, and you can see progress whenever you like. You also talk to the engineers directly, not only through a project manager.

Keep team conversations in shared channels rather than private messages, so the person in the other time zone can catch up on what was said. Show both teams' local times in the channel or the calendar, so nobody books a call in the middle of someone else's night.

Where to start

Write down the overlap window in both time zones and put it in both calendars. Name your product owner and a deputy. Agree the format of the daily update and the handoff note before the first sprint, then review both after a couple of weeks.

If you are bringing in a new partner, read our post on onboarding a software development partner. To see how a Coretus squad works inside your tools with at least four hours of daily overlap, look at managed engineering squads or book a free 30-minute call.