Put the bottom line first
Most people who read a weekly update read one or two lines and move on. So the first line has to carry the whole message: are things on track, and does the reader need to do anything? Military writers call this BLUF, bottom line up front. Everything under it is detail for the reader who wants it.
A good first line answers three questions in one or two sentences:
- Where do things stand against the plan? On track, at risk, or off track, and for which goal.
- What changed since last week? The one thing that moved the status, good or bad.
- What do you need from the reader? A decision, an introduction, a signature, or nothing.
"Busy week, lots of progress on several fronts" answers none of them. "Launch is on track for October 15; the vendor contract is two weeks late and needs your call on a backup by Friday" answers all three.
Report progress against a plan, not a list of activity
The most common weak update is a diary: meetings held, emails sent, calls made. It shows effort. It does not show whether the goal is closer. Before writing, name the two or three things you promised to deliver this month or quarter, and report each one against its target.
| Activity (weak) | Progress against the plan (stronger) |
|---|---|
| Had three calls with the payments vendor | Checkout switch: contract signed, integration 60% built, still on track for November 1 |
| Worked on the hiring pipeline | Designer hire: offer accepted, starts Monday; 1 of 2 planned hires done this quarter |
| Met with the marketing team about the campaign | Email campaign: slipped one week to October 8 because the copy review ran long |
This matters beyond the reader. Teresa Amabile and Steven Kramer studied the daily diaries of knowledge workers and reported in Harvard Business Review in 2011 that making progress in meaningful work, even in small steps, did more than anything else to lift people's motivation on a given day1. An update that shows real progress against a goal makes that progress visible to the team, not just to the manager.
Writing it down helps the goal too. A 2016 meta-analysis in Psychological Bulletin pooled 138 experiments with 19,951 people. Prompting people to monitor their progress helped them reach goals, and the effect was larger when progress was reported to others or made public, and when it was written down2.
Red, yellow, green, done honestly
Many teams mark each goal red, yellow or green. The known failure has a name among project managers: the watermelon, green on the outside and red on the inside. Every weekly report says green until the week it says red, and by then the options are gone.
This is a well-studied pattern, not a matter of a few bad actors. Andrew Snow and Mark Keil modeled traffic-light status reporting on software projects in IEEE Transactions on Engineering Management in 2002. They split the gap between real and reported status into two causes: managers can see the project wrongly, and they may not report faithfully what they do see. Their model found project managers tend toward excess optimism, and they advised executives to treat good news with some doubt3. Optimism also starts before the work does. Bent Flyvbjerg and his co-authors studied 258 transport projects in the Journal of the American Planning Association in 2002 and found costs were underestimated in almost 9 out of 104.
The fix is to agree what each color means before anyone uses it, in terms someone else could check:
| Color | Means | The update must say |
|---|---|---|
| Green | Will hit the target date and scope with the current plan and people | The next milestone and its date |
| Yellow | At risk: a known problem could cause a miss, but the owner can still recover it | The problem, the recovery step and when you will know |
| Red | Will miss the date or scope unless something changes that the owner cannot change alone | What needs to change and who has to decide |
Two habits keep the colors honest. Treat yellow as useful news, not failure: a team that is punished for yellow learns to report green. And when a status changes, say why in one line, so the reader sees the trend and not just the color.
Every blocker comes with an ask
A blocker without an ask is a complaint. The reader cannot tell whether you are handling it or waiting for them. Write each blocker so it names what is stuck, what it costs if it stays stuck, and exactly what you need, from whom, by when.
| Weak | Stronger |
|---|---|
| Waiting on legal for the vendor contract | Vendor contract has been with legal for 12 days. If it is not signed by Oct 1, the November launch slips. Ask: can you ask legal to prioritize it, or approve the backup vendor? |
| Design resources are tight | One designer covers two projects, so the pricing page mockups are a week behind. Ask: pick which project goes first this month. |
If you do not need anything, say "No ask this week." That tells the reader the blocker is under control.
Keep it short, and what an update cannot do
A weekly update that fits on one screen gets read. Aim for a one or two sentence summary, then no more than three to five lines each for progress, blockers and next steps. Cut anything the reader could not act on or would not miss. The same format every week helps too: readers learn where to look.
An update reports on a plan; it cannot stand in for one. If there are no clear goals with dates, every week turns back into a list of activity. What to use next:
- No clear goals to report against? Set them first with the OKR generator or the SMART goals generator, and pick the numbers to track with the KPI picker.
- Want a weekly rhythm built around the goal? 4DX sets out a short weekly meeting where each person reports on last week's commitments and makes new ones.
- Same risks showing up week after week? Move them into a risk register with owners and triggers.
- Blockers that need a real conversation? Take them to your next one-on-one rather than leaving them in writing.
Frequently asked questions
- What should a weekly status update include?
- A good weekly update has a one-line summary, what got done (progress), what is stuck or at risk (blockers), and what is planned next. The summary lets a busy reader skim; the lists give detail on demand.
- Who is a weekly update for?
- Usually your manager, your team, or stakeholders. Lead with the summary so they get the gist first, and keep each line tight.
- Does this tool save my notes?
- No. Your notes are used to generate the update and are not stored. The tool is anonymous and free.
- What is a good format for a weekly status update?
- Start with one or two sentences that say where things stand against the plan, what changed this week and what you need from the reader. Then list progress against each goal, blockers with a clear ask, and next steps. Keep the same order every week so readers learn where to look.
- What do red, yellow and green mean in a status report?
- Green means the goal will hit its date and scope with the current plan. Yellow means a known problem could cause a miss, but the owner can still recover it. Red means it will miss unless something changes that the owner cannot change alone. Agree these meanings before anyone uses the colors. Research on traffic-light reporting in software projects found managers tend to report too optimistically3.
- What is a watermelon status report?
- A report that is green on the outside and red on the inside: every goal shows green until the week it suddenly turns red. It usually happens when yellow is treated as failure, so people wait until a problem is certain before they report it. Clear color rules and treating yellow as useful news help prevent it.
- How long should a weekly update be?
- Short enough to fit on one screen. A one or two sentence summary, then three to five lines each for progress, blockers and next steps is plenty for most teams. If a reader could not act on a line or would not miss it, cut it.
Sources
- Teresa M. Amabile and Steven J. Kramer, "The Power of Small Wins," Harvard Business Review, May 2011. hbr.org
- Benjamin Harkin, Thomas L. Webb, Betty P. I. Chang and others, "Does monitoring goal progress promote goal attainment? A meta-analysis of the experimental evidence," Psychological Bulletin 142(2), 2016, pp. 198 to 229. doi.org
- Andrew P. Snow and Mark Keil, "The challenge of accurate software project status reporting: a two-stage model incorporating status errors and reporting bias," IEEE Transactions on Engineering Management 49(4), November 2002, pp. 491 to 504. doi.org
- Bent Flyvbjerg, Mette Skamris Holm and Søren Buhl, "Underestimating Costs in Public Works Projects: Error or Lie?" Journal of the American Planning Association 68(3), 2002, pp. 279 to 295. doi.org
Written by Tom Olajide, Founder. Last reviewed September 24, 2026.