Skip to content
Leadership Advanced 4 min

Replacing Status Meetings with Observability

A weekly status meeting reassures the manager and decides nothing. Observable system state beats reported status on accuracy, freshness, and reach.

By Victor Robin •

The problem

A standing status meeting feels like control and usually delivers reassurance instead. Most of what it collects is already true somewhere more reliable than memory, and the meeting bills the team for the difference.

I ran one. After a release slipped and I was caught flat-footed, I added a weekly 45-minute “Delivery Sync” — the whole team, going around the room. It felt informative until I priced it: eight engineers, 45 minutes, plus the context-switch tax on either side, is eight to ten engineering-hours a week. I went back through six weeks of my notes and counted the decisions made in that room. There were two. We reversed one by Thursday. The meeting wasn’t informing me; it was reassuring me.

The model

A team runs on shared context — everyone holding a roughly accurate picture so they can act without checking in first. What shipped, what’s failing, who’s burning error budget, where the queue backs up: that isn’t status, it’s state, and state is observable. Observed state beats reported state on every axis that matters — more accurate, always current, available to everyone at once instead of trapped in a window you happened to schedule. A manager has only a few real controls (what gets measured, what gets surfaced, what’s worth interrupting work for); a standing meeting feels like one but mostly consumes the attention it claims to coordinate.

What to do

  • Build a “team health” dashboard as a first-class artifact: deploy frequency, change-failure rate, time-to-restore, and current error-budget burn per service. One screen, always on, owned like production code.
  • Replace the meeting with a short async review. Post the dashboard with three or four sentences of narration (“budget tight on the ingest path, two PRs stuck in review”) and keep the comment window open a couple of days.
  • Define what still earns synchronous time: decisions with real disagreement, anything touching a person directly, and incident command. If it fits on the dashboard, it’s banned from the calendar.
  • Make the dashboard your source of truth upward, so you stop privately re-deriving state the team can already see. Same picture, top to bottom.

The results

We recovered roughly eight engineering-hours a week the moment the recurring slot disappeared — though some migrated into reading and commenting on the async review; the honest version is that we converted synchronous attention into asynchronous and came out ahead, not that we conjured free time. Incident calls got sharper: with state already on screen we argued about the fix, not the facts, and time-to-restore on the messier incidents fell from around a day to a few hours over the quarter (we tightened on-call at the same time, so the dashboard didn’t do that alone).

The caveat: a dashboard shows the system, not the engineer who is stuck and not saying so. A status meeting at least gave reticent people a scheduled moment to surface a worry. I had to add that synchrony back as short, regular one-on-ones — and I’d stand those up first next time, before removing the meeting, rather than discovering the gap after.

Further reading