You hear it all the time in public service and large organisations: We need to be more agile. We need to think like a startup. We need to disrupt ourselves. We need to fail.

This mandate ignores a fundamental, structural reality: we are trying to force the agility of a startup into an institution whose DNA was written to manage mass compliance.

Startups are designed to find market fit by moving fast, breaking things, and accepting a high mortality rate of almost 90%. In the UK, the corporate “failure rate” of statutory public services is essentially zero. Public bodies don’t die. Facing catastrophic failure, they simply enter a regulated zombie state, are taken over, or are forced to merge.

Public institutions were built in the 20th century to do the exact opposite of a startup: to deliver standardised services safely, equitably, and at scale. Their procurement rules, risk registers, and hierarchical sign-offs aren’t broken—they are functioning exactly as designed to prevent variance.

You can’t fail fast in an organisation where the remit is to move as slow as possible to ensure compliance.

The challenge of modern organisational design isn’t teaching people how to brainstorm. It’s figuring out how to surgically alter that DNA so highly localised innovation can thrive without collapsing the stability of the whole system.

The Immune System Response: Why Good Ideas Die in Committee

To understand why public services struggle to adapt, look at them biologically. Centralised compliance structures—procurement, HR, and IT protocols—aren’t designed by bad actors stifling creativity. It’s simply the organisational immune system doing its job.

An immune system maintains homeostasis by neutralising anomalies. In legacy institutions, homeostasis is standardisation; variance is the anomaly. When a frontline team attempts something radically different, the bureaucracy doesn’t see “innovation.” It sees a pathogen. And the immune system attacks.

Imagine a cross-functional team embedded in a specific neighbourhood. They identify a hyper-local problem that standard models can’t fix and design a contextualised solution. Operationally, the idea is sound. Administratively, it is dead on arrival:

• Procurement: The local supplier isn’t on the multi-year approved framework.
• IT: The department refuses to sanction the lightweight software needed because it doesn’t integrate with legacy tech.
• Risk: The committee flags the sustainability of a small local supplier.

The innovation suffers a slow, quiet death by a thousand forms, ground down in committee meetings until it perfectly resembles the legacy process it was meant to disrupt.

This creates a dangerous feedback loop. The system learns nothing, but the frontline team learns a harsh lesson: variance is punished with friction. Their rational response is to stop trying and retreat into box-ticking compliance. With no permission, the best people will leave over time.

Building an Architecture of Permission

What we need to build is a new architecture: an architecture of permission.

This means redesigning the administrative plumbing to encourage frontline adaptation. Instead of telling employees to “be innovative,” leaders must dismantle the structural blockers. We must shift from mandating specific solutions to engineering boundary conditions where local, place-based teams have the freedom to solve complex problems.

They don’t need to submit ideas to a centre. They have permission.

Three Examples of an Architecture of Permission

1. Outcome-Based Procurement Rigid, 100-page central specifications freeze out agile suppliers. An architecture of permission instead buys outcomes and delegates budgets locally. This gives the frontline explicit permission to partner with non-traditional local vendors or charities that a central compliance framework would usually reject.

2. Delegated Risk Registers Central risk committees view any deviation as a threat. An architecture of permission pushes risk authority down. Place-based teams are granted a ring-fenced “safe-to-fail” budget, requiring sign-off only from their immediate coach. This localised risk register prevents the immune system from killing the idea before it’s tested.

3. Role Fluidity and Dynamic HR Traditional job descriptions are rigid, punishing “mission creep.” An architecture of permission rewrites these roles for flexibility. Management might allocate 20% of frontline time for community brokering, ensuring staff have the systemic cover to solve the actual problem in front of them, not just the one in their job title.

We will never turn a statutory public service into a Silicon Valley startup, and we shouldn’t try. We don’t need a 90% failure rate; we need safe, equitable, and stable services.

But stability doesn’t have to mean stagnation.

By intentionally designing an architecture of permission, we can selectively suppress the organisational immune system exactly where it is needed most.

We can finally give frontline teams the systemic cover they need to solve hyper-local problems, proving that you don’t need to break the entire institution to rewrite its DNA.

Photo by Braňo on Unsplash