Timezone Rotation Killed My Team's Trust - A Cautionary Tale

[mobile_maria]

I need to share a failure story because I’ve seen a lot of advice about “fair timezone rotation” for distributed teams, and I tried it, and it nearly destroyed my team.

Context: I lead mobile platform engineering at Uber with folks in São Paulo (where I’m based), San Francisco, and London. Three timezones, nobody happy with meeting times. The São Paulo and SF folks complained London was always asleep. London complained meetings were always too late. SF complained about early meetings.

I read all the distributed team handbooks. They all say the same thing: “Rotate meeting times so everyone shares the pain equally.”

So I tried it.

The Rotation Experiment

We had one critical weekly sync - architecture review for mobile platform changes. Instead of fixing it at one time, I created three rotating slots:

• Slot A: 8am PT / 11am ET / 4pm London (terrible for SF, great for London)
• Slot B: 12pm PT / 3pm ET / 8pm London (middle ground, nobody loves it)
• Slot C: 4pm PT / 7pm ET / midnight London (great for Americas, brutal for London)

Week 1: Slot A. SF folks groggy and unprepared. Decisions made without proper context.

Week 2: Slot B. Everyone present, everyone distracted. Half the team cooking dinner, others answering morning emails.

Week 3: Slot C. London engineer joins from his living room at midnight, clearly exhausted. Contributes nothing meaningful.

This went on for 8 weeks.

The Breaking Point

One of our senior engineers quit. In his exit interview, he cited “timezone chaos” as a major factor. He said: “I never knew when I needed to be present. I was always either sleep-deprived or underprepared. I couldn’t plan my life around a rotating schedule.”

That hit hard.

I did a retro with the team. The feedback was unanimous: “Fair” rotation wasn’t fair. It was equally terrible for everyone.

Here’s what I learned:

Fairness ≠ Equality when contexts differ.

The SF/São Paulo folks had a 1-4 hour timezone gap depending on daylight savings. That’s manageable - we had natural overlap from 10am-2pm PT.

London was 8 hours ahead of SF. No amount of rotation fixes that. Someone is always suffering.

The “fair rotation” approach assumed all suffering is equal. But it’s not:

• Missing sleep is worse than joining a meeting during your lunch
• Unpredictable schedules (rotation) are worse than consistently inconvenient times
• Asking parents to take midnight calls is different from asking single folks

The New Approach

After that disastrous experiment, we shifted to: Optimize for the majority, compensate the minority.

Our team is 8 people: 4 in Americas (SF + São Paulo), 3 in London, 1 in Bangalore.

New rule: All regular syncs happen in the SF/São Paulo overlap window (10am-2pm PT). That’s 1-5pm São Paulo time, 6-10pm London time.

London folks join in their evening (not ideal but predictable). We make it worthwhile:

• Meetings recorded + transcribed for async review
• Written summary posted within 2 hours
• Decisions documented in Notion same day
• London engineers get comp time the next morning (start late)

For Bangalore (12.5 hour gap - even worse than London), we don’t force synchronous attendance. He watches recordings and provides async feedback. For critical decisions, we schedule one-off meetings at a compromise time.

The Investment

To make this work, we invested heavily in async infrastructure:

• Better meeting recordings (Zoom + automated transcripts)
• Loom for technical walkthroughs
• Decision logs in Notion (EVERY decision documented)
• Async approval process (48-hour decision window)

The London engineers also get explicit compensation:

• One late meeting per week max
• Comp time the next day (start 2 hours late)
• Option to dial in audio-only if it’s purely informational

The Results (6 Months In)

• Team satisfaction up
• No more surprise late/early meetings
• London folks feel respected (compensated for inconvenience)
• Decision velocity actually improved (async approval is faster than scheduling)
• Zero turnover since the change

The Hard Truth

This isn’t perfectly fair. The SF/São Paulo folks have timezone privilege. But recognizing that and compensating for it is better than pretending rotation makes it equal.

The key insight: “Fair” is about outcomes, not equal suffering.

I’d rather have a sustainable system where 4 people are comfortable and 3 people are occasionally inconvenienced (but compensated) than a rotation where everyone is always miserable.

My Question

How do you handle timezone equity? Have you tried rotation? What worked? What failed?

Especially curious about:

• Teams with even wider distributions (APAC + EMEA + Americas)
• How you compensate folks in minority timezones
• Whether you’ve found rotation models that actually work

