Skip to content

Communication & Status Updates

Writing a status update is a small act of respect for the reader's time: it should tell them the state of things without making them go dig for it.

When this matters

Any time you're not sitting next to the person who needs to know where things stand — a daily standup note, a weekly update to whoever you report to, a comment on an issue or PR, or an async message to a teammate in a different timezone. The written update is the interaction; there's no tone of voice or body language to fill the gaps, so it has to carry the whole signal on its own.

The practice

Match the update to the reader and the channel. A one-line async note and a fuller weekly summary carry the same underlying information at different resolutions — pick the resolution the reader actually needs right now, not the one that's easiest for you to write. Keep routine updates terse; save the fuller narrative for when someone asks for detail or for the weekly cut.

Default to async; reserve sync for what genuinely can't wait. Post the update where the reader will see it when they check in — don't assume anyone is watching it live. Interrupt someone synchronously only when a decision truly can't wait for the next time they look, and be able to say in one sentence why it couldn't.

Match a cadence, not just a moment. A daily update is meant to be skimmable in well under a minute — current state, nothing more. A weekly update is where the fuller picture belongs: what actually moved, what didn't, and why. Don't make a daily note carry weekly-sized narrative, and don't let a weekly update be nothing but a list of daily notes stapled together.

Close the loop — every time, even when there's nothing new. An update that never comes reads to the reader as "something's wrong," not as "everything's fine." If there's genuinely nothing to report, say that in one line rather than staying silent — silence and a dropped thread look identical from the reader's side.

Lead with the signal, not the story. A reader skimming in ten seconds should get the state and whatever you need from them in the first couple of lines. Anything else — the why, the detail, the color — comes after, for the reader who has time to keep going.

Checklist

  • Did I pick the right resolution for this reader and channel — quick async note, or the fuller weekly cut?
  • Does the update cover what changed since last time, where things stand now, and what's next?
  • Is any risk or ask named explicitly, not buried inside a longer narrative?
  • Did I send it even though there's nothing new to report?
  • Would a reader with ten seconds get the state and the ask from the first two lines?

Template

Since last update:
- <what happened / what shipped / what changed>

Now:
- <what you're doing right now>

Next:
- <what's coming, and roughly when>

Risks / asks:
- <anything blocking you, or anything you need from the reader — or "none">

Adapted from

  • SE's support-intake skill — acknowledge fast, no dropped threads, match the reader's register.
  • SE's heartbeat-protocol skill — signalling state as a standing, checkable fact rather than a one-off comment.
  • SE's no-cascade-marker skill — opening a message with a legible, one-line signature naming who's speaking, with what changed stated in the body right beneath it, not folded into the signature line.
  • role-runtime/docs/book/04-operating.md — the daily (quick, skimmable) vs. weekly (deeper, synthesized) cadence split.

Practice it

Ask the onboarding-tutor: "Write me a status update for this week's work on <my current task>, using the Since last update / Now / Next / Risks-asks template, and tell me if I buried the ask."