← Back to app · Blog

Running standups across time zones

· TimeZoneMeet editorial team

The daily standup is the smallest synchronous ritual most teams have. Fifteen minutes, every day, where each person says what they did, what they will do, and what is in their way. It is also the ritual that breaks first when a team becomes time-zone-distributed. The 15-minute slot that worked in one office becomes 5am for someone, then becomes optional for that person, then becomes a meeting that half the team has stopped attending. By the time a manager notices, the standup has stopped doing what it was meant to do for at least three months.

This post walks through the three viable options for distributed standups and what each one costs. The right answer depends on the geometry of the team — specifically how many time zones it spans and where they are — so we will cover all three rather than recommend one.

What a standup is actually for

Before picking a format, it helps to be honest about the function. The classic standup has three stated purposes: surface blockers early, share status across the team, and create daily lightweight accountability. In practice, only the first one is worth the cost of a synchronous meeting. Status sharing is better served by written updates that are read at each person's convenience. Accountability comes from delivery patterns over weeks, not from showing up to a 9am call. So the surviving function is "surface blockers early" — and the format you pick should be the cheapest one that does that.

Option 1: Synchronous standup with a rotating slot

If your team spans up to about six hours of clock time, a single synchronous standup can still work. The trick is to rotate the slot so that no single region permanently absorbs an inconvenient hour. A common pattern: the standup happens at a time that is end-of-day for one zone and start-of-day for another, alternating weekly so that each side gets the worse slot half the time.

Example for a US ↔ Western Europe team: week 1 holds standup at 17:00 CET / 08:00 PT — late-afternoon for Europe, mid-morning for the US East, early for the US West. Week 2 swaps to 17:30 CET / 08:30 PT, which adjusts when needed for DST. The rotation is between two slots, not many; complexity kills the discipline. Document the cadence prominently in the meeting description.

Beyond about six hours of spread, the rotation does not save it. A SF ↔ Berlin team has nine hours of spread; a SF ↔ Bengaluru team has 12.5. There is no synchronous slot that is fair, and rotating between unfair slots just spreads the unfairness. Move to one of the other options below.

Option 2: Regional standups plus a weekly cross-region bridge

For teams that span more than six hours, the next option is to split the daily standup by region — each region runs its own 15-minute call inside its working hours — and add a weekly cross-region bridge meeting where the regions actually talk to each other.

This works well for teams that are organized regionally to begin with: an engineering team where the SF squad and the Bengaluru squad are working on related but separable workstreams. The daily standup focuses on the day's work within the region; the weekly bridge focuses on dependencies, alignment, and the things that are genuinely shared.

The weekly bridge needs careful scheduling. It must be at a time that fits both regions' working hours, which means an early-morning slot for one and a late-afternoon slot for the other. Use the Schedule tool to find candidate windows; for popular city pairs, the examples reference covers the typical answers.

Where this option fails: when the regions are not actually separable. If the SF and Bengaluru engineers are working in the same codebase on the same features, splitting the standup by region produces two daily reports that nobody on the other side reads. That is just hidden synchronous coupling — moving the meeting did not move the dependencies.

Option 3: Fully async standup

The third option is to drop the live meeting entirely and make the standup a written ritual. Each person posts a structured update in a shared channel during their working day. Other team members read the updates during their own working day. There is no live ceremony.

The format that works is short and rigid. We use this template:

**Yesterday**
- One bullet per concrete thing shipped or progressed

**Today**
- One bullet per concrete thing planned

**Blocked**
- Anything in someone else's hands. Tag them.

Three sections, bulleted, no prose. If you are tempted to write a paragraph, the standup is not the right place — open a thread, a doc, or a DM with the relevant person. Most people's standup updates fit in five lines. Updates that take more than ten lines are a signal to break out a separate document.

The blockers section is the one that matters. Tag the person who can unblock you with an explicit ask. The team's response-time SLA (covered in our async-work patterns post) determines how long the unblocker has to respond. Without a tagged ask and an SLA, the blocker section becomes a list of grievances rather than a request for help.

Tooling

The most common tools for async standups are Geekbot, Standup Bot for Slack, Polly, Range, and Friday. They all do roughly the same thing: prompt each team member at a configurable time, collect the response, post a digest to a channel. The differentiation between them is small — pick whichever integrates with your existing chat.

The minimum-viable version is a plain Slack channel called #standup with a pinned template message. No bot, no tooling, no integration. People post their updates when they start their working day. The cost of the bot is that it locks in a specific time of day; the benefit is that it ensures consistency. For teams under 20 people, the plain channel is usually enough.

The blocker resolution gap

Async standups have one well-known failure mode: the lag between posting a blocker and getting unblocked. If you post your blocker at 09:00 IST and your unblocker is in San Francisco where it is 21:30 PT the previous calendar day, the unblocker may not see the message until the next morning their time — which is potentially 18 hours later. Your day is gone.

The fix is two-part. First, name the blocker in the previous day's update if you can predict it. "I'll be blocked on the schema review tomorrow morning IST" gives the unblocker a chance to handle it before they sign off. Second, use the urgency-tagged DM pattern from the async-work patterns post for genuinely urgent unblocks: a [!]-tagged DM that gets the response-time treatment.

Some categories of work are inherently sensitive to this lag — anything where iteration cycles are bottlenecked on cross-region review. For those workstreams, async standups alone are not enough. The team needs an explicit handoff protocol (covered in our follow-the-sun guide) or it needs to restructure who is doing the work so that the bottleneck is intra-region.

When to drop the standup entirely

For some teams, the standup is not worth the cost in any format. Signs that you are in this state:

If two or three of these are true, the standup has stopped functioning. Replace it with a weekly written team update — fewer cycles, more substance — and surface blockers through the explicit channels you would use anyway. The empty ritual is worse than no ritual; it consumes attention without producing value.

Choosing between the three options

Team geometry Recommended format
Single zone or up to ~3-hour spread Standard daily synchronous standup, no rotation needed.
3 to 6 hours of spread (US coast-to-coast, US ↔ UK) Synchronous standup with weekly slot rotation if needed.
6 to 10 hours of spread (US ↔ Western Europe, US ↔ Israel) Regional standups plus weekly cross-region bridge, OR fully async.
More than 10 hours (US ↔ India, US ↔ APAC, four-region) Fully async with explicit blocker-resolution protocol.

Further reading

← All posts