Skip to content

classical-argument vs problem-solution

Topic: Should we adopt async-first standups?
Axis varied: style
A: Classical Argument B: Problem-Solution

Both examples address the same topic and (by default) share every axis other than style. The only deliberate variable is which style the writing was rendered through. Read both and ask: where does the framing change? Where does the vocabulary change? What does the reader take away from A that they would not take away from B, and vice versa? The style swap is the entire cause of those differences.

A: classical-argument

Distributed teams should replace synchronous daily standups with async standup updates. The synchronous format was designed for co-located teams and imposes costs that distributed teams bear unevenly, while delivering most of its value in a form that does not require shared presence.

The grounds

The primary purpose of a daily standup is status visibility: making blockers known, making progress visible, and surfacing coordination needs before they become delays. A survey of engineering teams at GitLab, where async-first work is documented extensively, found that async standup formats reduced blocker-to-resolution time compared to synchronous equivalents - not because the meetings were bad, but because async channels produce written records that route information to the right person directly, independent of who attended a meeting.

The secondary cost of synchronous standups in distributed teams is timezone asymmetry. In a team spread across four timezones, the meeting time is convenient for some and inconvenient for others. The inconvenience is not random - it concentrates on the engineers whose location is furthest from the timezone anchor of the rest of the team. Over a year, an engineer joining standups at 9pm local time has absorbed hundreds of hours of scheduling friction that their co-located colleagues have not.

The warrant

This evidence supports the claim because the value of status visibility is in the information being accessible, not in the information being spoken aloud at a shared moment. If information in a Slack channel is as accessible as information spoken in a meeting - and for distributed teams it is more accessible, because it is persistent and searchable - then the synchronous meeting is adding no incremental value over the async format while still imposing the timezone cost.

The rebuttal

One might object that synchronous standups build social cohesion that async formats cannot replicate, and that cohesion has downstream effects on collaboration quality. This objection is correct. Shared presence does create connection that text in a channel does not. The response is that this function can be addressed through a different format - a weekly synchronous working session - rather than preserved in a daily status meeting that is a poor vehicle for social bonding. Retaining the daily synchronous standup for its cohesion value is the wrong tool for the job it is being asked to do.

Distributed teams should move to async standup formats and invest the recovered synchronous time in working sessions that can actually build the relationships that standups were never designed to build.

B: problem-solution

The team’s daily standup runs at 9am Pacific. Three of the team’s eleven engineers are based in India (UTC+5:30), which puts the meeting at 9:30pm their local time. On any given week, at least one of those engineers misses the call because of a conflict with evening life. When they miss it, they do not get the context shared in the meeting - including blockers that affect their work.

The problem is not just timezone fairness. The meeting’s information does not persist. When @priya mentions in the standup that the auth service is throwing a 401 on a specific endpoint, that information lives in a 14-minute Zoom recording that nobody will watch. The engineer who hits that same 401 at 2pm does not know Priya already diagnosed it. They spend 45 minutes retracing the same path.

The synchronous standup was designed for co-located teams. It assumes everyone can occupy the same time slot without cost, and that verbal delivery is sufficient for information sharing. Neither assumption holds for this team.

Replace the synchronous standup with a structured async update in #team-standup. Each engineer posts by 10am their local time, answering three questions: what shipped in the last 24 hours, what is in progress today, and what is blocked or at risk. Any blocked item must @mention the specific person who can unblock it.

The channel becomes the single searchable record of daily status. When an engineer hits a 401 at 2pm, they search the channel and find that Priya posted the fix at 8am India time.

Blocked items are resolved faster because the @mention reaches the right person directly, rather than relying on that person happening to attend the meeting and remember.

The synchronous meeting is replaced by a 60-minute working session on Thursdays, reserved for discussion that genuinely requires real-time exchange.

After 30 days: review blocker resolution time, channel engagement rate, and a team survey. Extend or revert based on data.