Follow-the-Sun Sounds Great Until You Try It—What Timezone Strategies Actually Work at Scale?

General
1

“Follow-the-sun” sounds amazing in pitch decks. In practice, it’s a coordination nightmare.

My EdTech startup scaled from 25 to 80+ engineers across 4 timezones in 18 months. We tried every timezone strategy in the playbook. Some worked. Most failed spectacularly.

Here’s what we learned—and the data behind it.

Attempt #1: Overlap Hours (Failed)

The theory: Find 2-3 hours daily where everyone’s online. Use that for collaboration. Rest of the day is focused work.

The reality:

  • East Coast team: 9 AM - 11 AM ET (reasonable)
  • Europe team: 2 PM - 4 PM GMT (fine)
  • APAC team: 11 PM - 1 AM Singapore time (brutal)

We burned people out. Our Melbourne-based senior engineer stayed online until midnight for “overlap hours” then worked her normal day. After 6 months, she told me she was looking elsewhere specifically because of timezone demands.

Lesson: Overlap hours sound fair until you realize someone’s always sacrificing their evenings or mornings. The edge timezones bear the burden.

Attempt #2: Regional Teams (Created Silos)

The theory: Organize teams by timezone. Americas team, EMEA team, APAC team. Minimize cross-timezone dependencies.

The reality:

  • Regional teams became feature silos
  • Knowledge hoarding (each team had unique context)
  • Customer-facing features couldn’t be delivered by single region
  • Product roadmap fragmented by geography, not strategy

Data: Our deployment frequency dropped 30% because features required cross-team handoffs that took days.

We were optimizing for timezone convenience at the expense of actual product velocity.

Lesson: Conway’s Law applies to timezones. Team structure shapes system architecture. Regional teams create regional systems.

Attempt #3: Hybrid Model (What Actually Works)

After two failed approaches, we landed on something that works—not perfect, but functional:

Daily 2-Hour Overlap Window

  • Americas: 11 AM - 1 PM ET
  • EMEA: 4 PM - 6 PM GMT
  • APAC: 1 AM - 3 AM Singapore (BUT: we don’t require APAC attendance)

APAC team handles incidents during their day, stays updated via documentation. They join overlap hours only for critical discussions (once every 2-3 weeks max).

Strong Documentation Culture

Everything significant gets documented:

  • Architecture decisions → ADRs
  • Product decisions → RFC process
  • Incidents → Blameless postmortems
  • Feature specs → Product briefs with clear success criteria

Rule: If it’s not documented, it didn’t happen.

Follow-the-Sun for Incidents Only

Incident response works follow-the-sun:

  • Each region has on-call rotation
  • Handoff protocol for multi-day incidents
  • Detailed incident logs for context transfer
  • Any engineer can respond using runbooks

This works because incidents are well-defined. You’re not making creative decisions; you’re executing established procedures.

Feature Work Stays Team-Owned

Feature development does NOT follow-the-sun:

  • Teams own features end-to-end
  • Cross-timezone collaboration happens async (PRs, RFC comments)
  • No “handing off” feature work between timezones

Why: Feature development requires context that’s nearly impossible to hand off. You end up re-explaining decisions daily.

The Data That Changed Minds

Before this hybrid model:

  • Blocked PR wait time: 18 hours average (waiting for reviewers in other timezones)
  • Decision lag: 4.2 days (time from “we need to decide” to “decision communicated”)
  • Meeting load: 22 hours/week average per engineer
  • Deployment frequency: 8 deploys/week

After hybrid model (6 months later):

  • Blocked PR wait time: 6 hours average (multi-reviewer policy, load balancing)
  • Decision lag: 1.9 days (async RFC process with time-boxed review)
  • Meeting load: 12 hours/week average per engineer
  • Deployment frequency: 26 deploys/week

When I showed these metrics to the team, behavior changed. Documentation stopped feeling like busywork—it was the thing that unblocked velocity.

What Still Doesn’t Work

Even with this model, we struggle with:

1. Real-Time Creative Collaboration

Product brainstorming, design critiques, architecture whiteboarding—these still work better synchronously. We record sessions for timezone-shifted teammates, but they miss the “riffing” energy.

