Working with a remote development team across time zones

If you're new to working with a remote development team, you probably expect the time difference to cause most of the trouble. In practice, the teams that struggle are the ones without a shared routine: nobody knows where updates go, who decided what, or what was left half done last night. Get those habits right and a distributed team across time zones can keep work moving for more hours of the day than a team sitting in one office.

We wrote this for product owners, engineering managers and founders who already work with remote or offshore developers, or are about to start.

What makes a remote development team work well?

Four habits make most of the difference. Good tools help, but if people don't write things down, no tool will save you.

How many overlap hours do you need?

Overlap hours are the part of the day when both sides are at work. Two to three hours a day is usually enough. Here's an example: a client team in London working 09:00 to 17:00 in summer (08:00 to 16:00 UTC, the shared world clock) and a team in Pune working 09:00 to 17:00 local time (03:30 to 11:30 UTC). They share three and a half hours, from 08:00 to 11:30 UTC.

Example: London and Pune working hours (UTC)

Pune teamPune team: 03:30 to 11:30 UTC

Shared hoursShared hours: 08:00 to 11:30 UTC, three and a half hours

London teamLondon team: 08:00 to 16:00 UTC

00:0006:0012:0018:0024:00

Pune 03:30 to 11:30Overlap 08:00 to 11:30London 08:00 to 16:00

• Spend shared time talking things through. Use it for questions, design discussions, demos and decisions, and put status updates in writing instead.
• Keep the window at the same time each day, so people can plan their quiet, focused work around it.
• Share the early starts. When your working days barely meet, take turns on who joins the early or late call.
• Keep meetings short. A 15 minute daily standup (a quick check on progress and anything stuck) plus a weekly planning session is often all you need.

Make written updates the default

When you're not online at the same time, writing is how work moves forward. This is called asynchronous communication: you leave a clear message and the other person picks it up when their day starts.

• End each day with a short update covering what's finished, what's in progress and what's stuck. Three or four lines will do.
• Write for someone who wasn't on the call. Put down what was actually decided, rather than a note saying a call took place.
• Keep project status in one place, such as a single shared board, instead of spreading it across chat and email.
• Add a bit more detail than feels necessary. One extra minute of writing can save the other side a whole day of waiting.
• Record short screen videos with a tool such as Loom to show a bug or walk through a design.

Teams that write things down well can work nearly as closely from different continents as they would at neighbouring desks.

How should a distributed team record decisions?

Picture a call where two people leave with slightly different memories of what was agreed. In one office, that gets sorted at the coffee machine. Across time zones, it can go unnoticed for a day or more, with both sides building the wrong thing.

• Keep a decision log that says what was decided, by whom, when and why, somewhere the whole team can see it.
• Record technical choices in more depth with an ADR (architecture decision record), a short note on the options you looked at and why you picked one.
• Name an owner for each decision. If a call decides something that affects a person who wasn't there, confirm it to them in writing.
• Change decisions in the open by updating the log.

What makes a good handover?

When work passes from one time zone to the next, the handover is what decides whether you wake up to progress or to a question that cost you a day. Here's how the daily cycle runs in the London and Pune example.

The daily handover cycle (UTC)

1. Pune readsReads the handover.From 03:30
2. Key stepOverlapLive questions and decisions.From 08:00
3. Pune hands overDone, open, blocked.At 11:30
4. London reviewsTests and answers.From 11:30
5. London hands overAnswers for Pune.At 16:00

The cycle repeats every working day.

Use the same short format every time. Put anything urgent at the top. Then list what got done today with links to the tickets or pull requests, what's in progress and the next step, what's stuck and who it's waiting on, and any questions that need an answer before tomorrow's overlap. Be specific: "Waiting on your decision about the refund rule" helps far more than "still working on this". And when you read a handover the next morning, send a quick reply so the other side knows it landed.

How do you keep code quality high across time zones?

• Use pull requests for every change. A pull request is a proposed change that another developer reviews before it goes in, usually on GitHub, GitLab or Bitbucket. Agree how quickly reviews should happen, for example within one working day.
• Set up automated tests and CI/CD, a pipeline that tests and releases every change, so problems get flagged even while the author is asleep.
• Agree what "done" means. For most teams that's reviewed, tests passing, documentation updated and shown in a demo.
• Hold regular demos every sprint (a short working cycle, often two weeks), so misunderstandings surface while they're still cheap to fix.
• Write setup documentation, so a new developer can get started without waiting for someone else to wake up.

Which tools does a remote team need?

Brands matter less than giving each kind of information one home: tasks in Jira, Linear or Azure DevOps; code in GitHub, GitLab or Bitbucket; chat in Slack or Microsoft Teams with a channel per topic; documents and decisions in Confluence or Notion; calls in Zoom, Google Meet or Teams, with notes posted afterwards. After a few weeks, look at what people actually open and drop the rest.

How do you keep a remote team secure?

Offshore collaboration should never mean handing out keys loosely. Set these rules from the first day.

• Single sign on and two factor sign in for every tool the team uses.
• Least privilege, meaning each person gets only the access their role needs, reviewed regularly.
• No live customer data on laptops. Developers work with test data or copies where personal details are masked.
• Company managed devices with disk encryption and automatic updates switched on.
• An offboarding checklist that removes all access on a person's last day, and a confidentiality agreement signed before you share anything sensitive.

Plan for different working cultures

Write in plain, short sentences and go easy on idioms, so a message means the same thing in every country it lands in. If you need to know whether something was clear, ask directly. A quiet nod on a video call can mean "I heard you" rather than "I agree". And keep a shared team calendar, so nobody plans a release for a day when half the team is on a public holiday.

A simple plan for the first month

1. Week 1: agree the overlap window, the tools, who gets which access and what a handover looks like.
2. Week 2: start with small, clearly described tasks so the team gets to know your code and your review process.
3. Week 3: hold the first demo and talk honestly about how communication is going.
4. Week 4: fix whatever felt clumsy, then move on to bigger features.

Next steps

If you're thinking of adding remote developers, our dedicated development team service gives you engineers, designers and testers who fit around your hours and work with your process and your tools. You can also read how our software development process runs, or see how we rebuilt an online store that grew orders 2.4x within a year. Our own teams sit in four regions and cover 24 time zones between them.