Working hours that overlap — US, Europe, and India
If your team has people in San Francisco, London, and Mumbai, you have one of the harder time-zone configurations in modern business. The natural overlap window — when all three are at desk during business hours — is narrow to nonexistent. Most three-zone teams work async-first. The ones that don't make sacrifices.
For checking specific overlaps, the meeting planner handles three-zone math. The rest of this post covers the patterns.
The basic math
Standard business hours (10 AM-4 PM local in each zone):
- San Francisco (UTC-8 winter, UTC-7 summer): 10 AM-4 PM = 18:00-00:00 UTC winter, 17:00-23:00 UTC summer
- London (UTC+0 winter, UTC+1 summer): 10 AM-4 PM = 10:00-16:00 UTC winter, 09:00-15:00 UTC summer
- Mumbai (UTC+5:30, no DST): 10 AM-4 PM = 04:30-10:30 UTC year-round
The overlap of all three is essentially zero. There's no UTC time when all three are inside their 10 AM-4 PM window.
The least-bad combinations:
SF-London overlap (skipping Mumbai):
- 17:00-18:00 UTC ≈ 5-6 PM London / 9-10 AM SF
- 1 hour, end of London's day, start of SF's
London-Mumbai overlap (skipping SF):
- 09:30-10:30 UTC ≈ 9:30-10:30 AM London / 3-4 PM Mumbai
- 1 hour, start of London's day, end of Mumbai's
SF-Mumbai overlap:
- 18:00-04:30 UTC = "no overlap."
- The least-bad time is 14:00 UTC ≈ 6 AM SF / 7:30 PM Mumbai. Both inconvenienced.
Three-zone strategies
Real teams use one of four approaches:
1. Async-first. Most decisions are made via written documents (RFCs, design docs, written status updates). Meetings reserved for emergencies and brainstorming. This is the dominant pattern for distributed teams.
2. Pair-wise sync. Schedule one weekly meeting between SF-London (during the 5-6 PM London window), one between London-Mumbai (during the 9:30-10:30 AM London window), and SF-Mumbai handles via async.
3. Rotating "world meeting." Once a week, pick a time that's painful for one region and tolerable for the other two. Rotate which region absorbs the pain.
4. Two of three principle. Accept that any synchronous meeting will be at painful hours for one region. Pick which region is "off" for each meeting based on relevance.
The classic SF-London-Mumbai schedule
A common recurring schedule for three-zone teams:
| Meeting | UTC time | SF | London | Mumbai |
|---------|----------|----|--------|--------|
| US-India weekly | 14:00 UTC | 6 AM | 2 PM | 7:30 PM |
| US-Europe weekly | 17:00 UTC | 9 AM | 5 PM | 10:30 PM |
| Europe-India weekly | 09:30 UTC | 1:30 AM | 9:30 AM | 3 PM |
Notice: each meeting is uncomfortable for one region (US gets early mornings, India gets late evenings, etc.). But by rotating, no one always takes the bad slot.
Why India ends up taking the late slot
Three-zone US-Europe-India teams almost always have India's recurring slots in the evening. Reasons:
- US-Europe overlap is during US morning / Europe afternoon — both reasonable
- Adding India to a US-Europe meeting pushes India to evening
- Asking US-Europe to wake up early (5 AM SF / 1 PM London) is harder than asking India to stay late (9 PM IST)
Some Indian engineering teams are explicitly hired with the expectation of evening shift work. Others rotate so the evening burden is shared.
Bangalore vs Mumbai vs Delhi
Indian cities are all on UTC+5:30 (no DST), so the time math is identical regardless of which city. Cultural and personal preferences vary:
- Bangalore has a heavy IT/outsourcing concentration; many engineers there are accustomed to evening US calls
- Mumbai is more finance-oriented; financial markets are tied to Mumbai exchange hours
- Delhi is more government/policy work; less evening overlap pressure
For practical scheduling, treat all of India as a single zone (UTC+5:30).
Handling DST shifts
Both US and Europe shift DST; India doesn't. So the gap between India and US (or Europe) shifts twice a year:
- US summer (EDT): Mumbai is 9.5 hours ahead of NY
- US winter (EST): Mumbai is 10.5 hours ahead of NY
- Europe summer (CEST): Mumbai is 3.5 hours ahead of Berlin
- Europe winter (CET): Mumbai is 4.5 hours ahead of Berlin
For Mumbai, US shifts make recurring meetings appear to shift by an hour each spring/fall. Europe shifts do the same.
The fix is the same as always: anchor recurring meetings to UTC. The Mumbai team sees the meeting at the same UTC moment year-round, and the US/Europe teams see their local time shifting due to DST.
Best practices for three-zone teams
1. Use UTC for recurring scheduling. All meetings appear at consistent UTC times. Local times shift with DST.
2. Document expected response times. A Mumbai engineer expecting US response within 2 hours during their day will be disappointed; the realistic expectation is "next-day during US working hours."
3. Use written-first communication. Slack threads, design docs, written summaries. Synchronous meetings are expensive at three-zone scale.
4. Hand-off rituals. "Follow the sun" model — work moves from East (India) to West (Europe) to West (US) over the course of a 24-hour cycle. Each region picks up where the last left off via shared docs.
5. Avoid 24/7 expectations. Just because you can theoretically have someone at desk every hour doesn't mean you should. Burnout is real and worse for three-zone teams.
6. Vacation and holidays differ. US Thanksgiving (late November), Indian Diwali (around October-November), European Christmas (December). Three different vacation calendars to track.
Small companies vs large
Large companies (5,000+ engineers) can usually staff three-zone teams adequately. The scheduling is hard but the resources exist.
Small companies (under 100 engineers) often find three-zone teams unsustainable. The overlap is too narrow, the management overhead too high. Many companies that scale internationally pick "two zones" — US + India, or US + Europe — rather than all three.
If your company has 50 engineers split across three zones, you have the worst of all worlds. Either consolidate to two zones or accept aggressive async-first culture.
Sample week for a three-zone team
A realistic schedule for a small three-zone team:
Monday:
- 14:00 UTC: US-India product sync (45 min)
- 17:00 UTC: US-Europe roadmap sync (45 min)
Tuesday:
- 09:00 UTC: Europe-India engineering sync (45 min)
Wednesday:
- (no meetings, async-first)
Thursday:
- 14:00 UTC: All-hands (recorded; everyone watches at their convenience)
- 18:00 UTC: 1-on-1s with US managers and India team members
Friday:
- (heads-down focus day, no meetings)
This pattern rotates the burden, uses async between meetings, and reserves Wednesday and Friday for deep work.
FAQ
Is "follow the sun" really practical?
For some specific tasks (24/7 monitoring, customer support), yes. For complex engineering work that requires deep collaboration, often not — the hand-off cost between zones can outweigh the benefit of round-the-clock progress.
What if my company doesn't have an established async culture?
Building one takes 6-12 months of explicit investment. Hire a remote-work lead, establish written-first norms, document everything. It's painful at first; smooth within a year.
Should I just hire only in two zones?
If you have the choice, yes — two zones is dramatically easier than three. The reason teams end up in three zones is usually cost optimization (cheaper engineering in one zone) which conflicts with management simplicity.
What about acknowledged "3 hours overlap is enough" teams?
Some teams rely on a 3-hour US-Europe overlap (5 PM London / 9 AM SF) and an explicit 1-hour overlap with India (after-hours for India). It works but requires Indian team members to accept evening shifts.
How do I respect my Indian colleagues' time?
Don't schedule recurring meetings outside 8 AM-8 PM IST without explicit consent. Don't expect responses outside Mumbai business hours. Trust async work; don't equate response speed with effort.
Bottom line
US-Europe-India is one of the hardest three-zone configurations. The natural overlap is ~1 hour or less. Successful teams use async-first cultures, rotate meeting burden, and accept that recurring meetings will be uncomfortable for at least one region. Anchor recurring meetings to UTC to handle DST shifts cleanly.
For specific overlap windows for any three-city combination, the meeting planner shows them.