2. Trust Building

Hard to build trust async. We do bi-annual team offsites (expensive but essential). Remote-first doesn’t mean never-meet.

3. Urgent Customer Escalations

When a major customer has a critical issue, sometimes you need real-time coordination. We can’t always wait for async handoffs.

4. New Hire Onboarding

Ramping up new engineers across timezones is slow. They miss casual knowledge transfer and hallway conversations. Deliberate mentorship and documentation help but don’t fully replace.

The Question I’m Still Wrestling With

Is there a timezone strategy that scales indefinitely, or does it break at certain team sizes?

At 25 people, overlap hours worked fine (everyone in US/Europe). At 80 people across 4 timezones, hybrid model works. But what about 200 people across 8 timezones?

At some point, does timezone distribution become more cost than benefit? Or is this just a skill we haven’t mastered yet?

What’s Your Experience?

For folks running distributed teams:

  • What timezone strategies have worked for you?
  • How do you handle creative collaboration across timezones?
  • Is follow-the-sun realistic for feature development, or only operations?
  • At what team size did timezone distribution start creating more problems than it solved?

I’m convinced that solving async engineering across timezones is one of the biggest competitive advantages a company can have. But I’m less convinced that most of us—including me—have truly figured it out.

2

Keisha, your experience with regional teams creating silos resonates deeply. We saw exactly that at my financial services company.

Follow-the-Sun Works for Ops, Fails for Features

I lead engineering at a major bank. We’re heavily regulated, which means incident response and compliance monitoring require handoffs we can’t avoid.

What works for us:

Incident Response (True Follow-the-Sun)

  • Austin team: 8 AM - 4 PM CT
  • London team: 9 AM - 5 PM GMT
  • Singapore team: 9 AM - 5 PM SGT
  • Near 24/7 coverage with only 2-hour gaps

Each region has on-call rotation. Multi-day incidents get explicit handoffs with detailed logs. Works well because incident response is procedural—you’re following runbooks, not making creative decisions.

Feature Development (Definitely NOT Follow-the-Sun)

We tried having Austin start features, hand to London, then to Singapore. Disaster.

Problems:

  • Context loss at every handoff (30% of first day spent understanding what Austin did)
  • Architectural decisions made without full team input
  • Code review delays (PR submitted in Austin, reviewed in London next day, changes needed, waits for Austin again)
  • Resentment (Singapore team felt like “code janitors” cleaning up Austin’s work)

Time-to-delivery increased 40% despite theoretically having 24-hour development cycles.

We switched to team ownership: each team owns features end-to-end, coordinating async when needed. Much slower on paper (single-timezone work hours), much faster in practice (no handoff overhead).

The Compliance Handoff Lesson

You mentioned feature work requiring context that’s hard to hand off. We learned the distinction is procedural vs creative work:

Procedural work (follows-the-sun works):

  • Monitoring alerts and responding per runbook
  • Compliance checks following documented criteria
  • Infrastructure maintenance with clear procedures
  • Customer support with detailed knowledge base

Creative work (follows-the-sun fails):

  • Feature architecture decisions
  • Code review with architectural feedback
  • Performance optimization (requires deep system understanding)
  • Security threat modeling

The difference: procedural work has explicit success criteria and documented steps. Creative work requires shared context and judgment calls.

Is Async Better for Operational Work?

Your question about whether async works better for operations vs problem-solving is interesting.

In financial services, regulatory requirements force documentation. Every significant decision needs audit trail. This accidentally makes us better at async work—we have to write everything down anyway.

Unexpected benefit: Our compliance requirement for documentation enables timezone distribution. Companies without regulatory forcing functions struggle to build documentation discipline.

Maybe the question isn’t “how do we make async work?” but “what external forcing function creates documentation discipline?”

For regulated industries: compliance
For open source: external contributors require docs
For high-growth startups: ???

Still figuring that one out.

3

Keisha, your data on deployment frequency dropping 30% with regional teams is exactly what we experienced during our cloud migration.

Time-Boxed Decision Windows That Actually Work

