Skip to content
Writing Style Library

confident vs matter-of-fact

Topic: Should we adopt async-first standups?
Axis varied: tone
A: Confident B: Matter of Fact

What to notice

Section titled “What to notice”

Both examples address the same topic and (by default) share every axis other than tone. The only deliberate variable is which tone 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 tone swap is the entire cause of those differences.

A: confident

Async standups are the right call for this team. The math forces it.

We have eleven engineers across four timezones. Our standup at 9am Pacific lands at 9:30pm in India, and our India engineers attend 3.2 times out of 5 because they have families and lives and 9:30pm is not a fair ask. We have been doing this for months. The pattern is not going to change by itself.

The 14-minute standup with 4 minutes of signal is also not a coincidence. Sync standups optimize for the speaker’s convenience over the listener’s, and they convert status into a performance instead of a record. When status does not persist, every cross-timezone handoff costs us a second conversation. We pay that cost every day.

The proposal is well-shaped. Three fields - Shipped, In progress, Blocked-or-at-risk - is enough structure to make the updates scannable without turning them into paperwork. Posting by 10am local means each timezone writes during their own peak, which is when status is most accurate. Blockers @-mentioned means urgency still has a channel. And reclaiming the slot for a 60-minute Thursday working session gives us back something the current standup was pretending to be: a real coordination point.

There is one thing I want to be clear about. Async standups are not just a kinder version of what we have. They are a different operating mode. The team will lose some incidental conversation, and people who like meetings will feel that loss. That is a fair cost, and it is smaller than the cost of asking three engineers to log on at 9:30pm.

Thirty days is enough to learn whether the team adopts the rhythm. We do not need to debate it further. Let us run it.

B: matter-of-fact

Proposal: Transition to Async-First Standup Format

The team currently holds a daily synchronous standup at 9am Pacific. Attendance has averaged 8 of 11 engineers over the past quarter. The three engineers who miss most frequently are in the UTC+5 timezone, where 9am Pacific is 9:30pm local. The meeting runs an average of 14 minutes.

The proposal is to replace the synchronous standup with a structured async update posted to #team-standup by 10am each engineer’s local time. The format uses three fields: what shipped in the last 24 hours, what is in progress today, and what is blocked or at risk. Blocked items must include a @mention of the person who can resolve the block.

The on-call engineer reads the channel by 9am Pacific each day and responds to blocked items within 30 minutes during business hours.

The synchronous meeting would be replaced with a weekly 60-minute working session on Thursdays. That session is not a status meeting - it is reserved for topics that require real-time discussion.

Expected outcomes:

  • All engineers participate on a schedule that fits their timezone
  • Blockers reach the relevant person with a direct mention rather than relying on meeting attendance
  • Status information is persistent and searchable rather than spoken and lost

Risks:

  • Engineers who do not read the channel regularly will miss updates
  • The format requires consistent participation to be useful - if three people stop posting, the value drops for everyone

Next step: Trial period of 30 days starting the week of May 19. Review at 30 days with a team survey and a look at blocker resolution time before and after.