How async standups actually work across a 10+ hour time gap

A live daily standup is a strange ritual to try to preserve when a client team and our team are separated by ten or more hours. We replaced it early on with an async format that actually fits how the day really unfolds across that gap, rather than forcing a live meeting neither side can consistently attend without someone being inconvenienced.

Each project lead posts a short written update at the end of their working day: what got done, what's next, and anything blocking progress. It's deliberately short, three or four sentences, written to be read in under a minute by someone starting their day on the other side of the gap, rather than a long-form report that takes real time to parse.

Anything blocking progress is called out at the top of the update, not mentioned in passing at the bottom. The whole point of async standups is that someone reads this once, at the start of their day, and needs to immediately know if something requires their input before work can continue on their side of the project.

Async updates handle status; they don't handle a genuinely complicated decision that benefits from back-and-forth discussion. We keep one weekly live call, scheduled at a time that's reasonable for both sides, specifically for those conversations, rather than trying to force every discussion into writing where nuance and tone are easy to lose.

Updates posted in a channel that also fills with unrelated chatter tend to get missed. We keep project updates in a dedicated thread or board separate from general conversation, which sounds minor but noticeably improved how consistently clients actually engaged with daily updates once we made the change.

We don't require a substantive update every single day if there's genuinely nothing new, a brief "no change since yesterday, still working on X" is a complete and acceptable update. Forcing padded updates just to fill the format trains people to stop reading them carefully, which defeats the entire purpose.

Async daily updates aren't meant to handle something urgent that can't wait until the next update cycle. For genuinely time-sensitive issues, we use a separate, explicitly flagged channel that both sides know to check outside the normal daily rhythm, so urgency doesn't get lost inside a routine status post.

For one client with an unusually large time gap, nearly twelve hours, we eventually added a short overlap window, a couple of hours where both sides deliberately kept flexible availability, specifically for the handful of conversations each week that genuinely needed real-time back and forth rather than async handling.

It would be easy to bolt on more elaborate project management tooling to formalize this further, but we've found a simple, consistently used written update beats a more sophisticated system that people engage with less consistently. Simplicity that's actually used beats sophistication that gets ignored.

India and a client's home country rarely share the same public holiday calendar. We maintain a shared calendar flagging holidays on both sides in advance, so an update gap doesn't get mistaken for a missed update or a stalled project when it's simply a scheduled day off on one side.

During a launch week or a particularly complex integration phase, we sometimes temporarily increase update frequency to twice daily for a short, defined period, then explicitly step back down to the normal daily cadence once that intense phase passes, rather than letting an elevated pace become the unstated new normal indefinitely.

The biggest mistake we made early on was over-engineering the format before we'd actually tested a simple version. We initially built a more elaborate structured template with six or seven fields to fill out daily, which nobody actually kept up with consistently. The simple three-question version that replaced it succeeded specifically because it was easy enough to genuinely do every single day without feeling like a chore.

The second lesson was that the discipline of actually reading every update, not just posting your own, matters as much as the posting itself. We hold project leads accountable for demonstrating they've read the other side's update, referencing it in their own next post, rather than two parties posting past each other without genuinely engaging with what the other side wrote.

Any team considering this kind of async structure across a large time gap should expect the first two or three weeks to feel awkward and underused before it becomes a genuine habit. That adjustment period is normal, not a sign the format isn't working, and pushing through it rather than abandoning the practice early is usually what determines whether it actually sticks.

We also periodically ask clients directly, usually a few weeks into a new engagement, whether the async format is genuinely working for them or whether they'd prefer more real-time contact, since some client team members simply have a stronger personal preference for live conversation regardless of how well the async system objectively performs on paper. We'll adjust the specific communication mix per client relationship within reason, treating the standard async format as a strong, well-tested default rather than a rigid, one-size-fits-all requirement imposed regardless of individual preference.

A new hire or a new client stakeholder joining an already-established async relationship doesn't automatically understand the unwritten norms around tone, length, and what counts as urgent enough to flag outside the normal cycle. We walk every new participant through a short written guide covering these specifics during their first week, rather than letting them learn the norms purely by trial and error, which tends to produce a rocky first few weeks of either over-communicating or under-communicating relative to what the rest of the team expects.

Video and voice updates have become more common in remote work generally, and we've tested them, but written updates remain our default because they're searchable, quick to skim, and easy to reference back to weeks later during a dispute about what was actually agreed. A video update might feel more personal, but it doesn't hold up nearly as well as a paper trail once a project spans many months.