direct-communicator vs operator

Topic: Should we adopt async-first standups?
Axis varied: voice
A: Direct Communicator B: Operator

What to notice

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

A: direct-communicator

I think we should try the async format for 30 days.

Here is why. The 9am Pacific standup is 9:30pm for the three engineers in India. Their Q1 attendance was 3.2 out of 5. The US-based engineers averaged 4.6. That is not a coincidence and it is not their fault. We built a meeting that punishes a third of the team for living where they live.

The meeting also does not earn its time. Fourteen minutes per day, eleven people, and roughly four minutes of that drives any action. The rest is status that could be read. We also lose what gets said. Priya diagnosed a 401 in standup last month. Five hours later, someone else hit the same error and spent 45 minutes re-diagnosing it because the original answer lived in a Zoom call no one could search. A Slack post would have fixed that.

The proposal is simple. Each engineer posts in #team-standup by 10am local time. Three fields: shipped, in progress, blocked or at risk. Blockers @mention the person who can unblock. The old 9am slot becomes a 60-minute Thursday working session - not a status meeting, an actual working session with an agenda.

I want to be straight about the tradeoff. We lose the daily check-in. For some teams that matters, and I do not want to pretend otherwise. The Thursday session is meant to carry the connection load that the daily call was carrying, but it is one session, not five. If after 30 days the team feels disconnected or things are slipping, we go back. The revert is a one-line message in Slack. Nothing about this is permanent.

What I am asking: run it for 30 days starting Monday. At day 30 we look at three things - India attendance and participation, blocker response time, and how people say it is going. Then we decide.

If you have concerns or this is a bad idea for a reason I am missing, tell me before Friday. After that I am going to set it up.

B: operator

Here is what happens at 9am on a bad standup day. Three engineers have been working since 7am. Two engineers are on the west coast and join 10 minutes late. The engineer on-call from last night’s incident is barely conscious. Someone starts talking about their PR. Nobody asks about the deploy that broke the staging environment at 8:45. The meeting ends at 9:17. At 9:30, @sam pings @alex to ask if the staging issue is known. It was. Nobody said so.

That is not an edge case. That is Tuesday.

The coordination failure is not that standups are bad. It is that synchronous standups do not wait for the right people to be present, and they do not persist the information in a findable place. The on-call handoff note from 8am is in a Slack thread. The PR status is in GitHub. The staging issue is in someone’s head. The standup adds a fourth place where information lives, briefly, before evaporating.

Async standup in Slack fixes the evaporation problem. The update is there. @prasad posted at 8:15 India time that the deploy is blocked on a config change. @sam reads it at 9am Pacific and responds in thread. The blocker is resolved before the standup would have even started.

The setup: post to #team-standup by 10am local. Three fields - shipped, in progress, blocked. Anything blocked requires a @mention of the person who can unblock it. On-call reads the channel daily by 9am Pacific and responds to blocked items within 30 minutes.

What this does not fix: people who do not read the channel. You still need someone to own that. Set a reminder in the channel. Make it a team norm. Check the receipts.