How to Write Internal Status Updates That People Actually Read
Most internal status updates fail in the same way. They're a list of activities ("worked on X, met with Y, started looking at Z") instead of a report on outcomes. They bury the important news under five paragraphs of context. They get sent on Friday at 5pm to an audience that won't read them until Monday, when half the content is already stale.
The format below is what we use - a four-section template that takes about ten minutes to write, runs around 300 words, and reliably gets read by people three layers above the author. It works for individual contributors, team leads, and project owners with almost no modification.
The template
**TL;DR**
[One sentence. The single thing a busy reader should remember.]
**Shipped this week**
- [Outcome 1, with a link to evidence]
- [Outcome 2]
- [Outcome 3]
**In flight**
- [What's happening right now, with an expected ship date]
- [What's expected next]
**Blocked / needs decision**
- [Specific ask, with a deadline. Or "nothing."]Four sections. Names matter - keep them identical week to week so readers can scan in three seconds.
Why this format works
The TL;DR forces priority
If you can't compress your week into one sentence, you don't yet know what mattered most. Writing the TL;DR is usually the hardest part of the update; everything else is mechanical. When the TL;DR is honest ("Launch slipped by two weeks because of an integration issue") it earns trust, and when it's celebratory ("Q3 revenue target hit ahead of schedule") it gets shared.
"Shipped" means outcomes, not activities
"Worked on the pricing page" is an activity. "Pricing page redesign live, A/B test shows +12% trial signup" is an outcome. The first one tells the reader you were busy. The second one tells them what changed in the world because you exist.
Strict rule: every line under "Shipped" should be a thing that's done, with a measurable result or a link to it. If it's not done yet, it goes under "In flight." This rule alone makes status updates 3x more useful.
"In flight" is short on detail, long on dates
Readers don't need to know everything about a project. They need to know roughly when it will land, so they can plan around it. Each line under "In flight" should fit on one row and contain an expected ship date - even if the date is a guess. A guessed date that's wrong is still more useful than no date, because it lets people calibrate their expectations of your team's velocity.
"Blocked / needs decision" is where the real value is
This is the section that turns a status update from a report into a tool. If there's something a reader can do to unblock you - a decision, an introduction, a budget approval - put it here, with a deadline. Specific asks get acted on; vague ones don't.
If nothing is blocked, write "nothing" - don't omit the section. The presence of the section is itself information ("we're not asking for anything this week"), and the consistency makes the update scannable.
Format mechanics
Send Wednesday or Thursday morning, not Friday afternoon. Friday-afternoon updates land in a weekend, get forgotten, and then compete with Monday's fresh chaos. Mid-week is when leadership actually has time to read and respond.
Post in a public channel, not via email. Email status updates die in inboxes; channel posts get scanned by people who weren't in the original distribution. GitLab's public handbook documents this pattern at scale - public-by-default updates compound into searchable institutional memory.
Cap the length at one screen of phone reading. If it requires scrolling, it's too long. The discipline of fitting in one screen is what produces the quality. Long status updates almost always contain hedging, padding, and context that the reader doesn't need.
Don't reorder sections by importance. Keep TL;DR → Shipped → In flight → Blocked, always in that order. Predictability is the whole point - a reader who has read your update twice should be able to find the relevant section without thinking.
What this replaces
Two things, mostly.
It replaces the weekly status meeting where everyone goes around the table summarizing their week. If the same information is in a written update, the meeting becomes unnecessary - or it becomes a meeting for the things that actually need discussion (the "Blocked" section, in practice), which is a much better use of everyone's time.
It also replaces the post-hoc "what did you do this quarter?" panic, where managers scramble to assemble achievements for review cycles. With consistent weekly updates, that question is already answered - it's just a matter of reading back the TL;DRs and Shipped lines from the last twelve weeks.
An example, end to end
**TL;DR**
Onboarding redesign shipped; activation rate up 8% in first 5 days of data.
**Shipped this week**
- New onboarding flow live for all signups (PR #2341, dashboard: link)
- Removed legacy invite-code field, simplifying signup form
- Published changelog post for customers
**In flight**
- Q4 pricing page experiment - launching Sep 29
- Migrating analytics to new event schema - estimated Oct 6
**Blocked / needs decision**
- Need approval to spend $1,500/month on session-replay tool for onboarding research. Decision by Sep 26 so we can start before the holiday freeze.That's roughly 100 words. It tells a reader the most important thing first, the concrete outcomes second, what's coming third, and exactly how to help if they want to. It will take you ten minutes to write and it will be read by everyone you wanted to reach.
Sources & Further Reading
- GitLab Handbook: Bias for asynchronous communication
- Will Larson: Writing weekly updates that engineers actually read
- Signal v. Noise: Rules of thumb for status meetings
- Harvard Business Review: How CEOs manage time - background on why short, predictable formats win attention from senior readers