Status and decision updates

Templates are not bureaucracy. They are a shared schema so a skimmer knows where the status, the risk and the ask live. Reuse three shapes until they are muscle memory: the weekly status, the incident update and the decision request.

Status update

Audience: your team, your manager, stakeholders who only skim.

Status: ON TRACK | AT RISK | BLOCKED
Goal this week: <one sentence>
Done since last update:
- …
Next:
- …
Risks / asks:
- <risk>: mitigation or decision needed from <name> by <date>
Links: design doc, dashboard, tracking ticket

"Making progress" is not a status. Name the artifact ("merged auth refactor", "load test at 2× peak passed") so a reader can judge reality without a meeting.

Incident update

Audience: on-call peers, managers, sometimes a status page. Speed and accuracy beat polish. See production ownership.

Severity: SEV-2 | Customer impact: checkout failures ~8% of attempts
Status: MITIGATING | Started: 14:32 UTC | Last update: 15:10 UTC
What we know: elevated 5xx on api-checkout; correlated with deploy abc123
What we're doing: rolled back deploy; watching error rate
Next update: 15:30 UTC or sooner if impact changes
Owner: @you

Separate facts, hypotheses and actions. Mixing them creates panic. Update on a cadence even when nothing changed ("still investigating; no new impact") so people stop pinging you.

Decision request

This is the highest-leverage writing you do. Frame options so the decision maker can pick without re-deriving your analysis. Link the design doc; do not paste it into Slack.

Decision needed by: Thursday EOD
Options:
A) Ship behind flag Friday — lower launch risk, +1 eng-day
B) Delay launch 1 week — more bake time, slips marketing
Recommendation: A, because …
Consequences if we don't decide: default is B by Friday noon

Walking through a rewrite

Same facts; different signal.

Before: "Hey all, just wanted to give a quick update on the notifications work. Still chipping away at it. Hit a few snags with the vendor API but making progress. Hoping to wrap soon. Let me know if you have questions!"

Readers learn nothing. "Soon" is not a date. "Snags" is not a risk. Nobody knows whether to help, wait or escalate.

After:

Status: AT RISK for Friday launch. Vendor rate limits block full backfill; need decision below.

Done: dual-write to new notifications table live in staging; 100% parity on canary cohort (n=2k users). Next (Wed–Thu): production backfill at 50 msg/s (~14 hours); feature flag default-off until bake. Risk: vendor cap is 100 msg/s shared across company — if Search starts a campaign Thursday, we slip to Monday. Ask @morgan (by Wed noon): (A) proceed Friday with partial backfill + catch-up weekend, or (B) slip launch to Monday. Recommend A if marketing can accept ~30% users on old path for 48 hours.

The second version takes about five more minutes to write and can save a meeting.

Common mistakes

• Fake status. "Working on it" every week. Name artifacts, risks and dates.
• Mixing facts and guesses in an incident. Label hypotheses so nobody pages from a hunch.
• A decision request with one option. Give at least two real paths and a default if nobody answers.

Check yourself

1. Why is "hoping to wrap soon" a weak status line?

It has no date, no artifact and no ask, so nobody can help or escalate.

2. What three things must a decision request include besides the options?

A deadline, a recommendation and a default if nobody decides.

Key takeaways

• Status names artifacts and risks, not vibes.
• Incident notes separate facts, hypotheses and actions, and land on a cadence.
• Decision requests give options, a recommendation and a consequence of silence.

Further learning

Next: async etiquette.