Your 9 A.M. Standup Across Timezones Is Someone's 6 P.M.

Pick a time for your daily standup and you've made a choice you probably didn't mean to make. You've decided whose day it fits and whose day it interrupts.

On a team in one office, that choice is invisible. On a distributed team, it's the whole problem.

The math nobody runs

Say your team spans San Francisco, Berlin, and Bangalore. A 9 a.m. standup in San Francisco is 6 p.m. in Berlin and 9:30 p.m. in Bangalore.

Your Berlin engineer is closing her laptop. Your Bangalore lead is dialing in from the couch after putting his kids to bed. They'll attend. They're professionals. But look at what you actually get from them.

Their updates get thin. Someone at the end of a long day sums up eight hours of work in one sentence. Any blocker they raise lands at the exact moment they're about to go offline, so it sits for a full night before anyone who heard it can act. Meanwhile, your San Francisco engineers are reporting on a day that started twenty minutes ago. "Still getting into it" is an honest update. It isn't a useful one. So the meeting everyone attends produces updates nobody can use.

Moving the meeting moves the cost

The usual fix is to shift the time. Try 7 a.m. Pacific. Now Berlin is at 4 p.m. and Bangalore at 7:30 p.m. Better for them, worse for the people in California who now report before coffee.

Rotating the time sounds fair. In practice, everyone gets a bad slot on a schedule they have to remember, and attendance drops on whichever days hurt most.

Every version of this has the same flaw. It assumes the update has to happen at one moment for everyone to standup across time zones.

Ask a different question

Stop asking what time works for the team. Ask two separate questions instead.

When is each person's update most useful to write? For most people, that's the start of their own day, when the plan is fresh and yesterday is still clear. Some teams prefer the end of the day, when people know what actually got done. Pick one and hold it constant. What matters is that it runs on the writer's clock.

When is the team's update most useful to read? At the start of the reader's day. A manager in San Francisco wants the Berlin and Bangalore updates waiting when she logs on. The Bangalore lead wants to know what California shipped overnight.

Once you split writing from reading, the standup stops being a meeting. It becomes a handoff. Bangalore's update is Berlin's morning briefing. Berlin's update is San Francisco's. Nobody stays late. Nobody reports on a day that hasn't started.

Make blockers travel

The handoff model changes what a blocker is worth. In a meeting, a blocker is something you mention. In a handoff, it's a request someone in the next time zone can pick up before you're back.

That only works if people write blockers for a reader who wasn't there. "Waiting on API access" tells the next person nothing. "Need write access to the billing API from anyone with admin, blocking the invoice export" gets solved overnight.

Add one question to your standup to force this: "Is there anything someone in another time zone needs to do before you're back?" It turns a status report into a relay.

What a good handoff update looks like

Most async updates fail the same way. They're written for the writer. "Worked on the export. More tomorrow." That's a note to yourself, and it's useless to someone reading it eight hours later with no context.

A handoff update is written for the next person to log on. Here's the same day, rewritten:

Yesterday: Finished the CSV export for invoices. It handles up to 10,000 rows. Larger files time out, and I haven't found why yet. Today: Tracing the timeout. I suspect the query rather than the file write. Blocker: Need write access to the billing API from anyone with admin. Without it I can't test against real data.

The reader knows where the work stands without asking, and they know exactly what they can do to help before you're back. It takes an extra minute to write. It saves the reader from sending you a question and waiting a full day for the answer.

What about the face time?

The strongest objection to dropping the meeting is that people like seeing each other. That's fair. On a lot of distributed teams, the daily standup is the only time some teammates hear each other's voices all week.

But a status meeting is a poor place to build that. Everyone is performing progress while the clock runs, and the person on the late shift is counting the minutes until they can log off. You get fifteen minutes of faces and very little connection.

Keep the face time and give it its own slot. Hold one call a week and ban status updates from it. Rotating a weekly call is far easier than rotating a daily one, and people show up to talk about the work instead of reporting on it. The daily handoff carries the status, so the call doesn't have to.

Standup Across Time Zones

Async standups fail quietly. Nobody complains, so the first sign of trouble is usually a blocker that sat for three days.

The most common failure is a report nobody reads. The updates keep coming and the summary keeps landing in the channel, but it turns into wallpaper. Fix this by making reading someone's job. Whoever owns the sprint should reply to at least one update a day. People write better updates when they know someone answers.

The other failure is blockers with no owner. A blocker posted to a channel of twenty people is a blocker nobody picks up. Name the person or role who can clear it, even if you're guessing. A wrong name gets redirected. No name gets ignored.

If updates start repeating word for word from one day to the next, your questions have gone stale. Swap one out for something that can't be answered on autopilot, like "What took longer than you expected?"

Setting this up in Alice

Standup Alice handles this pattern directly. It reminds each participant and collects their update in their own time zone, so a 9 a.m. reminder means 9 a.m. for whoever receives it. You can customize the question set for each standup, which is where the blocker question above goes. The combined report lands in your channel or inbox on the schedule you set.

Start with one team.

Keep the same questions for two weeks. Then read the blockers section and count how many got cleared before their owner came back online.

That number is your case for dropping the meeting.