# The Iron Cage

>  We’re making progress on the alpha, but it is slower than I have experienced anywhere else. Processes, processes, processes.

> Last updated: 2026-09-19

A few weeks on from my last note and we’ve made more progress. Last week we started our first round of testing prototypes with users and had some interesting early signals on where to focus after the baselining exercise. 

One of our partner teams launched their new national service to great acclaim, and the performance metrics look good. This has meant they’re a little more available to chat with us, and we’ve had a couple of meetings. 

It helped us realise that we don’t have a concise summary of what we’re looking at and why, with just-enough technical detail to explain what we need from them. We fixed that, and we’ve got a pithy set of slides now. We’ve also started work on the technical experiment with them, looking at a proof-of-concept data-matching algorithm which should [give teams more control of a test result](https://design-history.prevention-services.nhs.uk/managing-my-health/2026/08/how-might-we-give-teams-more-control-of-a-result/).

Instead of twiddling our thumbs while waiting for people or processes, we’ve spent time gathering a list of assumed needs for service teams, which are helping to shape other pieces of work we’ll need to do. It sparked a couple of pieces of desk research, such as looking into existing data processing policies and how other tools meet (or don’t meet) teams’ needs. 

That got me thinking about what it is we could do beyond providing consistent patterns and fixing some plumbing for teams. To improve a national service iteratively, you need detailed metrics that help you understand your users as people. Some of those feedback loops exist, but the needs for those will only grow. So we have to help teams see what’s going on.

The main thing we’ve been waiting for, though, is access to development environments and the permissions to access certain bits of kit. It’ll mean we can develop technical prototypes, giving us a better understanding of how to knit systems together. But it is slow, the slowest I’ve experienced anywhere. 

Instead of getting bored by this, we’ve also been looking at other processes we might have to go through in order to create new or change existing software. Leaning into the headwinds. Like in most big organisations, some of these have the flavour of Weber’s [‘iron cage’](https://en.wikipedia.org/wiki/Iron_cage): where formal rationality (following the process, ticking boxes on a checklist) wins over substantive rationality (making decisions based on values and principles). It’s more important that the rules are followed than whether they make sense.

But it’s all par for the course in public sector organisations. It can’t be swept away overnight, but you can find a way through and suggest where things might change.

We’re doing what we can to speed things up, but realistically we’re going to be held back by the slow processes around us. So I’m trying to make sure we use the time well, investing in research & testing to develop more and better ideas – not just validating the MVP.

The unit economics of agile and Lean working can be very efficient: mitigate some big risks, validate the core value exchange, design principles and architecture, plus the initial form of your product or service. All research and testing for later iterations can be shifted right, in favour of shipping that first, valuable version.

When research & testing is slow, plus delivery is slow, you’ve got an expensive team running below their full potential. There is an opportunity here though: we can spend more time imagining what a truly enhanced experience would be, thinking expansively about what would be best for users. I’ve noticed that many teams shave scope when meeting user needs will prove to be expensive, such as building a small piece of infrastructure. I think we need to gather evidence that makes those infrastructure decisions cheap and obviously valuable. 

Our value is in multiplier effects, so that’s where we have to focus our efforts. Data orchestration for better experiences.

Anyway, to make the cost of shipping cheaper over time, we hit upon a change we could ship that should be just small enough, just narrow enough, that we learn about all the processes without having to reason too hard for the change. It’s hard to argue against and would help around a quarter of a million people over the last 12 months. The thinnest thin-slice.

Both [Frankie](https://frankieroberto.github.io/nhsnotes/posts/week-109-near-and-far/) and [Ralph](https://ralphhawkins.co.uk/posts/weeknotes/2026-09-13-prevention-all-the-way-down/) chatted about it last week. It’s a small piece of real estate, but enough to get a foothold.

Anyway, I’m going away for a week, off to see what Georgia has to offer. Have fun.