Post a working update, not a status performance

Why this rule exists

We don't do a synchronous standup where everyone recites what they did yesterday to prove they were busy. We write short updates, when there's something worth saying, because the point is to surface blockers and share direction, not to generate a daily attendance record. A good update tells the team what you're actually stuck on and where you're heading, so someone can unblock you or wave you off a cliff before you drive over it. A status performance, by contrast, is a list of verbs designed to look productive, which helps no one and quietly trains everyone to pad. The difference matters because updates are one of the few regular windows the team has into work happening in someone else's head. If we make that window honest, small problems get caught early; if we make it theater, they stay hidden until they're expensive.

In practice

Keep it to three things: what you're focused on, anything blocking you, and anything the team should know or weigh in on. Lead with the blocker if you have one, because that's the part that needs another human. Name the specific thing, not the vague area, so someone can actually help. Skip the update entirely on days you have nothing real to add rather than manufacturing filler. If you're stuck, say so plainly and early, since 'I've been fighting this for two days' is a signal we failed to catch, not a confession. Write it for a teammate who wants to help you, because that's who it's for.

Example

Focus: wiring up the export-to-CSV endpoint
Blocked: need a decision on whether we paginate
  large exports or stream them — flagged in #eng
FYI: touched the shared auth middleware, so
  pull main before you start on billing

When it doesn't apply

During a heavy build or an incident, updates get more frequent and more terse by design. And if you're the kind of person who spirals writing these, a one-line 'heads down on X, no blockers' is a complete and honest update.