We coordinate across Seattle, London, and Bangalore for our SaaS platform. The breakthrough for us was time-boxed decision cycles with explicit approval windows.

The RFC Process We Use

When someone needs a decision (architecture change, product direction, process update):

Day 0: Post RFC document

  • Context, proposal, alternatives considered, success criteria
  • Explicitly tag: Driver, Approver(s), Required Contributors, Optional Contributors

Day 1-2: 48-hour comment window

  • Required Contributors must comment (questions, concerns, approvals)
  • Optional Contributors may comment
  • Driver responds to questions, updates RFC

Day 3: Approver makes final decision

  • If no blocking concerns: approved
  • If concerns raised: Approver decides whether to proceed, modify, or reject
  • Key rule: If Required Contributor doesn’t comment in 48 hours = implicit approval

Result: Average decision latency dropped from 5.3 days to 2.1 days.

The Controversial Part: Implicit Approval

The “no response = approval” rule was contentious. Engineers worried decisions would be made without their input.

We added safeguards:

  • RFCs must tag specific people (not “everyone”)
  • Email + Slack notification when tagged
  • If you’re tagged and can’t respond in 48 hours, explicitly delegate to someone who can
  • Big architectural decisions require explicit approvals (no implicit)

After 6 months, implicit approval rate dropped from 30% to 8%—once people saw the process worked, they engaged.

Building Trust Without In-Person Time

You asked how to build trust in distributed teams without in-person time. Honestly? I don’t think you can.

We do team offsites twice yearly:

  • Entire engineering org (120 people now)
  • 3 days, mix of work sessions and social time
  • Expensive (~$180K per offsite with travel/lodging)
  • Board questions it every time

But the data supports it:

  • Post-offsite engagement surveys: 40% increase in “trust team members” rating
  • PR review quality improves (more thoughtful feedback, less defensive responses)
  • Cross-team collaboration requests increase 25%
  • Effect lasts about 5-6 months, then starts declining

My take: Remote-first doesn’t mean never-meet. It means async-by-default, with intentional sync moments.

Those offsites are expensive, but so is having distributed teams that don’t trust each other. The ROI is there, even if it’s hard to measure.

What Breaks at Scale

Your question about what team size breaks timezone distribution is haunting me.

At 50 engineers (3 locations), our hybrid model worked.
At 120 engineers (3 locations), it’s creaking but functional.
At 200+ engineers (5+ locations), I suspect we’ll need regional autonomy with light coordination—basically accepting regional silos as a trade-off.

Hypothesis: Maybe full distribution doesn’t scale past 100-150 people. Beyond that, you need regional teams with clear ownership boundaries, accepting that some coordination overhead returns.

The companies that seem to make it work at huge scale (GitLab, Automattic) have extremely strong documentation culture and very clear ownership boundaries. It’s not just timezone strategy—it’s organizational design.

Still figuring this out. Don’t have the answers, just more expensive experiments ahead.

4

The “real-time creative collaboration” problem is hitting me hard right now.

Design Collaboration Doesn’t Translate to Async

My design systems team spans Austin and Poland (only 8-hour difference, not even that extreme). We’ve tried every async design critique method:

What we tried:

  • Figma comments: Thoughtful but slow, misses collaborative energy
  • Loom walkthroughs: Nobody watches 10-minute videos
  • Async design sprints: Felt forced and mechanical
  • Written critique docs: Too formal, killed creativity

What actually works: Live sessions with recordings for timezone-shifted folks.

But here’s the uncomfortable truth: people who watch recordings aren’t really participating. They’re observing. The decisions get made in the live session, and the recording is just FYI.

We’re calling it “async-first” but it’s really “sync with async observers.”

The Starter Fail Context

Luis mentioned that regulated industries accidentally get better at async through compliance requirements. That’s fascinating because my failed startup had the opposite problem—zero forcing function for documentation.

Three founders, no regulatory requirements, no external contributors, just internal chaos. Nothing forced us to write things down.

Looking back, we needed artificial constraints:

  • “No decision made in Slack is real” policy
  • “If it’s not in Notion, it didn’t happen” rule
  • Weekly decision log review

But we were too chaotic to impose discipline on ourselves. Classic startup trap.

