Status updates that actually inform — what to include, what to cut
ost weekly status updates are written by people who feel obligated to send them and read by people who feel obligated to skim them. They consume time at both ends and surface roughly nothing useful. Status updates that actually inform are short, structured, and biased toward the things stakeholders need to act on rather than the things that happened.
Informative status updates
- Weekly updateinclude
- Decisions needed
- Risks and blockers
- Progress since last
- Next week focus
- Under 10 minutes
- Cut performative sections
Table of Contents
- What you'll learn· 1 min
- The four sections that matter· 1 min
- Writing it in under 10 minutes· 1 min
- What to cut· 1 min
Quick reference
Four sections
Headline, status, risks/decisions, done/next.
Headline first
One line that carries the most important signal.
Decisions needed
Most actionable section. Most space. Named owner and deadline.
10 minutes
Friday morning, template, pre-filled from tool. Done.
Word budget
200 words most projects, 400 for the largest.
Don't lie green
Bad news travels best when it travels early.
Most weekly status updates are written by people who feel obligated to send them and read by people who feel obligated to skim them. They consume time at both ends and surface roughly nothing useful. Status updates that actually inform are short, structured, and biased toward the things stakeholders need to act on rather than the things that happened.
What you'll learn
The four sections that matter
A useful weekly status update has four sections, in this order:
1. Headline (one line). "On track for May 8 launch. Two risks emerging — see below." This is the line that gets read by stakeholders who only have ten seconds. Make it carry the most important signal.
2. Status against plan. Are you on track, behind, ahead, or off-track? One sentence, plus the date the answer last changed. Don't bury the lead.
3. Risks and decisions needed. New risks since last update. Decisions you need from someone — by when, with the option set. This is the section stakeholders actually act on. It deserves the most space.
4. Done this week / next week. Optional, kept short. Three bullets each maximum. Stakeholders almost never need the detailed task list; the people who do need it should be in the project tool, not the update.
The order matters: the headline pulls the signal up, and the most actionable content (decisions needed) gets prominence. Most updates do this in reverse — narrative of what happened, then maybe a risk at the bottom that nobody reads.
Writing it in under 10 minutes
A clear weekly update should take 10 minutes, max. If yours takes an hour, the structure is doing too much work.
A practical rhythm:
- Friday morning, 10 minutes. Open last week's update. Update each section. Send.
- Use a template. Same four headings, same order, every week. Predictability lets readers find what they want quickly.
- Pre-fill from the project tool. Most modern tools (Linear, Jira, Asana) can give you the "shipped this week" list automatically. Don't hand-write what the tool already knows.
- Cut the colour commentary. Stakeholders don't need the story. They need the state.
- Set a strict word budget. 200 words for most projects, 400 for the largest. If you're consistently writing more, you're doing the project tool's job.
The weekly update is a status mirror, not a narrative essay. Treat it like a dashboard with sentences instead of charts.
What to cut
Sections that look professional but consume time and surface nothing:
The lengthy "what happened this week" narrative. If you can't reduce a week to three bullets, you're explaining instead of summarising. The detail belongs in the project tool, not the update.
The team-by-team breakdown. A status update is the project state, not an org chart. The team leads can write their own internal updates if they need to.
The "blockers" section that's really a complaint section. A blocker is a specific decision or resource you need by a specific date. "Frustrated with cross-team alignment" isn't a blocker — it's frustration. Either translate it into a concrete decision request or leave it out.
The metrics dump. One key metric per update is enough, with a sentence about what changed. A wall of metrics nobody reads is worse than no metrics.
The "all green" status when it isn't. The hardest cut and the most important. If something is wobbly, say so early. Stakeholders forgive bad news that arrives early; they don't forgive surprise.
Want a more guided way to practise this?
Common questions
How often should I send updates?
Weekly is the default for most projects. Longer projects (3+ months) can do every two weeks if the rhythm of decisions allows. Daily updates are almost always too frequent to be useful at the stakeholder level.
What about written vs. live status meetings?
Written first, every time. A live meeting that exists only to read out the status is a tax on everyone. If you keep the meeting, use it for discussion of the risks/decisions section, not for narration of the work.
Should I CC the whole company?
No. Send it to the people who actually act on it — typically your sponsor, immediate stakeholders, and the team. Wider distribution dilutes the signal and trains everyone to skim.
How do I handle a project that's clearly going off the rails?
Send a separate, prominent update — not the regular weekly one. Headline the bad news, name the decisions needed, and propose a path. Don't bury it inside the routine update; the change in format helps stakeholders take it seriously.
Bottom line
Useful status updates are short, structured, and front-loaded with signal. Headline, status, risks and decisions, done/next. 200 words. Ten minutes on a Friday. Cut the narrative, the colour commentary, and the team-by-team breakdown. Bad news early, every time.