Designing for accountability when nobody owns the outcome
What systemic failure teaches us about responsibility in public services
For more than a decade, hundreds of sub-postmasters across the UK were prosecuted, bankrupted, or imprisoned based on data produced by the Horizon IT system used by Post Office Ltd.
The Chair of the public inquiry, Sir Wyn Williams, has since described what happened as “one of the most widespread miscarriages of justice in British legal history”.1
What is striking about the Horizon scandal is not that it involved reckless behaviour or obvious malpractice. On the contrary, many of the decisions that sustained it were made carefully, professionally, and in line with established processes.
This matters because it challenges a comforting assumption: that if we design services carefully, follow best practice, and govern them properly, good outcomes will follow.
Horizon shows that this is not always true.
Responsibility in that system was not absent. It was segmented. Tasks were decomposed, handed over, verified, and closed. Each part functioned as expected. What was missing was not effort or intent, but the ability to see — and act on — the service as a living whole.
This pattern is familiar in public services that deal with people, judgment, and trust, but are organised around transactions, cases, and throughput.
Once you accept that, a more uncomfortable question follows.
If most of what we work on in government behaves like a service rather than a product, what does accountability actually mean when that service is structured as a sequence of handovers rather than a sustained relationship?
In January, I argued that we routinely misclassify what we are designing. We treat standards, guidance, platforms, and increasingly AI-enabled tools as discrete outputs, when in reality they shape behaviour over time. They are interpreted, adapted, relied upon, and defended long after they are delivered.
February is about what happens next.
Services that involve people, discretion, and consequence cannot be reduced to a series of correct transactions without something being lost. When they are, accountability becomes procedural rather than moral. Harm does not appear as failure; it appears as an unfortunate but legitimate outcome of the process.
This is why Horizon persisted even as evidence mounted. The system was optimised for consistency, not challenge. For resolution, not doubt. For closure, not care.
And Horizon is not an outlier.
Some failures announce themselves loudly. Others dissolve into the background of normal work.
Some are quieter, slower, and easier to rationalise.
GOV.UK Verify did not collapse, breach data, or cause public scandal. It passed security assurance. It aligned with recognised standards. It was reviewed repeatedly. By many conventional measures, it was competently delivered.
And yet it never became the shared capability it was intended to be.
After more than £250 million of investment, it was closed because departments did not adopt it at scale. The National Audit Office documented low take-up, limited confidence, and misalignment between central delivery and local need. No single decision explains the outcome. No individual failure triggered it. Each party acted reasonably within their remit.2
The service did not fail loudly. It failed quietly through erosion rather than rupture.
This is not a story of incompetence. It is a story of a system designed to move work through stages, rather than hold responsibility across time.
In both cases, the work was organised around correctness: meeting criteria, passing checks, completing steps. What proved harder was sustaining accountability for outcomes that emerged later, elsewhere, and often outside the field of view of any single team.
This is what a soft failure looks like.
There are no victims in the conventional sense. There is no inquiry headline. Instead, the cost shows up as institutional drag: duplicated effort, fragmented approaches, delayed capability, and quiet loss of confidence. Responsibility is shared. Accountability never quite materialises.
This dynamic is well understood in systems thinking. In Meltdown, Chris Clearfield and András Tilcsik describe how complex socio-technical systems fail not because of single errors, but because small, reasonable decisions accumulate without sufficient feedback or corrective mechanisms. The system keeps working - until it doesn’t.
This is where many service designers feel a familiar tension.
We produce journeys that reveal systemic issues, but struggle to find an owner who can act on them. We define standards that describe good practice, but lack mechanisms to notice when their intent is being hollowed out. We measure delivery because it is observable, while outcomes drift beyond reach.
Over time, assurance becomes something that happens to the service rather than within it. Reviews confirm that the right steps were taken. Learning remains optional. Responsibility becomes something that belongs to a moment, not a relationship.
What is often described as a lack of ownership is, more precisely, the result of organising relational problems as if they were transactional ones.
Accountability does not disappear. It becomes procedural. It becomes distributed. It becomes difficult to locate the point where harm is felt.
Importantly, this does not mean public services are doomed to fail.
There are examples of services that have resisted this pattern. Chile’s Comisaría Virtual is often cited not because it is flawless, but because responsibility for outcomes remained visible as the service evolved. Digital access to policing services was treated not as a one-off delivery, but as an ongoing public commitment. During the pandemic, that distinction mattered.3
The difference is not technological. It is structural.
If services that deal with people are designed and governed as if they were factories for processing cases, then harm can be produced even when everyone involved is acting in good faith. The system will do exactly what it was designed to do, just not what we hoped it would achieve.
If no one owns the outcome, it is not because people do not care.
It is because the system has been optimised to complete transactions, not to sustain responsibility over time.
That is not a failure of execution.
It is a failure of fit.
And it is one we need to be honest about before we can name it properly.