Questions Timezone Distribution vs Startup Speed

Michelle mentioned team offsites costing $180K. My startup couldn’t afford that. Most early-stage startups can’t.

This makes me wonder: Is timezone distribution a privilege of later-stage companies?

Early-stage advantages of co-located:

  • Faster decision-making (just turn around and ask)
  • Serendipitous collaboration (overhear relevant discussion)
  • Culture building (shared struggles create bonds)
  • Lower coordination overhead (no documentation infrastructure needed)

Distributed advantages kick in later:

  • Access to global talent (matters when hiring is competitive)
  • 24/7 development cycles (matters at scale, not 5-person team)
  • Documentation culture (investment pays off with team size)
  • Timezone coverage (only needed for always-on services)

Maybe the answer is: co-located for 0-20 people, hybrid for 20-100, structured distribution for 100+?

Not sure. But Keisha’s point about timezone distribution creating more problems at certain sizes resonates. My startup died partly because we went distributed too early—before we had the documentation discipline or team size to make it work.

5

Keisha, your blocked PR wait time dropping from 18 hours to 6 hours is exactly the kind of metric that matters for product velocity.

Customer Research Across Timezones

I run product for a B2B fintech with customers across Americas, EMEA, and APAC. User research across timezones taught me some hard lessons.

What Works: Written Research Summaries

We do user interviews in whatever timezone the customer is in. PM in their region conducts it, records session, writes detailed summary with:

  • Key insights (bullet points)
  • Direct quotes (customer’s words)
  • Implications for roadmap
  • Recommended actions

Finding: Written summaries get read and acted on. Recordings don’t.

Tracked it:

  • Research video watch rate: 12% of intended audience
  • Research summary read rate: 87% of intended audience
  • Actions taken from video: ~15% result in roadmap changes
  • Actions taken from summary: ~60% result in roadmap changes

Conclusion: Writing forces synthesis. Videos create illusion of transparency but nobody has time to watch 45-minute interviews.

The Forcing Function for Product Documentation

Luis mentioned regulated industries have compliance as forcing function for docs. For product teams, the forcing function is cross-functional alignment.

Product decisions affect: engineering, design, marketing, sales, support, success.

If you try to communicate product strategy through meetings, you end up with:

  • 6 different meetings for 6 different functions
  • Inconsistent messaging (you explain it slightly differently each time)
  • People who missed meetings operating on outdated info
  • Constant “wait, when did we decide that?” questions

Written product briefs solve this:

  • Single source of truth
  • Everyone reads same content
  • Async questions in comments
  • Clear approval trail (“PM approved on [date]”)

Side benefit: Written briefs force you to think through decisions more carefully than talking through them.

Timezone Distribution for Product Discovery

Maya asks if timezone distribution is a later-stage privilege. From product perspective, I’d say distribution helps product discovery, hurts product delivery.

Discovery advantages of distribution:

  • Customer access across timezones (can interview APAC customers during their business hours)
  • Market insights from local team members (cultural context matters)
  • Round-the-clock user testing (ship beta, get feedback from APAC overnight, iterate)

Delivery disadvantages:

  • Cross-functional alignment harder (PM, design, engineering across timezones)
  • Sprint planning more complex (harder to get everyone in room)
  • Launch coordination requires timezone gymnastics
  • Customer escalations don’t respect timezone boundaries

My take: Early-stage startups optimizing for speed should co-locate product/engineering/design. Later-stage companies with established product-market fit can benefit from distribution for discovery.

The ROI Question on Offsites

Michelle mentioned $180K offsites. Our Series B startup can’t afford that yet, but I’m making the case for one annual offsite (~$50K for 25 people).

Framing it to CFO/board:

  • Not a perk, an operating expense for distributed team effectiveness
  • Measure ROI: Post-offsite collaboration metrics, decision velocity, employee retention
  • Alternative cost: Failed cross-functional projects due to misalignment cost more than $50K

Still haven’t gotten approval. But treating it as infrastructure investment rather than team-building expense helps the conversation.

Timezone distribution isn’t free—coordination has real costs. The question is whether we’re honest about those costs and willing to invest in making it work.