Daily Standup
A brief daily status communication with three fixed sections - done, next, blockers. Surfaces information and flags what needs action. Not a progress report; a coordination tool.
Daily Standup
Section titled “Daily Standup”The daily standup is a coordination format, not a status report. The distinction matters. A status report demonstrates effort; a standup surfaces information that allows a team to respond. The three sections - what was done, what is next, what is blocking - are not prompts for comprehensive updates. They are prompts for the minimum information a team needs to know whether to act. Done and next are information; blockers are the only part that demands a response.
The failure mode of the standup is treating it as an opportunity to demonstrate productivity. Long “done” sections, vague “next” sections, and absent blocker sections indicate the writer is performing effort rather than coordinating work. A well-written standup is short. The done section names completed items without narrating them. The next section names the next task, not a plan. The blocker section is either empty or states specifically what is blocked and what resolution would look like.
Standup format works for both synchronous (spoken in a meeting) and asynchronous (written in a Slack channel or doc) contexts. The written async standup has the same structure but gains the additional obligation of being self-contained: the reader cannot ask a follow-up question in real time. Every blocker in an async standup should name what the writer needs, from whom, and with what urgency.
Canonical template
Section titled “Canonical template”**Done**- [Completed item - one line each]
**Next**- [Next task or focus - one line each]
**Blockers**- [What is blocked, what is needed, from whom - or "None"]When to use
Section titled “When to use”The standup format belongs in daily team coordination - sprints, weekly goal cycles, or any rhythm where a team needs to know who is moving and where things are stuck. It works in synchronous stand-up meetings and in async Slack channels. The format is especially valuable when blockers need to surface reliably so the right person can respond without needing to ask for status.
When not to use
Section titled “When not to use”Skip the standup format when the situation calls for context or narrative - end-of-sprint summaries, milestone updates, or communication with stakeholders who need to understand the work, not just the status. If the recipient cannot use the three-section structure to know whether to act, a different format serves better.
Pairs well with
Section titled “Pairs well with”operator, direct-communicator, matter-of-fact, candid
Often confused with
Section titled “Often confused with”meeting-notes: Meeting notes capture the full outcomes of a specific meeting - decisions, assigned actions, open items - across any topic. A standup is a recurring short-form personal status update with a fixed three-section structure focused on coordination.
slack-message: A Slack message is a general-purpose channel communication that can take many forms and lengths. A standup is a specific format with a fixed three-part structure - it often lives in Slack, but the format constraint is tighter than the Slack message format allows for.
Instruction
Section titled “Instruction”Write as a daily standup update. Use exactly three sections: Done, Next, Blockers. Eachsection uses short bullet points, one item per line. Done covers completed work - name theitem, do not narrate it. Next covers the immediate next task or focus. Blockers states whatis blocked, what resolution is needed, and from whom - or the word "None" if there are noblockers. The entire update should fit in 10 lines or fewer. Do not include progress narratives,explanations of effort, or general context not needed for coordination.Template
Section titled “Template”See the Daily Standup template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Operator, Direct Communicator, Matter of Fact, Candid
Avoid with
Section titled “Avoid with”Pastoral, Columnist, Devotional Reflection, Warm
Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”#team-standup - Devon Park - Tue May 27, 9:42am PT (day 9 of trial)
Shipped
- Rate-limiter rollout to staging; 0 errors over 18h soak
- PR #4412 merged (auth token rotation runbook)
In progress
- Production rollout of rate-limiter, gated behind
rl_v2flag, 5% traffic by EOD - Pairing with Aditi 10am PT on the IST-hour metrics dashboard
Blocked / at risk
- Waiting on @sara for sign-off on the rotation runbook before I close the parent ticket (not urgent, EOW is fine)
- (meta) Async format participation was 9/11 yesterday - @oliver and @emma did not post. Oliver was on-call handoff, fine. Emma I will DM. Flagging so @maya has visibility before the day-15 pulse.
Standup - Wed 2026-05-14
Shipped:
- Closed out the Q2 metrics review doc, sent to Priya for sign-off
- Cleared the API deprecation tickets (3 of 3)
- Hit day 26 of the no-phone-first-hour experiment - first time I made it through a travel day without breaking the rule
In progress:
- Reviewing the onboarding flow proposal, comments back by EOD
- New morning routine variant for travel days (water + 5 min planning only); testing tomorrow on the SF trip
- Drafting talking points for Thursday’s 1:1 with Dana
Blocked:
- Waiting on legal for the partner agreement redlines, pinged again this morning
- Cannot finalize Sunday planning block until I find a second notebook that does not slide off the kitchen counter (low priority, self-imposed)
Standup - Ana, 2026-05-14
Section titled “Standup - Ana, 2026-05-14”Done
- Wrote up the operational-capacity case for Postgres ahead of yesterday’s 2pm architecture meeting
- Walked Marcus through the on-call cost model; he agrees the framing is fair
- Posted the draft decision to #notify-arch for the wider team to react to before Friday
Next
- Finalize ADR-0023 (Postgres for notification service) for review today
- Spec out the
notification_jobsschema andpg_notifylistener for the Friday sprint plan - 30-min sync with Priya at 11am to confirm the decision is locked for sprint planning
Blockers
- Need Marcus to sign off on the 5M events/day revisit threshold in the ADR before I mark it Accepted. Asked in #notify-arch; if no response by 3pm I will DM him directly. Priya needs the decision locked by EOD Friday so we do not slip the sprint.