The 3 AM Slack message read: "Can someone unblock me on this? I've been waiting 6 hours."
An engineer in Singapore had hit a blocker during his morning. His teammate in California who could help was asleep—and would be for another four hours. By the time she woke up, responded, and the Singapore engineer saw the reply, nearly a full day would be lost.
This happens in distributed teams constantly. The naive solution is overlap hours—force everyone into a window where they're all online simultaneously. But overlap hours are a band-aid that creates new problems: engineers in some time zones work at absurd hours, resentment builds, and the "solution" treats the symptom while ignoring the disease.
The actual solution is designing work that doesn't require real-time unblocking. That's harder than scheduling overlap, but it's the only approach that scales to truly global teams.
At SmithSpektrum, I've helped over 40 companies build distributed engineering teams across every continent[^1]. The ones that thrive don't organize around overlap hours—they organize around autonomy, documentation, and deliberate asynchronous handoffs.
The Overlap Hours Trap
Overlap hours seem logical: find times when everyone is online, schedule meetings and collaboration there, problem solved.
In practice, overlap hours create a two-tier system. Engineers in the "home" time zone work normal hours. Engineers in distant time zones work early mornings or late nights to accommodate the overlap window. Over time, this burns people out and signals that some engineers matter more than others.
Overlap hours also concentrate all synchronous work into a small window. If your only overlap is 8-10 AM Pacific, every meeting, every real-time discussion, every collaboration session gets crammed into those two hours. The rest of the day becomes fragmented, with people waiting for the overlap window to resolve questions.
Worse, overlap hours create artificial urgency. Since synchronous time is scarce, every question feels urgent—better ask now while people are online! This interrupts deep work and trains engineers to depend on immediate responses rather than designing for async.
| Time Zone Strategy | Advantages | Hidden Costs |
|---|---|---|
| Forced overlap hours | Guaranteed sync time | Burns out distant engineers, limits hiring geography |
| "Follow the sun" handoffs | 24-hour productivity | Requires rigorous documentation, handoff overhead |
| Async-first with optional sync | Maximum flexibility | Needs cultural shift, discipline around documentation |
| Regional hubs | In-person collaboration within hubs | Coordination overhead between hubs |
Designing for Async by Default
The fundamental shift is moving from "sync by default, async when convenient" to "async by default, sync when necessary."
This means designing work so that engineers can make progress independently. Not because collaboration is bad, but because blocking on collaboration across time zones is expensive. The goal is autonomous progress with collaboration as enhancement rather than prerequisite.
Async-first requires upfront investment in clarity. If an engineer needs to wait 8 hours for an answer, the question better be precise enough to get an answer on the first try. Vague questions that require clarifying back-and-forth create multi-day delays.
Documentation becomes infrastructure, not overhead. The question that gets asked repeatedly because the answer isn't written down costs far more than the time to document it once. In distributed teams, documentation is literally saving hours per question.
Code reviews need to be thorough and actionable the first time. A review that says "this doesn't look right" forces a round trip. A review that says "this doesn't look right because X, consider Y instead, here's an example in Z file" can be resolved in one iteration.
The Documentation That Actually Matters
Not all documentation is equal. Distributed teams need specific types of documentation that often don't exist in co-located teams.
Decision records capture why choices were made. When an engineer in a different time zone wonders "why did we build it this way?" the decision record answers immediately. Without it, they either guess, wait to ask, or make incompatible choices.
Architecture documentation with context explains how systems work and why they work that way. Not just what the code does—the reasoning, the trade-offs, the constraints that shaped the design.
Onboarding paths that work independently are essential. New engineers should be able to ramp up substantially without real-time help, accessing the information they need when they need it regardless of what time zone they're in.
| Documentation Type | Async Value | Common Gaps |
|---|---|---|
| Decision records (ADRs) | Explains "why" without needing author | Most teams don't have them |
| System architecture docs | Enables independent understanding | Often outdated or missing |
| Runbooks for common tasks | Unblocks without waiting | Usually incomplete |
| Onboarding guides | New hire self-service | Assumed to happen verbally |
| Meeting notes with decisions | Catches up absent time zones | Meetings often undocumented |
Handoff Practices That Work
When work needs to transfer between time zones, the handoff itself requires practice.
End-of-day updates should capture state explicitly. Not "made progress on the feature" but "completed X, blocked on Y, next step is Z, relevant context is here." The engineer picking up should be able to continue without guessing.
PRs should include context for reviewers in other time zones. Why this change? What does it affect? What specifically should reviewers focus on? What decisions were made and why? Front-loading this context prevents review round-trips.
Blockers should be escalated before they become critical. If you know you'll need help in a domain owned by someone in a distant time zone, ask early. Waiting until you're completely blocked, then waiting 8-12 hours for help, then waiting for their response to your clarification—that's how one-day tasks become one-week tasks.
When Sync Is Actually Necessary
Async-first doesn't mean never synchronous. Some activities genuinely benefit from real-time interaction.
Complex problem-solving with high ambiguity often benefits from sync. When the problem isn't well-defined enough to articulate precisely in writing, a conversation can cut through ambiguity in minutes that would take days of async back-and-forth.
Relationship building needs some synchronous time. Trust develops differently through real-time conversation than through text. Teams that never interact synchronously tend to feel like collections of strangers.
Urgent incidents require real-time coordination. When production is down, async handoffs are too slow. Having on-call coverage across time zones—with clear escalation paths—ensures someone can always respond.
The key is intentionality. Don't schedule sync meetings out of habit; schedule them when the specific interaction genuinely benefits from real-time. And when you do schedule sync, ensure the time zones asked to accommodate are rotated fairly—the same people shouldn't always take the awkward hours.
Tools and Practices
The tooling for distributed teams matters, but practices matter more.
Recorded video updates (like Loom) let people communicate with richness without requiring synchronous availability. A five-minute video explaining a design decision communicates tone and nuance that's hard to capture in text, but can be watched whenever the recipient is online.
Persistent chat with threading keeps conversations discoverable. Slack or Discord channels with good threading mean that someone waking up in a different time zone can catch up on what happened and contribute when they're able.
Shared documents with async commenting (like Notion or Google Docs) enable collaborative work across time zones. Rather than a meeting to review a proposal, the proposal lives in a doc, comments accumulate over 24 hours, and everyone's input is captured without simultaneous presence.
Building Culture Across Time Zones
Culture in distributed teams has to be explicit where co-located culture can be implicit.
Norms around response time expectations prevent anxiety. If the norm is "respond within 24 hours" and everyone knows it, nobody feels stressed about not replying instantly. If expectations are unclear, people either burn out trying to respond immediately or feel guilty when they don't.
Celebrating contributions across time zones requires intention. The engineer who ships a feature while the rest of the team sleeps should get recognition—not silence because nobody was awake to notice.
Creating space for informal connection prevents the team from feeling purely transactional. Virtual coffee chats, async "watercooler" channels, periodic team gatherings—these build the relationships that make work feel human.
The engineer who was blocked for six hours waiting for help? His team redesigned how they work. They created detailed runbooks for common blockers. They established async handoff practices with explicit state capture. They documented architectural decisions so engineers could understand systems independently.
Six months later, the average blocking time dropped from hours to minutes—not because overlap improved, but because most questions didn't need to be asked anymore. The answers were already documented.
"We stopped treating time zones as a coordination problem to solve," the engineering manager told me, "and started treating them as a constraint to design around. Once we accepted that we couldn't all be online together, we built systems that didn't require it."
References
[^1]: SmithSpektrum distributed team advisory, 40+ global teams, 2021-2026. [^2]: GitLab Remote Work Report, "Async Communication Practices," 2025. [^3]: Doist, "Async-First Culture Research," 2024. [^4]: Harvard Business Review, "Managing Across Time Zones," 2023.
Building a distributed engineering team? Contact SmithSpektrum for global hiring and async culture strategy.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum