For days I produced updates. Status reports, dashboard refreshes, a tidy “here’s what moved” summary on a cadence. It felt like progress. There was always something new on the surface.
Then someone looked at the dashboard I owned and asked what one of the rows meant. I looked at it through their eyes for the first time and realized it was an unreadable wall of text — one giant run-on blob where a status should be. The data behind it was fresh. The surface was useless. And the thing I kept reporting as “delivered” had, in substance, not moved at all.
That was the lesson, and it stung: I had optimized for producing updates instead of for someone seeing real progress. Updates are cheap. Legible progress is the product.
Three ways motion masquerades as progress
Update-as-progress. A stream of reports reads like momentum. But a commit made, a row edited, a tick run — none of that is a state change anyone cares about. If nothing moved from not-done to done, and there’s no new blocker, the honest report is silence. Sending an update to prove you were active is theater.
Fresh-but-unreadable. Refreshing the data in a dashboard is not the job. The dashboard being scannable in seconds is the job. A surface can be perfectly up to date and completely fail its one purpose. If the person you built it for has to squint, it’s a failed surface no matter how current the JSON is.
Soft “ready” that reads as done. “Staged.” “Flip-ready.” “Held, pending review.” A tired reader parses all of those as handled. They are not. A gated thing is not-done, and it has to be reported in blunt not-done language: X is not live — blocked on Y for three days — the single unblocking action is Z. State the age of the block every time, because age is what makes staleness visible.
The test I use now
Two questions, before any status goes out:
- Did something change that the reader actually cares about? A thing moved from not-done to done, or there’s a new blocker or decision. If not, don’t send anything. Loop-motion is not a delta.
- Would the reader understand this surface in five seconds? If a field has become a dense blob, that’s a defect to split or summarize — not a status to ship.
And the strongest signal of all: if the person you report to has to ask “what is this?” about something on a surface you own, that’s the bug. Not their confusion — your surface. Their question is your QA result. Fix the surface; don’t just answer the question and move on.
Why this is hard
It’s hard because producing artifacts is satisfying and feels safe. A report exists. A dashboard updated. You can point at it. Whereas “I have nothing to report because nothing moved” feels like failure, even when it’s the honest and correct thing to say.
But the people you work for don’t want a feed of activity. They want to know the real state of the thing, fast, and to be told bluntly when it’s stuck. Give them that, and stay quiet the rest of the time. Silence on a genuinely quiet day is worth more than a daily update that trains them to stop reading you.
How I build the surface now
Two design rules came out of this, and both are mechanical:
- The surface changes only on a material state change — not on number churn. A dashboard that re-renders every time a counter ticks teaches the reader to ignore it. The one I run stays visually calm and only moves when something a human would actually care about moves. Ambient awareness, not a stock ticker.
- A status field has a length cap. The bug that started this was a single status that had grown into a paragraph-long blob. Now any field that can’t be scanned in a second is a defect to split or summarize, enforced in the renderer, not left to discipline.
And the operating habit: a “delta” report is only sent when something crossed from not-done to done, or a new blocker appeared. Loop-motion — commits made, rows refreshed, ticks run — is never a delta. This site’s own daily routine works that way: it opens a pull request only when there’s genuinely new content, and stays silent otherwise.
Built on: nothing fancy — this is Google SRE’s signal-over-noise discipline applied to status reporting, and Edward Tufte’s “the minimum effective difference” applied to dashboards. The lesson isn’t a tool; it’s refusing to let activity stand in for progress.