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.
Status Report
Section titled “Status Report”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.
Canonical template
Section titled “Canonical template”# 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]When to use
Section titled “When to use”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.
When not to use
Section titled “When not to use”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.
Pairs well with
Section titled “Pairs well with”direct-communicator, operator, matter-of-fact, executive
Often confused with
Section titled “Often confused with”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.
Instruction
Section titled “Instruction”Write a status report covering a defined period (typically a week). Open with a single-sentenceheadline that lets the reader stop reading if they only have ten seconds. Use the three-sectionstructure: Done this period, Up next, Blocked. Write outcomes, not activity - "shipped X tousers" not "worked on X". Be specific about dates and owners. The Blocked section is the mostimportant: if nothing is blocked, say so explicitly. End with an Asks section if there issomething specific you need from the reader. Use matter-of-fact tone and resist the urge toperform progress; the reader needs the truth, not a sales pitch.Template
Section titled “Template”See the Status Report template.
Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Direct Communicator, Operator, Matter of Fact, Executive
Avoid with
Section titled “Avoid with”Often confused with
Section titled “Often confused with”Examples
Section titled “Examples”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
Headline
Section titled “Headline”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.
Progress this week
Section titled “Progress this week”- 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
@mentionto 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.
What is next
Section titled “What is next”- 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.mdby EOD Tuesday.
Blocked or at risk
Section titled “Blocked or at risk”- 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-standuptriage, 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.
Next report
Section titled “Next report”Week 3 status report will land in #team-standup and via email by EOD next Monday.
Morning routine - Month 1 status report
Section titled “Morning routine - Month 1 status report”Period: Days 1 to 30 of the v3.0 protocol Author: Me, to me, posted publicly in the repo Purpose: Honest accounting before I decide whether to keep going.
Headline
Section titled “Headline”Better than I expected, worse than I am sometimes tempted to claim. Completed 23 of 30 mornings against the full protocol. The phone-in-the-kitchen rule turned out to be the single highest-leverage change. The 6:15 wake held on 19 of 30 days, with travel and one bad cold accounting for most of the misses.
Progress this month
Section titled “Progress this month”- Completed mornings: 23 of 30 (76.7 percent). “Completed” means all four steps in order, no shortcuts.
- Wake time held at 6:15: 19 of 30 (63.3 percent). The 11 misses split into 3 travel days, 4 sick days, and 4 days I cannot explain except as drift.
- Phone deferred until step 4: 28 of 30 (93.3 percent). The two failures were both Mondays. There is a pattern there.
- Mood log: “Steady” was the most common one-word mood (14 days), followed by “tired” (7), “sharp” (6), “anxious” (3). Compare to my admittedly informal pre-protocol baseline where “tired” and “rushed” dominated.
What is working
Section titled “What is working”- Water and light, in that order, before anything else. The combination feels like a switch flipping. Movement and planning could be optional and the morning would still be better than v1.
- Paper planning. Writing the top three by hand has, surprisingly, made me close more days satisfied than any digital tool ever did.
- The phone-in-the-kitchen rule. Removing the device makes the first 30 minutes feel like time I own.
What is not working
Section titled “What is not working”- Tuesdays. Something about Monday’s leftover load makes Tuesday morning the hardest to start cleanly. Three of my four unexplained 6:15 misses were Tuesdays.
- Travel. The protocol assumes a familiar environment. Two of the three travel days I tried to adapt, both poorly. I need a travel variant rather than just “skip and resume.”
- Weekends. I keep wondering whether to run the protocol on weekends or relax it. Right now I am running it. The verdict is genuinely unclear.
What is next
Section titled “What is next”- Month 2 design. Keep the structure. Add a travel variant. Decide explicitly about weekends by writing the rule down, even if the rule is “same as weekdays.”
- Tuesday experiment. Sunday evening planning session (15 minutes) for the week ahead. Hypothesis: Tuesday is hard because Monday consumed all the buffer.
- One subtraction. I will try removing the 10-minute light step for one week, just to see what it costs. If the cost is real, the step earns its place.
Blocked or at risk
Section titled “Blocked or at risk”- At risk: the 90-day version. I tried this before at 90 days and quit on day 11. The 30-day frame worked. I do not yet trust myself to extend without a checkpoint.
- Watching: family friction. Family has tolerated the new wake time, but I have not asked directly whether the silent first hour is actually fine. Need to ask, not assume.
Next report
Section titled “Next report”Month 2 status report on day 60. Weekly retros continue in log/retros/.
Status Report - Notification Service
Section titled “Status Report - Notification Service”Period: 2026-05-10 to 2026-05-16 Author: Ana Rivera (tech lead) Status: Green
Headline
Section titled “Headline”Datastore decision (Postgres vs DynamoDB) concluded at Wednesday’s architecture meeting; recommendation is Postgres, lock pending Friday 11am sync with Priya. Sprint planning Friday 2pm assumes lock-in, no slippage on the 6-week ship target.
Done this period
Section titled “Done this period”- Completed the DynamoDB spike (
experiments/notify-ddb/) - confirmed it fits the access pattern; documented the operational cost - Ran the Wednesday 2pm architecture meeting with Ana, Marcus, Priya, Jordan, Sam; produced meeting notes and the draft ADR-0023
- Marcus and Ana aligned overnight on a single recommendation (Postgres) and the 5M events/day revisit threshold language
- Posted the recommendation to #notify-arch and emailed Priya for the Friday lock
- Drafted the notification service PRD with Priya (linked in ADR-0023)
Up next
Section titled “Up next”- Lock the datastore decision in the 2026-05-16 11am sync; mark ADR-0023 Accepted
- Sprint planning 2026-05-16 2pm to commit the first two weeks of build work
- Sam delivers
notificationsschema +notification_jobstable spec by 2026-05-20 - Jordan adds queue depth and write rate to the on-call dashboard by 2026-05-22
- First end-to-end internal traffic on the Postgres path by 2026-05-29
Blocked / risks
Section titled “Blocked / risks”- Not blocked. Marcus’s sign-off on the revisit threshold is pending but I have his verbal agreement; written confirmation expected by EOD Thursday.
- Risk - low: If the Slack-partnership deal closes faster than the 12-month projection, we hit the 5M events/day revisit window earlier than planned. Mitigation: Priya tracks deal timing in the partnership review cadence and gives the team 30 days of warning. No action needed this period.
- Risk - low: Postgres partitioning work at the 3M events/day mark is real and on the roadmap. Owner: Ana. Currently scheduled for Q4 if growth tracks projection.
- Priya: please confirm the 11am Friday sync is locked on the calendar.
- Engineering leadership: please review ADR-0023 by Monday so we can publish to the wider eng team and close the decision loop.