# Four hours of overlap is the standard advice. Ask which four.

Europe's clocks go back on 25 October and America's on 1 November, and every team split across continents feels it. Overlap is counted in the wrong unit. How to place the hours that matter, and what to ask anyone promising your hours.

By Precision Code Studios. Published October 18, 2026. Category: Hiring. https://www.precisioncodestudios.com/insights/overlap-hours-ask-which-four

On Monday 2 November, the ten o'clock stand-up in New York will reach an engineer in Bengaluru at half past eight in the evening. The Monday before, it reached them at half past seven. Nobody moved the meeting. Under the current rules the United States turns its clocks back on Sunday 1 November, India does not change its clocks at all, and the call will now sit an hour deeper into that engineer's evening until March.

Europe goes first, on Sunday 25 October, which leaves North American and European teams with an odd week in between when London is four hours ahead of New York instead of five. If you work with engineers on another continent, or you are deciding whether to, these two weeks are a free stress test. The meeting someone misses, the review that waits overnight, the on-call handover with an hour-long hole in it: the clock change does not cause any of these. It shows you where the team was relying on luck.

The standard advice for distributed teams is to secure about four hours of overlap a day. It is fine as a starting number, but two teams with the same four hours can have completely different weeks. What decides the week is which hours overlap, what they are spent on, and how long a question waits when it lands outside them.

## Measure the wait, not the overlap

Take a typical arrangement. A product lead in New York works nine to five. An embedded engineer in Berlin also works nine to five. In winter Berlin is six hours ahead, so they share two hours: 3 to 5 p.m. in Berlin, 9 to 11 a.m. in New York.

Now follow one question. At half past nine in Berlin the engineer notices that the spec says refunds go back to the original card, and the payment provider cannot do that for one of the card types the product accepts. They post the question and move on. The product lead's morning is two back-to-back meetings, as most leads' mornings are. The reply goes out at half past eleven New York time, which is half past five in Berlin, after the engineer has logged off. They read it at nine the next morning. A two-minute decision took twenty-three and a half hours.

One slow answer is an annoyance. The real damage is what the team learns from it. Engineers who have waited a day a few times stop asking and start guessing, and a sensible guess is right often enough to feel safe. By the third sprint the pull requests are large, confident and built on assumptions nobody confirmed. The rework arrives in review, a week after the guess was cheap to fix.

> **The real measure:** Overlap counts hours. What hurts is the longest a question can wait for an answer. Measure that, and arrange the day so it stays well under one working day.

## Move the window to where the questions are

The fix in that example costs nothing and takes one conversation. Each person moves by an hour. The engineer works ten to six in Berlin, the lead works eight to four in New York, and the lead spends the first half hour of that earlier start on the stand-up and whatever questions come with it. The shared time grows from two hours to four, and the stand-up now opens the window instead of closing it, so the morning's blockers are settled while both people still have an afternoon to act. The same refund question, asked at half past ten, is answered at two o'clock Berlin time. The wait falls from most of a day to three and a half hours.

*Figure: Two timelines in Berlin time. Nine to five in both cities gives two hours of overlap, filled by meetings, and a 09:30 question waits 23.5 hours. When each side shifts an hour, the overlap doubles to four hours and the question waits 3.5. Same people, same work. One hour of shift on each side, and a stand-up at the start of the overlap, cut the worst wait from a day to an afternoon.*

Two details matter. First, small shifts on both sides beat a large shift on one. Ask only the engineer to move, by four hours or until midnight, and within a year they will either leave or quietly stop being senior after ten at night. Second, the shared hours belong at a point in each person's day where they can still act on what they hear. An overlap that falls in the engineer's last hour, when they are tired and about to stop, is worth less than the same hour at the start of their afternoon. We would rather see four well-placed hours than eight nominal ones.

## Spend the shared hours on what only they can do

Scarce hours get wasted in a familiar way: a stand-up where a dozen people read their tickets aloud. Anything that can be written can wait for the other side to wake up. Keep the overlap for work that needs two people at once.

- **Decisions with trade-offs.** Questions like the refund one, where the engineer needs a judgment call rather than a fact. Five minutes live beats a day of threads.
- **Unblocking.** Access, environments, credentials, the one reviewer who must approve. Early on, this is most of what goes wrong.
- **Live incidents.** When production breaks inside the window, both sides should be on the same call with one person in charge, not trading messages.
- **Pairing on unfamiliar code.** Especially early on, when an hour of shared screen saves a day of reading someone else's assumptions.

Everything else, from status to routine review to demos, works better written down or recorded. If your own team decides things in corridors and never writes them down, more overlap will not fix that, and an engineer on another continent will be the first to feel it.

## The first month needs more overlap than the fourth

