Done Looks Like Silence

We used to think a product was done the day we released it. The deploy went green, the changelog went out, and we called the ticket finished. It took one of the quietest releases we ever shipped to show us how wrong that was.

The release where nothing happened

Last year we fixed the slowest part of FleetOS. Routes kept failing because they were planned on data that was a day old, so we rebuilt the planning layer to read live telemetry. The work took weeks. Then it shipped, and nothing happened.

No spike in the dashboard. No flood of support emails. For the first week we kept waiting for the phone to ring. It did not. We checked the logs out of habit in week two, found nothing worth reading, and moved on. A month passed, then two, then three. Nobody called. Nobody reopened anything.

It took us that long to realize we had done the job properly. We were so used to shipping being loud that we did not recognize the job being done as silence.

The actual definition of done

A ticket closing is not done. A deploy succeeding is not done. A feature shipping is not done. Done is what the world looks like a while after those moments. A bug fix is done when the bug stops coming back. A feature is done when it stops needing attention.

This sounds obvious written down, and almost nobody runs their team on it. Status boards reward visible motion. A shipped feature shows up in a standup, in a changelog, in a release note. A system that is doing its job shows up nowhere. So teams learn to reward shipping and punish silence, without ever saying so.

We started doing the opposite.

The quiet graph we almost deleted

In DevXcl we built a warning that catches burnout patterns before they surface as incidents. For its first two months the alert was nearly silent. One or two notes a week, nothing dramatic. The graph was boring enough that we kept convincing ourselves it was wasted work, and we cut it in review twice.

It was the most valuable graph we have.

Teams with long review latency and weekend commit patterns showed up in the data weeks before anyone called it a problem. Nobody was complaining, and that was exactly the point. The warning was not failing. It was scoring a perfect game, and we had trained ourselves to read a perfect game as a bug.

Check the absence, not the presence

The shift changed how we review everything. Now a product is discussed in terms of what stopped happening, not what started. Route failures that stopped. Duplicate charges that stopped. Burnout warnings that never needed to turn into full incidents.

The strongest signal we have is the problem that used to call us and now does not.

Try this on your own team

None of it requires a new tool. It requires a different habit, in three parts.

First, wait before you call anything finished. Do not pronounce a fix done on deploy day. Put a review date a month out and check back. If nothing has returned, then it is done.

Second, keep a list of the problems you have fixed, with a date beside each one. Revisit the list every few weeks and mark which entries stayed quiet. Those marks are your real wins, and you will be surprised how rarely they get celebrated.

Third, say the quiet wins out loud. When a system has gone ninety days without a complaint, that deserves the same energy as a launch. It is a launch, just in reverse.

The most alive thing we build

A product that sits there and works is the most alive thing we make. The tickets that stop reopening. The alerts that stop firing. The inbox that goes quiet. That is the definition of done. Not the day we pressed deploy.

The day after that, and the day after that, until there is no next day, because there was nothing left to fix.

If you are tired of the same problem reopening every few months, send it to us. Finding the cause is our daily work.

Related reading: From Symptom to Source covers the trace we run before any of this quiet is earned.