For a few years my teams have spread across five time zones, from the US West Coast to Eastern Europe. There is no hour of the day when everyone is fresh, online and free. For a while we tried anyway. Someone joined the daily call at 7 AM, someone else at 6 PM, and a third person watched the recording at lunch and quietly stopped watching. The call technically happened every day. Accountability did not.
Earlier in my career, as a partner, I helped grow a software consulting company from about $6M to $60M in under three years, and later I founded and ran a fully remote consultancy. One of the most useful changes I made in that remote work was replacing the daily standup call with a written async standup. Not a vague "post updates in Slack" policy, but a small set of habits that make written updates as reliable as a meeting, and usually more useful.
Here is what that looks like in practice for an async standup remote team.
Why the Daily Call Breaks Across Time Zones
A standup has three jobs: surface blockers early, keep people aligned on priorities, and create light, visible accountability. Across five time zones, the call fails at all three.
Blockers wait until the next call, which may be 20 hours away for someone. Alignment depends on who managed to attend. And accountability becomes "I showed up" instead of "I moved the work forward." Meanwhile you are taxing the people in the earliest and latest time zones every single day. Over months, that tax shows up as fatigue and quiet resentment.
Written updates fix the timing problem, but only if you design them. Left alone, they drift into long status essays nobody reads, or one-line "working on stuff" posts that hide problems.
The Habits That Make Async Standups Work
1. One fixed format, short enough to write in five minutes. We use three prompts: what I finished since my last update, what I am doing next, and what is blocking me or at risk. Each answer links to the ticket, pull request or document. If an update takes longer than five minutes to write, the format is too heavy.
2. A posting window tied to each person's own morning. Everyone posts at the start of their own workday, not at a shared clock time. That way the update reflects real plans for the day ahead, and people in earlier time zones hand context to the people waking up after them. Think of it as a relay, not a roll call.
3. Blockers named with an owner and a time. "Blocked on API access" is not enough. "Blocked on staging API key, need it from the platform lead by my 2 PM" gives someone a clear action and a deadline. Vague blockers sit for days. Specific ones get cleared within hours.
4. Links over prose. A good update points to the work rather than describing it. The pull request, the failing build, the design comment. Readers can go as deep as they need, and the writer does not have to summarize everything.
5. One dedicated channel or thread per day. Updates live in one predictable place, threaded by date. Side conversations happen in replies. When someone joins late or comes back from leave, they can scroll a week of history in ten minutes.
6. Leads read and respond inside a set window. This is the habit that keeps accountability real. The team lead, or a rotating reader in each region, reads every update within a few working hours and replies to blockers, risks or anything that looks stuck. A written standup that nobody reads is worse than no standup, because people learn their words do not matter.
7. A visible "no update" signal. If someone has not posted by the end of their window, the lead checks in privately. Not as a punishment, but because silence across time zones is how small problems become missed deadlines. Most of the time the answer is "sick day" or "deep in a bug." Occasionally it is the early warning you needed.
Keeping Accountability Without Micromanaging
People worry that written standups feel like surveillance. In my experience they feel less intrusive than a daily call, as long as you keep the focus on work, not on hours.
Measure outcomes, not activity. The update says what moved and what is stuck. It does not say how many hours someone was online. Leads should respond to the substance, ask about risks and help clear the path.
Compare plans to results over the week. Once a week, skim each person's "next" items against what they later reported as "done." Patterns stand out quickly: work that is consistently underestimated, priorities that change too often, or someone quietly carrying too much. That is a coaching conversation, not a reprimand.
Make good updates visible. When someone writes a crisp update that flags a risk early, say so in the thread. Teams copy what gets noticed.
What Still Needs a Live Conversation
Async standups replace the daily status ritual. They do not replace every meeting. We still keep a short weekly call at the least painful overlap, rotating the inconvenient slot so the same region does not always pay. That call is for planning, demos and the human side of working together.
We also keep a simple rule: if a thread needs more than three back-and-forth replies to resolve a blocker, the people involved jump on a quick call, then post the outcome back in writing. That keeps async from turning into slow-motion arguments.
And for onboarding, incidents and hard feedback, synchronous time is worth the cost. Writing is great for status. It is not great for tension.
Getting Started Next Week
If you want to try this, do not redesign everything at once.
Pick the three-prompt format and pin a short example in the channel. Tell the team that for two weeks, the daily call is replaced by written updates posted at the start of each person's day. Assign a reader in each major time zone. Keep your weekly call. At the end of two weeks, ask the team what was missing and adjust one thing.
Most teams I have worked with do not go back. They get their mornings and evenings back, blockers surface sooner, and leads have a written record of how work actually moved. The daily call was never the point. Clear, visible, accountable progress was.
If your team is spread across time zones and you want help building async habits that keep delivery accountable, visit https://tdzpro.com.
Ashkan Rajaee is the founder of TDZ Pro. He founded and scaled a fully remote software consultancy.
Top comments (0)