I’m convinced timezone rotation is a bad idea, but I’m open to being wrong. What’s worked for you?

[vp_eng_keisha]

Maria, thank you for sharing this. The honesty about failure is exactly what this community needs.

I faced a similar challenge with my team distributed across Atlanta, San Francisco, and Bangalore. Your conclusion - “optimize for majority, compensate minority” - is exactly where I landed, but I took a different structural approach.

The Timezone Pod Model

Instead of trying to make everyone attend everything, we split into timezone-based ownership pods.

Here’s how it works:

Americas Pod (Atlanta + SF): 5 engineers, 3hr max timezone gap

• Owns: Customer-facing features, web platform, US infrastructure
• Sync window: 10am-2pm PT (1-5pm ET)
• Decision authority: Can make technical decisions within their domain

Asia Pod (Bangalore + Singapore): 4 engineers

• Owns: Backend services, data pipeline, APAC infrastructure
• Sync window: 10am-2pm IST
• Decision authority: Can make technical decisions within their domain

Cross-pod coordination: Async-first with 48-hour decision windows

• RFCs for anything affecting both pods
• Weekly async written updates (no meeting)
• Monthly sync at compromise time (8pm ET / 6am IST) - brutal but rare

The trade-offs are real:

• Each pod moves fast within their domain (no timezone blockers)
• Sustainable schedules within pods
• Clear ownership boundaries
• Some duplication of systems/expertise
• Coordination overhead for cross-cutting concerns
• Risk of knowledge silos

The key enabler: We shifted from “everyone knows everything” to “everyone knows where to find information.”

Documentation became critical. The Asia Pod can’t wait 12 hours for the Americas Pod to wake up, so everything must be written down. This actually improved our documentation culture more than any mandate.

Where this breaks down:

• Incidents that span both regions (rare but painful)
• Architectural decisions affecting shared infrastructure
• Hiring and culture building across pods

For those cases, we do exactly what you described: scheduled sync at compromise time with heavy compensation and async alternatives.

One thing you said really resonates: “Fair is about outcomes, not equal suffering.”

We tried rotation too. It failed for the same reason - predictable inconvenience is better than unpredictable misery.

My question for you: Have you considered hiring explicitly for timezone coverage? Like, when you have a London-based role, could you hire someone in Portugal or Spain instead of requiring UK-based? Or does the role need to be London-specific for legal/client reasons?

[eng_director_luis]

Maria, I’m so glad you posted this. The timezone rotation advice is everywhere and I’ve always been skeptical.

We have a US-LATAM distributed team (Austin, Mexico City, São Paulo, Buenos Aires), which is “easy mode” compared to your SF-London gap - we’re talking max 4-hour difference. Even with that relatively small gap, rotation attempts failed.

The “Timezone Tax” Budget Model

Here’s what actually works for us: We made timezone inconvenience visible and compensated.

Every meeting outside someone’s 9am-5pm local time generates “timezone tax”:

• Meeting during lunch hour: 0.5x time
• Meeting before 8am or after 6pm local: 1.5x time
• Meeting before 7am or after 8pm local: 2x time
• Weekend meeting: 3x time

That time gets added to a comp time bank. Engineers can use it for:

• Late starts or early departures
• Extra PTO (up to 2 days per quarter)
• Professional development time

Here’s the key: We track this in a shared spreadsheet that everyone can see.

When someone proposes a new meeting time, I literally show them: “This time would generate 12 hours of timezone tax per month. That’s costing us 1.5 engineer-days of focused work time. What async approach have we tried?”

It creates healthy friction. Teams self-police meeting necessity.

Real example:
Product wanted a weekly Americas+LATAM all-hands at 3pm Austin time (6pm Buenos Aires). That’s 3 hours of timezone tax per week (52 × 3 = 156 hours/year) for our Buenos Aires engineers.

When I showed that number, Product pivoted: Monthly all-hands at compromise time (recorded), weekly async written updates. Problem solved, no timezone tax.

The transparency is critical. Everyone can see who’s paying the timezone tax. It prevents the situation where one engineer is always taking the late meetings because they’re too junior to push back.

In our last quarter:

• Total timezone tax: 24 hours across team of 40
• Most equitably distributed (no one person taking >10% of tax)
• Converted to 3 days of comp time for affected engineers

The other thing we enforce: Meeting recordings + async summaries are MANDATORY for any meeting with timezone tax.