The need for shared time is not flat. An engineer in their second week asks a dozen small questions a day: where the staging credentials live, why this service calls that one, who owns the flaky test. By the third month they ask two or three, and they are better questions. Plan for the curve. Give the first four to six weeks a generous window and a named person on your side whose job includes answering, then narrow it once the engineer can find most answers alone. Many teams do the reverse without meaning to, and are back in their own meetings by week three, just as the engineer starts touching real code.

## Write down whose clock the team runs on

Most engagements describe hours vaguely: "overlap with US Eastern", or simply "your working hours". Then the calendar moves underneath them. North America and Europe change their clocks on different Sundays, twice a year; next spring the United States moves on 14 March 2027 and Europe on 28 March, so the odd fortnight comes round again. Countries such as India do not change at all, so their gap to everyone else shifts twice a year.

The rules themselves may move. On 14 July 2026 the US House of Representatives passed the Sunshine Protection Act, which would make daylight saving time permanent, by 308 votes to 117, as U.S. News & World Report covered on 16 July. The Senate has not followed: WTVB reported on 5 October 2026 that the bill was still stalled there, and that the Senate had adjourned for the midterm elections without acting on it. Check where it stands before you write a window into a contract.

*Figure: Six weeks from 19 October 2026. New York and London are four hours apart only in the week of 26 October. A 10:00 New York stand-up reaches Bengaluru at 19:30, then 20:30 from 2 November. Karnataka and US holidays are marked. Six weeks of autumn, two clock changes, and holidays on both sides. None of it shows up in a contract that just says your hours.*

Machines feel this as well. An on-call rota that hands over at end of day in two local times will have an hour with nobody on it, or an hour with two people who each assume the other has it. A nightly job scheduled in UTC, the universal reference time most servers keep, lands at a different local hour after the change, sometimes inside somebody's working day. Check both in the next fortnight.

Then there are holidays. The Farmers' Almanac puts this year's five-day Diwali festival at 6 to 10 November, but a festival is not a day off; what removes overlap is the holiday list your engineers work to. Karnataka's 2026 government list, as published by the payroll compliance site Keka, makes Tuesday 10 November a holiday for Balipadyami (Deepavali), while Naraka Chaturdashi, on 8 November, falls on a Sunday. The same list closes Friday 27 November for Kanakadasa Jayanti, the day after US Thanksgiving, when many Americans are off too. That leaves a New York and Bengaluru team three shared working days that week, at most. Private employers set their own lists, so ask for the one your engineers follow and put it next to yours in the plan.

> **Name the zone:** Write the overlap as a window in one named time zone, check it the week after every clock change, and put every holiday calendar the team lives under into the plan.

## What to ask anyone who promises your hours

"They work your hours" is an easy promise to make and a hard one to check. These questions make it checkable, whoever you hire.

- **Which hours, in which time zone?** A good answer names a window in one zone, such as 9 a.m. to 1 p.m. New York time, and keeps it through clock changes. "Flexible" is not an answer.
- **Where does that window fall in the engineer's day?** If it is always their last two hours, ask how they stay sharp for it, and how long people tend to stay in roles shaped like that.
- **How fast is a question answered outside the window?** Ask for a number of hours, and what happens when the engineer is deep in a task and the question is blocking someone.
- **Whose public holidays apply?** You want the holiday calendars in writing now, and a plan for cover, rather than a surprise in the week of a release.
- **Who adjusts after a clock change?** Someone on the vendor's side should know the dates and send the new meeting times before you notice they are needed.

## When to hire closer to home

Some work does not split well across continents, and an honest vendor will say so. A role that is mostly live conversation, such as a technical lead who spends half the day with customers, needs most of your day, not four hours of it. So does a team that cannot or will not move its decisions into writing. In those cases, hire within two or three hours of your own clock, or ask a vendor with people on several continents to place the role in a zone that suits it, not wherever someone is free.

For most engineering work, the arrangement that holds up is modest: a window written in one time zone, placed where questions arise, with a named person who answers. Over the next two Sundays the clocks will run a small audit for you. Watch whose question waits overnight, which meeting someone misses, and which alert nobody picks up. Each one is a decision about time that someone was already making by accident.

## The short film: transcript

Four hours of overlap? Ask which four.: the short version (1:20).

Most advice on distributed teams stops at a number of shared hours. Where those hours sit in each person's day matters far more.

Nobody rescheduled anything. America turns its clocks back on the first of November, India never does, and that engineer's evening just got an hour longer until March.

Picture a question posted at half past nine in Berlin. The lead in New York spends the morning in meetings, the reply lands after Berlin has logged off, and it's read the next day.

In that Berlin example, the engineer starts an hour later and the New York lead an hour earlier. Neither day changes much, the shared time doubles, and the question is settled by two.

The scarcest hours of the day often go on people reading tickets aloud. Anything that can be written can wait for the other side to wake up.

Promising to work your hours is easy and hard to check. Ask for actual clock times in a city everyone can name, and ask who moves the meetings when the clocks change.

Next March the clocks split again for a fortnight. Teams that wrote their hours down won't even notice.

Read the full article at Precision Code Studios.