What It Is
Cross-time-zone collaboration is the deliberate design of communication and coordination processes that work when team members are not available at the same time.
The core problem: a company with people in San Francisco, London, and Singapore has 8 to 16 hours of time difference between any two of those locations. If the company’s coordination model depends on real-time communication — Slack responses, scheduled meetings, shared office hours — then the people in Singapore are perpetually disadvantaged. Their “synchronous” participation in a company centered in San Francisco requires them to work at 6am or 11pm regularly.
The practice of cross-time-zone collaboration is the set of choices that move coordination away from this real-time dependency.
Why It Works
Async communication is inherently time-zone-agnostic. A written message sent at 2pm in San Francisco is received and responded to at 10am the next morning in Singapore — and both parties get to do the work at their peak hours, not at hours determined by the other’s location.
Time-zone distribution can become a competitive advantage. A team genuinely active across multiple continents can move 24 hours a day. Zapier’s teams across six continents create a near-continuous work cycle. (Source) The handoff requires good documentation and clear ownership, but the organizational clock does not stop.
Removing the default of synchronous coordination levels the playing field. When meetings and real-time chat are the default coordination mechanisms, employees in minority time zones pay a tax — in sleep disruption, exclusion from key conversations, and second-class status in decisions made while they were offline. Async-first removes that structural disadvantage. [Inference — practitioner observation; not measured cross-company but consistent with what GitLab and Buffer publish about timezone-aware operating norms.]
Writing-first communication is more equitable for non-native speakers. In synchronous meetings, native speakers in the majority language dominate because they can process and respond faster. Written communication gives non-native speakers time to compose thoughtful responses without the real-time pressure. [Inference — based on the absence of accent / fluency / response-latency biases that real-time speaking produces; not a measured empirical finding. Same framing as the corresponding inference on /practices/written-first-culture.]
Where It Fails
“Async” without accountability norms produces silence, not coordination. A team that sends messages without defined response windows does not have an async culture — it has an ambiguous one. Cross-time-zone coordination requires explicit norms: what response time is expected? When is something urgent enough to interrupt? [Inference — practitioner observation; the failure mode is consistent with what Buffer’s “10 Slack agreements” and GitLab’s response-norm guidance both treat as worth codifying.]
Overlap hours as the only mechanism is insufficient but cannot be zero. Some coordination genuinely requires real-time interaction. Teams that have zero overlap hours — and no mechanism for occasional synchronous contact — miss the moments where a 30-minute conversation would save three days of async misalignment.
Decision-making in majority time zones excludes everyone else. The default failure mode: important decisions get made in the time zone cluster where most senior people are located, with others looped in after the fact. This is not async collaboration — it is asynchronous notification of decisions already made. [Inference — central failure mode argued in the page; supported by the contrast between the structurally global Buffer / GitLab / Zapier setups and most “remote-friendly” companies whose decision-makers cluster in one zone, but not measured cross-company.]
Hiring without time-zone awareness creates structural bottlenecks. A fully distributed team where every decision-maker is in the same time zone is a colocated team with remote workers scattered around it. The power and information asymmetry is real regardless of the nominal “remote” label.
Best Examples
37signals / Basecamp — Async by default, no required overlap. No required overlap hours are documented. The system works because the four required communication mechanisms (daily check-in, weekly check-in, heartbeat, kickoff) create visibility without requiring simultaneity. Any employee in any time zone can see what everyone is working on without attending a meeting. (Source)
Their communication principle: “Communication shouldn’t require schedule synchronization. Calendars have nothing to do with communication.” (Source)
GitLab — Meeting guidelines designed for global distribution. GitLab’s meeting guidelines require: agenda 72 hours in advance (minimum 24), optional attendance for non-essential participants, and explicit consideration of EMEA, APAC, and AMER time zones when scheduling. Meeting attendance should be evaluated as optional unless genuinely necessary. (Source)
GitLab’s definition of async work: “Do as much as you can with what you have, document everything, transfer ownership of the project to the next person, then start working on something else.” The handoff model — work flows to whoever is awake — requires strong documentation. (Source)
Buffer — “Give flexibility to get flexibility.” Buffer’s explicit social contract: team members are expected to sometimes stretch their hours to accommodate colleagues in distant time zones. In return, they receive the same flexibility when they need it. The contract is bilateral, not a one-way demand. (Source)
This norm acknowledges that zero synchronous coordination is not realistic — but it makes the accommodation bilateral and voluntary rather than structural and mandatory for certain time zones.
Zapier — Default to transparency enables asynchronous handoffs. When work and decisions are public by default — in shared channels, not DMs — team members in other time zones can pick up context and continue work without waiting for a briefing. “Working in public” is Zapier’s term for this. (Source)
Implementation Guide
1. Define expected response windows explicitly. “We are async” is not enough. Specify: “We expect responses within one business day for standard requests, four hours for urgent requests marked as such.” Write this down and communicate it to the whole team.
2. Identify which decisions require synchronous input. Not every decision can or should be async. Identify the categories — crisis response, certain personnel matters, complex cross-functional alignment — where synchronous coordination is genuinely necessary. For those, identify when synchronous overlap is available and protect it.
3. Document decisions made in one time zone before others wake up. When a decision has to be made while half the team is asleep, write up the decision, the reasoning, and the alternatives considered — and post it where the rest of the team will see it when they come online. Async notification of decisions made in real-time is not the same as exclusion from decision-making; it is a reasonable division of labor when done with transparency.
4. Write meeting agendas 24–72 hours in advance. GitLab’s minimum: 24 hours. Best practice: 72 hours. This gives team members in other time zones time to read the agenda and contribute input before the meeting, rather than learning what was decided after the fact.
5. Rotate meeting times. When some synchronous meetings are genuinely necessary, rotate their timing so that the “inconvenient” time zone slot rotates across the team rather than always landing on the same people.
6. Make Slack (or equivalent) explicitly async. Configure notification schedules. Establish team norms that prevent the implicit expectation of real-time response. Zapier and GitLab both operate Slack as an async tool — you are not expected to respond immediately.
Common Mistakes
Labeling something “remote” when the power center is colocated. If all senior leadership is in one time zone and employees in other time zones are perpetually waiting for direction, the org is functionally colocated with remote execution staff. This is not cross-time-zone collaboration — it is time-zone-based hierarchy.
Using “we are async” to avoid designing overlap windows. Some real-time interaction is legitimate and valuable. Teams that eliminate all synchronous touchpoints in the name of async purism often find that async communication breaks down at the edges of complexity. The goal is not zero meetings — it is meetings only when they produce better outcomes than writing.
Designing processes for the majority time zone. All-hands at 10am Pacific. Team meetings at noon Eastern. OKR reviews at 3pm CET. Each of these choices is neutral for one cluster and penalizing for everyone else. Design processes that work for everyone by default, not processes that are good for the majority and accommodated for the rest.
Not building the documentation infrastructure that makes handoffs work. Cross-time-zone coordination requires that work transferred between time zones comes with enough context for the recipient to continue without a briefing. This is a documentation discipline. Companies that do not invest in it find that cross-time-zone handoffs produce rework, misunderstandings, and delays that offset the timezone coverage benefit.
Sources
- 37signals Handbook: How We Work: https://basecamp.com/handbook/how-we-work
- The 37signals Guide to Internal Communication: https://basecamp.com/guides/how-we-communicate
- GitLab: How to Embrace Async Communication: https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous
- GitLab: All-Remote Meetings: https://handbook.gitlab.com/handbook/company/culture/all-remote/meetings
- Buffer is Remote but not Async-First: https://buffer.com/resources/remote-not-async-first/
- Wade Foster on Working Async (Zapier): https://remote.com/blog/remote-work/remote-talks-episode-5-wade-foster
Inferences
- The most common cross-time-zone failure is not a communication failure — it is a power structure failure. When decision-makers are concentrated in one or two time zones, the “distributed” label describes where people live, not where authority lives. Async communication tools allow employees in other time zones to contribute work; they do not automatically give them voice in decisions made at 2pm San Francisco time.
- The handoff model — work flows to whoever is awake, documentation transfers context — requires much more disciplined writing than most companies are prepared for. The productivity gain from 24-hour organizational coverage is only realized when documentation quality is high enough that the incoming person can actually continue the work. Low documentation quality turns timezone distribution from an advantage into a bottleneck.
Work with Alex
If your distributed team’s “global” coverage mostly means some people consistently work odd hours to stay in sync with the rest, Alex helps leadership teams build the coordination systems that make time-zone diversity a genuine advantage.