See how Alex worksWork with Alex
All practices

Practice — Communication

Cross-Time-Zone Collaboration: How Distributed Companies Work Across the Clock

Cross-time-zone collaboration is the set of practices that allow distributed teams to coordinate effectively when team members are 6, 10, or 16 hours apart. Companies that do it well have moved beyond 'overlap hours' as the primary mechanism and built async-first systems with intentional synchronous touchpoints.

By Alex Karasyov — Operating consultant for product & engineering teams

Last reviewed November 1, 2026

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: teammates in San Francisco, London, and Singapore have substantial time-zone gaps that vary with daylight saving time. If routine coordination requires everyone to be online together, some participants may need to work outside their normal hours. [Inference — illustrative coordination problem, not a measured practice at every distributed company.]

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 can separate contribution from simultaneous attendance. [Inference — design implication.] Someone can leave context during their working day for a colleague to review later. Response deadlines and urgent dependencies still require explicit choices. (Source)

Shared context supports handoffs across time zones. Zapier’s async guide describes working in public so colleagues can find context without an immediate reply. [Inference — application guidance.] This can support handoffs, but geography alone does not establish a continuous 24-hour work cycle. (Source)

Async can reduce one source of participation cost. [Inference — design hypothesis, not a measured equity result.] Preserved context can let an offline colleague contribute later, provided the decision has not already closed. It does not by itself redistribute authority or eliminate inconvenient live work. (GitLab, Buffer)

Written context may help some contributors prepare. [Inference — accessibility hypothesis, not a measured comparison by language background.] Extra reading and drafting time can help a participant, while writing fluency, accessibility needs, and the task may favor another format. Evaluate the format with the people doing the work. (37signals, Buffer)

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.]

Plan intentional synchronous contact. [Inference — application guidance.] Define when a live discussion is valuable without making routine work depend on continuous overlap. GitLab describes both asynchronous handoffs and deliberate synchronous starts. (Source)

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.]

When availability and authority are concentrated. [Inference — coordination risk.] Map where decisions depend on a particular person being online. Location alone does not establish a power imbalance; the decision rights and response path matter. (Source)

Best Examples

37signals / Basecamp — Written visibility alongside occasional live collaboration. Its handbook does not specify a universal overlap-hours rule. It describes daily and weekly automatic prompts plus manual Kickoffs and Heartbeats; the daily prompt requires answers at least twice weekly. These mechanisms make context available without simultaneous responses. The same handbook retains live collaboration when async is inefficient. (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 asks meeting DRIs to prepare a shared agenda at least 72 hours in advance, explicitly exempts informal coffee chats, and treats non-essential attendance as optional. Its scheduling guidance considers regional time zones. These are published norms, not an audit that every meeting complies. (Source)

GitLab’s current communication guidance starts with async and also identifies reasons to meet, including strategy, disagreements, trust-building and context that is hard to express in writing. [Inference — a handoff needs usable context and a clear owner; being awake in another time zone does not automatically transfer authority.] (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)

The November 2023 account asks teammates to adjust hours when they are able and says standing or scheduled meetings can fall outside typical working hours. It also rejects always-on availability. This is a stated reciprocal expectation, not evidence that every inconvenient meeting is voluntary or evenly distributed. (Source)

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

[Inference — implementation questions from the cited cases, not validated response-time benchmarks.]

  1. Define response and escalation expectations. State what can wait until a colleague’s working day and how urgent work reaches an accountable person.
  2. Identify work that benefits from live discussion. Protect that interaction without making all routine work depend on overlap.
  3. Preserve participation before closure. For decisions with an available review window, leave time for offline colleagues to contribute; document urgent decisions and their rationale when that is impossible.
  4. Prepare shared agendas in advance. GitLab’s example asks meeting DRIs for 72 hours and exempts informal coffee chats.
  5. Inspect the distribution of inconvenient meeting times. Adjust timing when the same people repeatedly bear the cost.
  6. State channel expectations. Define which messages can wait and which signal a genuine live escalation.

(GitLab meetings, communication, Buffer, Zapier)

Common Mistakes

[Inference — failure modes to inspect, not measured frequencies or inevitable outcomes.]

  • Using location as a proxy for participation. Check whether an offline colleague can influence the decision before it closes.
  • Treating an async label as a scheduling policy. Make room for useful live contact and document its purpose.
  • Assigning recurring inconvenient hours to the same people. Review who bears that cost and whether another format would work.
  • Handing off without usable context. Include the current state, owner, open question, and next step.

(GitLab, Buffer, Zapier)

Sources

Additional direct references for this review:

Other retained links below include historical/background context; dated accounts do not establish a current universal policy.

  1. 37signals Handbook: How We Work: https://basecamp.com/handbook/how-we-work
  2. The 37signals Guide to Internal Communication: https://basecamp.com/guides/how-we-communicate
  3. GitLab: How to Embrace Async Communication: https://handbook.gitlab.com/handbook/communication/#asynchronous-communication
  4. GitLab: All-Remote Meetings: https://handbook.gitlab.com/handbook/company/culture/all-remote/meetings
  5. Buffer is Remote but not Async-First: https://buffer.com/resources/remote-not-async-first/
  6. Zapier — How to Work Asynchronously: https://zapier.com/blog/how-to-work-asynchronously

GitLab current communication guidance: https://handbook.gitlab.com/handbook/communication/

Inferences

  • Time-zone distribution does not itself distribute decision authority. Review who can contribute before a decision closes and who owns exceptions.
  • A handoff can extend work across schedules only when the next person has sufficient context, authority, and availability. The sources here do not demonstrate a general productivity gain from 24-hour coverage.

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.

asynccommunicationpracticeculture

Last reviewed November 1, 2026