Show Your Working

Why visible fixes build knowledge, demonstrate competence, and strengthen trust.

Show Your Working

Every fix is a puzzle solved. Each one shelved in the open becomes part of the organisation’s library, a catalogue others can search, learn from, and build upon.

When someone raises an issue, they have already invested in the system. They noticed, they documented, and often they brought clues with them. In many cases they are also blocked, unable to continue their own work until the problem is resolved. As explored in Shouting in the Digital Office’s “Bring the clues with you,” that effort is a building block of organisational learning.

After a fix, responding with a clear explanation of what changed achieves three things. It confirms shared understanding of the problem. It demonstrates skill and care in the resolution. And it creates a record others can learn from. Each closed loop is another solved puzzle added to the shelf, compounding into resilience over time.

To be useful, the explanation must be explicit. Not just that the issue is fixed, but what was done to resolve it: which component was touched, which behaviour corrected, which decision made. Without that clarity, others cannot verify the fix, learn from it, or challenge whether it is sustainable.

A fix is not complete until it is explained - clarity turns resolution into knowledge, builds trust, and multiplies business value.

Invisible fixes do none of this. A simple “try again” leaves uncertainty, prevents knowledge from compounding, and discards the chance to test whether the resolution is correct or durable. Visible fixes invite verification. Others can confirm the change, assess whether it will hold, and share their perspective on whether the issue might return. That scrutiny strengthens both the fix and the organisation’s confidence in it.

Openness is not about blame. It is about showing competence, making care visible, and building trust. Communication can matter as much as technical skill, because the way fixes are shared often decides whether they help once or many times.

The same instinct matters outside the walls. Release notes that say “bug fixes and improvements” teach nothing. A note that names the issue and the change builds confidence that the system is under control. Better: “Fixed login timeouts on older Android devices by correcting token refresh logic and adding a retry on 429.” That shows understanding, shows care, and reduces the chance of return.

Respect in engineering is not only in restoring function, but in making visible the steps taken to keep things reliable. When organisations work this way, issues turn into durable knowledge, trust strengthens across teams, and customer confidence grows. The business value is clear: faster recovery, fewer repeats, unblocked teams, and a culture where every fix multiplies its impact.