If you’re asking someone in São Paulo to join at 8pm, the meeting better be recorded, transcribed, and summarized within 2 hours. No exceptions. We actually blocked calendar invites that didn’t include a Zoom recording link.

Where this breaks:

• True emergencies (production incidents don’t respect timezones)
• Client meetings (customer dictates the time)
• Recruiting (candidates won’t rotate for your convenience)

For those cases, we rotate who takes the hit, but we’re explicit about compensation.

Maria, your “optimize for majority, compensate minority” model is essentially what we’re doing. The difference is we quantify the compensation rather than leaving it implicit.

One question: How do you prevent the “comp time” from becoming theoretical? Like, do people actually take the late starts, or does team pressure prevent it?

[product_david]

Coming at this from a product angle, and I’m going to challenge the premise a bit.

The problem isn’t timezone rotation. The problem is thinking engineering teams and customer needs operate on the same constraints.

Here’s what I mean:

Product managers face timezone challenges with CUSTOMERS, not just team members. When you’re selling enterprise B2B software, your customers are in specific timezones and they want sync calls during THEIR work hours.

We sell to financial services companies in Europe. They want product reviews at 10am London time. We can’t “rotate” that - the customer is in London, period.

My solution: Hire explicitly for timezone overlap, not despite it.

When we needed EMEA coverage, we didn’t ask our SF-based PM to take early morning calls forever. We hired a PM based in Portugal. Explicit job requirement: “This role requires overlap with European business hours.”

That person knew what they were signing up for. They’re not suffering through timezone rotation - they’re working their normal 9-5 in Lisbon, which happens to overlap with London.

Maybe engineering should do the same?

Instead of: “We need a senior backend engineer (anywhere in the world welcome!)” and then struggling with timezone coordination…

Try: “We need a senior backend engineer in Americas timezones (UTC-8 to UTC-3)” or “…in EMEA timezones (UTC-1 to UTC+3)”

Constrain hiring by timezone the way you constrain by skill level, experience, or tech stack.

Trade-offs:

• Sustainable schedules from day one
• Natural overlap for collaboration
• No compensation complexity
• Smaller hiring pool
• Potential for timezone-based pay disparities
• Loses some benefits of global talent access

I know “hire anywhere” is the dream of remote work. But if timezone mismatches are causing this much pain, maybe we’re over-rotating (pun intended) on geographic flexibility.

Maria, in your case: If Uber said “mobile platform team will be Americas + EMEA only, no London,” would that solve the problem? Or are there business reasons you NEED London representation?

Sometimes the answer is: pick your timezones strategically, not randomly.

[priya_security]

Security/incident response perspective here, and I think there’s a model we already solved for this: on-call rotation.

Think about it: Security incidents don’t respect timezones. A production breach at 3am someone’s time needs immediate response. We can’t do async incident response.

How do we handle this? Paid on-call rotation with clear expectations.

• Each engineer takes on-call shifts for 1 week at a time
• If you get paged outside business hours, you get compensated (usually 1.5x time)
• Clear escalation paths if you’re not available
• Rotates fairly so no one is always on call

Why not apply the same model to critical sync meetings?

Here’s what it could look like:

“Timezone On-Call” for critical weekly syncs:

• Designated person responsible for attending inconvenient-timezone meetings
• Rotates monthly (not weekly - predictability matters)
• Explicit compensation: premium pay or comp time
• Clear expectations set during hiring

Example: Your weekly architecture review that hits London at 8pm.

Instead of rotating the meeting time (everyone suffers) or always asking the same London folks (unfair), rotate who from the London team takes the timezone hit.

Week 1-4: London Engineer A is “on timezone duty”, gets premium pay
Week 5-8: London Engineer B takes over
Etc.

The key differences from your rotation model, Maria:

• Person rotates, not meeting time (predictability)
• Explicit compensation (not just goodwill)
• Clear expectations (you know when it’s your turn)
• Opt-in at hiring (if you can’t do occasional evening meetings, don’t join London team)

This works in security because:

1. We acknowledge incidents are exceptions, not the norm (most weeks, no incidents)
2. Compensation is real and tracked
3. Rotation is transparent

Could work for distributed teams if:

1. You acknowledge sync meetings should be rare (not daily standups)
2. Compensation is real (money or time, not just “flexibility”)
3. Rotation is transparent and fair

Thoughts?