Scrolls
6 min read
On this page

Status Updates That Work

Nobody reads your status update. Not because they do not care, but because most status updates are not worth reading. They are either too long, too vague, or too focused on activity instead of outcomes. "Worked on the API refactor this week" tells the reader nothing actionable. It does not say whether the refactor is on track, blocked, or finished. It does not tell anyone what to expect next week.

A good status update takes 5 minutes to write and 30 seconds to read. It answers three questions: what shipped, what is blocked, and what is next. Write for the reader, not for yourself.

The Three-Section Format

Every status update should have exactly three sections. No more. If you need more, you are writing a report, not an update.

## What Shipped
- Deployed annual billing support (PR #847, #852)
- Migrated 12k existing subscriptions to new schema
- Closed 3 customer-reported bugs in the checkout flow

## Blocked
- Payment provider sandbox is down since Tuesday, blocking
  integration tests for the refund flow. Ticket open with
  their support (ref: PAY-4421). ETA unknown.

## Next
- Refund flow integration tests (once sandbox is back)
- Start on invoice PDF generation (design approved, JIRA-2001)
- Tech debt: remove deprecated v1 billing endpoints

That is the entire update. One paragraph per section, maybe two. No narrative, no filler, no "I had several productive meetings this week."

What Shipped

This section is about outcomes, not activities. "Worked on X" is an activity. "Deployed X" or "Merged X" or "Closed X" is an outcome.

Bad (activity):
- Worked on the API refactor
- Had meetings about the migration plan
- Reviewed some PRs

Good (outcomes):
- Merged API refactor PR #312: response times down 40% on /search
- Finalized migration plan, posted RFC for review (link)
- Reviewed and approved PRs #318, #321, #325

Include PR numbers, links, or measurable results when possible. They make the update verifiable and give the reader a path to more detail if they want it.

What Is Blocked

This is the most important section, and the one most people skip. Blocks are what leadership and cross-functional partners need to know about. If you are not blocked on anything, say so explicitly: "No blockers this week."

Good blockers:
- Waiting on legal review of the new privacy policy before we can
  ship the consent flow. Sent to legal on Monday, following up Thursday.
- CI is flaky (3 out of 10 runs fail on the E2E suite). Wasting ~2 hours
  per day on re-runs. Investigating root cause, but might need platform
  team help.
- Design for the settings page is not started yet. Cannot begin frontend
  work until wireframes are ready. Checking with design team on timeline.

Notice the pattern: state the blocker, state what you have done about it, and state what happens next. Do not just say "I'm blocked." Say what is blocking you and what the unblocking path looks like.

What Is Next

This section sets expectations for the next period. It lets your manager and teammates know what to expect and creates implicit commitments that help you prioritize.

Good "next" items:
- Ship the consent flow (assuming legal approval by Wednesday)
- Start backend work on the notification preferences API
- Pair with Maria on the database sharding spike

Bad "next" items:
- Continue working on stuff
- Various meetings
- TBD

Be specific enough that someone could check next week whether you did what you said you would. If your plans change, that is fine -- but having an explicit plan makes the change visible.

Audience Awareness

Different readers need different things from your status update. Write for the most important audience, and structure the update so everyone can extract what they need quickly.

Your manager:            Are you on track? Are you blocked? Do you need help?
Your teammates:          What can I expect? What should I watch for?
Cross-functional peers:  Does anything here affect my team's work?
Skip-level leadership:   Is this project on track? Any risks?

The three-section format serves all of these audiences. The manager checks "Blocked" first. Teammates check "Next" to see what is coming. Cross-functional peers scan "What Shipped" for impacts. Leadership skims the whole thing in 15 seconds.

If you need to tailor for a specific audience (e.g., a weekly email to the VP), start with the same three sections and add a one-sentence summary at the top:

Summary: Annual billing is live and processing. Refund flow is blocked
on payment provider outage. On track for Q2 milestone.

That one sentence is often all leadership reads. Make it count.

Frequency & Cadence

Weekly is the right frequency for most teams. Daily is too noisy for async updates (though async standups can work for daily check-ins). Biweekly is too slow -- problems fester for two weeks before becoming visible.

Daily standup (async):     Short, focused on today's plan and yesterday's blockers
Weekly update:             The full three-section format
Sprint/biweekly review:    Tied to your iteration cadence, more detailed
Monthly summary:           For leadership, aggregated from weekly updates

Pick a day and time and stick to it. Friday afternoon is popular because it forces you to reflect on the week. Monday morning is popular because it sets expectations for the week ahead. The exact day matters less than consistency.

Where to Post

The update should be easy to find and easy to reference. Common locations:

Team Slack channel:       Good for visibility, bad for long-term reference
Project management tool:  Good for linking to tickets, searchable
Email:                    Good for leadership updates, inbox clutter risk
Shared doc:               Good for running record, easy to skim history
Dedicated tool:           Geekbot, Status Hero, Range -- automate collection

The worst option is a meeting. A synchronous round-robin status meeting where each person reads their update aloud is a spectacularly expensive way to share information that everyone could have read in 30 seconds.

If your team does standup meetings, convert them to async standup posts. Use a Slack bot or just a channel convention: post your update by 10am in #team-standup. Same information, zero meeting time.

Writing Concisely

Status updates have a length problem. People either write too little (one vague sentence) or too much (three paragraphs per item). Aim for the sweet spot: enough detail to be actionable, concise enough to be read.

Too short:
"Made progress on billing."

Too long:
"This week I continued work on the billing service refactoring
that we discussed in last sprint's planning meeting. As you may
recall, the goal of this refactoring is to support annual billing
plans in addition to the monthly plans we currently offer. I spent
Monday and Tuesday updating the subscription model to include a
new 'billing_period' field, which required changes to the database
schema as well as the API serialization layer. On Wednesday..."

Just right:
"Shipped annual billing support: new billing_period field on
subscriptions, updated API and admin dashboard. 12k existing
subscriptions migrated. Three checkout bugs fixed along the way."

Use plain language. Do not pad with qualifiers ("I was able to successfully complete the implementation of..."). Just say what happened.

Making Updates Useful Over Time

Status updates are not just for this week. They are a record of what happened. When someone asks "when did we ship annual billing?" or "what blocked us in March?", a searchable history of status updates provides the answer instantly.

Making updates searchable:
- Include ticket numbers (JIRA-2001) and PR numbers (#847)
- Use consistent terminology (always "annual billing," not sometimes
  "yearly plans" and sometimes "annual subscriptions")
- Include dates for shipped items and blockers
- Keep updates in a searchable medium (not ephemeral Slack messages)

Some teams keep a running Google Doc or Notion page with weekly updates appended. This creates a timeline of the project that is invaluable for retrospectives, performance reviews, and handoffs.

Common Pitfalls

  • Writing for yourself instead of the reader. Your update should answer the reader's questions, not describe your week. The reader wants to know: is this on track? Is anything at risk?
  • Activity instead of outcomes. "Attended 5 meetings" and "worked on the migration" are activities. "Migrated 12k records" and "deployed to production" are outcomes. Report outcomes.
  • Burying blockers. If you are blocked, that should be the first thing the reader sees. Do not hide it after a list of accomplishments.
  • Skipping the update when nothing exciting happened. "Continued work on X, no blockers, same plan next week" is a valid update. Skipping the update makes people wonder if something is wrong.
  • The status meeting. A meeting where 8 people take turns reading their updates is 8 times more expensive than 8 people posting their updates in a channel. Convert to async.
  • Inconsistent cadence. If you post some weeks and skip others, people stop checking. Consistency builds the habit for both the writer and the reader.

Key Takeaways

  • A status update has three sections: what shipped, what is blocked, and what is next. That is it.
  • Write outcomes, not activities. "Deployed X" tells the reader something. "Worked on X" does not.
  • The blockers section is the most important. It is what your manager and cross-functional partners need to act on.
  • Keep it to one paragraph per section. If it takes more than 30 seconds to read, it is too long.
  • Post consistently on the same day each week. Consistency builds the reading habit.
  • Use async updates instead of status meetings. Same information, a fraction of the cost.