Note: I wrote this back in February 2023 but didn’t press publish until now. Should have done it sooner.

There was a good talk run by UCL’s Institute for Innovation and Public Purpose towards the end of January that looked at why innovation needs bureaucracy. The event accompanied the launch of a book that looks at ‘agile stability’: “that in order to successfully innovate, state organisations have to move nimbly like start-ups and yet ensure stability at the same time.”

Amongst the academic chatter that, to be honest, often went over my head, there were examples shared of what that ‘agile stability’ means. Rules or principles that guide people, which I’ve written about before. Not a playbook or a step-by-step, but some guardrails that keep you on track while giving space for creativity. For innovation.

My guess is that that was the intention of the Service Standard. It encourages teams to build services in a user-centred, iterative way. A service assessment then gives teams the opportunity to tell the story of how they utilised those methods.

The thing is, despite everyone’s best efforts to avoid this and reframe service assessments as friendly reviews by digital peers, there is a culture of fear amongst service teams. And I think this stifles creativity and innovation.

I’ve been working on the GOV.UK Design System for just shy of 3 months now, and we receive frequent questions about needing ‘sign off’ or ‘approval’ to do things. For example, if you’re looking for a date picker to include in your service, the GOV.UK Design System doesn’t have one. But Digital Scotland does. So we were asked what sign-off was needed to use it.

None. You don’t need any approval.

Sure, you’ll get asked about using the design system in alpha and beta assessments, but you don’t have to. (There are many reasons why you should, but there are reasons why teams don’t.) And if you haven’t designed or implemented an accessible component, this will get picked up in an accessibility audit. But so will everything else.

What’s most interesting in this example is that the team asking about sign-off were working on a live service. Digging in to their thought patterns, they realised that there wasn’t a service assessment or anything similar to go through. They had been worried about being ‘pulled up’ on using a non-GOV.UK component, but realised there wasn’t a moment when they would be policed on this.

This is one example in a pattern of questions about ‘GDS approved’ ways of doing things. It signals a culture of fear, where people find it hard to do their job for fear of misstepping.

Another example: my service owner at NHS Digital was petrified of the alpha service assessment. They thought that if they failed the assessment, the service would be stopped. This caused them to focus more on boxes to tick in order to pass, rather than thinking about what good looked like, what our priorities should be, and how to empower teams to do their best work.

This doesn’t feel good. Constraints should encourage creativity, not stifle it. When people feel they need to tick boxes, they’re not in the right headspace to innovate. To make government services radically better.

We need to address the dogma, otherwise it’ll be damaging in the long-run. For an organisation that professes the benefits of open-working, agility, and co-design, it hasn’t done too well at creating psychological safety in the system.

The bureaucracy got too much. It has its uses, but we need to rebalance it to encourage more agility, more innovation. I don’t know how just yet – others have suggested how to rethink the phases – but I’m sure we can figure it out.