Skip to content

Status Report

A periodic async update covering progress since the last report, what is next, and what is blocked - the working unit of distributed-team visibility.

A status report is a periodic written update, typically weekly or biweekly, that answers three questions: what got done, what is next, and what is blocked. It is written async, read async, and exists to give a distributed team or external stakeholder enough visibility to stay aligned without a meeting. The Blocked section is the most important; a status report that does not name what is stuck is performing alignment rather than producing it.

# Status Report - [Project/Workstream Name]
**Period:** [Date range]
**Author:** [Name]
**Status:** [Green | Yellow | Red]
## Headline
[One or two sentences summarizing the state of the work.]
## Done this period
- [Outcome, not activity]
- [Outcome, with link to artifact where useful]
## Up next
- [Specific deliverable with a target date]
## Blocked / risks
- [What is stuck, what is needed to unblock, who can help]
## Asks
- [Specific request of the reader, if any]

Use a status report for weekly or biweekly team updates in distributed organizations, consulting engagement updates to a client, or workstream-lead reporting up to a program manager. It is the working unit of async visibility on long-running work.

Do not use this format for a daily standup (smaller scope, less detail - use daily-standup). Do not use it to document a discussion that happened in a meeting (use meeting-notes). Do not use it for one-off announcements.

direct-communicator, operator, matter-of-fact, executive

meeting-notes: Meeting notes capture a discussion that happened synchronously; they are organized by topic and reflect what was said. A status report is written async, with no meeting required; it is organized by done/next/blocked and reflects the state of the work itself.

daily-standup: A daily standup covers yesterday and today in a sentence or two and is read in seconds. A status report covers a longer window (a week or more) with enough detail to be useful to someone outside the day-to-day. Same shape (done/next/blocked), different scope.

Write a status report covering a defined period (typically a week). Open with a single-sentence
headline that lets the reader stop reading if they only have ten seconds. Use the three-section
structure: Done this period, Up next, Blocked. Write outcomes, not activity - "shipped X to
users" not "worked on X". Be specific about dates and owners. The Blocked section is the most
important: if nothing is blocked, say so explicitly. End with an Asks section if there is
something specific you need from the reader. Use matter-of-fact tone and resist the urge to
perform progress; the reader needs the truth, not a sales pitch.

See the Status Report template.

Direct Communicator, Operator, Matter of Fact, Executive

Storyteller, Pastoral

Meeting Notes, Daily Standup

Async standup trial - Week 2 status report

Section titled “Async standup trial - Week 2 status report”

Period: Days 8 to 14 of the 30-day trial Author: Engineering manager Audience: Director of engineering, team, peer EMs

The trial is on track. Participation is up, blockers are getting resolved faster than under the sync model, and India engineers are now contributing every weekday for the first time in this team’s history. Two friction points have surfaced and are tracked below.

  • Post completion: 47 of 55 expected posts arrived by the 10am local cutoff. That is 85.5 percent on-time, up from 78 percent in Week 1.
  • Blocker resolution: Median time from @mention to first substantive reply was 18 minutes. P90 was 2 hours 40 minutes. Compare to the sync standup baseline, where blockers raised at 9am often did not get a real conversation until the afternoon.
  • India participation: All 4 IST-based engineers posted every weekday this week. Under the sync model this group attended 3.2 out of 5 standups on average.
  • Time recovered: With the sync standup gone, the team got back approximately 16 person-hours this week. The Thursday working session used 11 of those. Net recovery: 5 person-hours.
  • Run the Week 3 cycle without process changes. Holding the design stable so the retro data is comparable.
  • Pull the first qualitative signal: 10-minute 1:1 with each engineer Thursday and Friday. One question only: “What do you want to keep, change, or kill after the trial?”
  • Prep the retro deck for the Day 30 review. Skeleton landing in docs/trial-retro.md by EOD Tuesday.
  • At risk: async posts trending long. Three engineers are writing 200+ word posts. The format is meant to be skimmed in under 60 seconds per teammate. Plan: share two exemplar posts in the channel pinned message and demo the three-bullet ceiling at the Thursday session.
  • At risk: on-call triage load. The on-call engineer this week spent roughly 25 minutes per morning on #team-standup triage, higher than the 10 minute target. Likely cause: blockers are surfacing earlier and louder than they did in sync. Watching this for one more week before deciding if the on-call role needs to be split.
  • None this week.

Week 3 status report will land in #team-standup and via email by EOD next Monday.