Mike Gallagher

When people in the NHS discuss strategy, tactics, and how hard it is to change the current direction of travel, you often here phrases such as “its like trying to turn an oil tanker”, but that analogy has never sat particularly well with me. Earlier this week, Steve Messer wrote a thing that gets so much closer to what reality feels like. It is hard to reference his post without quoting nearly the whole thing, but here’s the most salient bit, logged for future reference:

Regardless of how many people are on your boat or how big it is, you need one hand on the tiller.

That doesn’t mean one person calling all the shots. Captains will listen to their crew and get feedback on the prevailing conditions. They use that information to adjust the course and turn the tiller.

[...]

Being a leader in today’s world is more like being an admiral: having influence over several boats rather than being on every one. Clear direction, clear decisions, and clear coordination.

Many hands, many tillers.

My situation is probably more akin to whatever you call the ninth in command of a small flotilla, itself part of a much greater fleet.

With contemporary, product-led ways of working, where each team is meant to be empowered and autonomous and agile and whathaveyou, trying to produce something that looks like coordinated action across a flotilla or fleet is a bizarre experience. You’ve got teams and clusters and programmes and portfolios and directorates all trying to play their part, but in the public sector you operate amidst nearly constant changes in the direction of the wind, the choppiness of the water, and the amount of cloud cover. Things tend to get blown all over the place and before you know it: mess, entropy, sunken ships.

By happy accident, I’m currently reading Cognition in the Wild by Edwin Hutchins, which, get ready: is about distributed decision making (on boats). I’m only half-way through but thus far the key concept is that, taken together, people and rules and objects can comprise a cognitive system that can be said to have its own computational power. We’re wading into actor-network theory, and going back to Steve’s post, might we think of the fleet itself as a thinking entity?

I continue trying to keep the big difficult project moving forward. This work isn’t on our public roadmap yet and it isn’t about AI or the Single Patient Record, but in my estimation it is really very important. It is also an absolute slog. If we do manage to make the thing happen, I’m not sure how much energy I’m going to have left to actually work on it.

Much of my energy right now is focussed on devising a plan for how to approach the topic, which involves identifying who should work on it, under what guidelines, and with what means. Sound familiar? Per Edwin Hutchins, it is about establishing a cognitive system – a thinking machine – by assembling and arranging the elements of a collective.

Amongst my cohort of lead designers in NHS England, we’ve discussed weeknotes and blogging a little this week. More and more people across the org are writing about their work on the internet, which is great. Between Caroline and Frankie and Irina and James and Joe and Kathryn and Matt and Max and Micol and Ralph and Rebecca and Rochelle and Sarah and Sarah and Tero and Tom and Trilly and Vero (and probably people I’ve missed; sorry!) it feels like we have a substantial public community developing around the work.

Design histories are part of this too, as are the Github issues where people document what they’re learning about how the NHS design system works in practice. Both are useful tools for shaping future decision making.

There is a sense of energy that comes from this collective publishing endeavour – so many people working in the open! There is also a sense of overwhelm stemming from the sheer volume of words being put out there – how on earth does one find the time to keep up with all of this? On Friday, Joe wrote about how he deals with this tension (he also referenced me and frankly I don’t know what to say other than it is extraordinarily nice). For my part, I don’t try to read every single thing right when they are published – it isn’t the news; it is enough to know that it is happening and that the material will be there when you need it. That and I use RSS religiously, off-boarding the act of keeping track to a machine.

All of these messages in their proverbial (digital) bottles are another aspect of trying to direct the fleet. Posting about our work online is an indirect method of steering, but I think the collective knowledge and learning that is captured is a hugely important part of group decision making. This corpus of material is another element of the cognitive system that makes up design in the public sector, multiplying and connecting the hands and the tillers.

(How’s that for torturing an analogy?)

I’m working on plans for a new round of work that will explore our general approach to designing the NHS App, our design system, and how we make use of native technology. If I’m lucky, this is going to be a major part of what I spend my time on for the rest of the year. Writing about this in public sets off a certain amount of trepidation because I don’t want to jinx anything. I’m not a superstitious person, but getting to the point where we might take this on for real has been such a long road that I don’t want to take any chances of something going wrong, be they material or cosmic.

We’re getting on the design histories train. There isn’t much there yet, but we’ve set out our intention of creating a public record of why we’ve made design decisions, and much like this very website, the mere presence of the design history site is motivation to add to it.

We’re also trialing new a set of design principles that aim to clarify our definition of what good looks like. They’re an amalgamation of various sets of design heuristics, tailored to our domain and values. They still need a bit of work, but we’ve now got a few teams putting them into action and the early signs are positive.

A discovery looking into a niche component of appointment booking concluded this week and the main thing I walked away thinking was that we can’t solve any of the challenges that have been identified whilst in our current shape. As a team dedicated to working on the NHS App, we aren’t set up to solve problems that require changes to how services work outside of the app – not by ourselves, anyway. This is one of the big, persistent issues with having a team that works on an app when said app is only ever a window into a much wider and deeper system.

When the problems that make the app less than it could be exist well outside of our area of control, whose job is it to fix them? Marianne Brierley and Jane Maber cover aspects of this issue very well in their article The space around the thing: why products alone won’t transform healthcare. They say:

The NHS environment is especially complex. It’s governed by opaque, interwoven factors – structures, behaviours, legacy systems, safety protocols, policies, culture, and people. And when those forces aren’t understood, or accounted for, even the best designed product will struggle to survive rollout.

Yes, exactly. In my team we can add an extra dimension to the challenge: we can’t even responsibly design the thing without first sorting out all of the spaces that might surround its hypothetical future area. It is a very chicken vs. egg type of problem.

Cathy Dutton published an article this week called It’s time to get serious about design that absolutely nails a lot of what I’ve been struggling with lately. The basic pitch is that now – in 2025, following on from the Blueprint for Modern Digital Government – is the time to reset what we expect from design, moving away from digitising paper processes and formulaic approaches toward something messier and more imaginative. Further, this change is the only way we (collectively) will ever be able to deliver on the ambitions set out in the blueprint.

Dutton pulls out a quote from the blueprint:

We need to holistically improve policies, business processes, data, and systems rather than on a piecemeal basis.

That sounds about right for addressing the 10 Year Plan, no? The reset being asked for mirrors some of what Kuba Bartwicki describes in What’s a good design team anyway?, specifically the note that a good design team “can ship, but can also dream”.

There are stickers proclaiming “be bold” all over the place in the office. Mostly this is the doing of the prevention services gang. Is this the responsible, considered version of YOLO? Perhaps something is in the air.

I find this declaration easy to internalise but tricky to operationalise in my current role. Most of the big bold things I want to do sit outside the team’s remit (see above). Pursuing bold ideas means coalition building to assemble and coordinate all of the many little pieces required to make significant change happen. The good news is that cross-team plans across the entirety of the NHS are beginning to come into focus, however the amount of zoom in / zoom out telescoping required to keep track of everything is rather a lot for one’s neck muscles.

Speaking of the 10 Year Plan, now that we have a collective north star, I’ve been getting involved with an ever growing number of conversations in which people ask some version of “ok so how do we fix this big systemic problem that affects all care settings?” It is too early to tell whether any of the conversations and diagrams and workshops and project plans are going to solve any of the challenges they are aimed at, but there is a palpable sense of energy in the air.

None of the topics being discussed are novel, none of the ideas being proposed have never been had before. The issues affecting the health system are well known and thoroughly catalogued (and have been for quite some time), but the level of ambition set out by recent policy documents has had a galvanising effect across the organisation that is really nice to witness. What a time to be alive, eh?

A small but important piece of discovery work that is investigating how new approaches to technology might affect the way we design is wrapping up and I’m trying to get ahead of whatever comes next. This week I was able to spend time with Sarah and Ben writing a few versions of a project brief for the next phase of work, each of which describes what we might do and how we might do it in slightly different ways. Choosing one will depend on what the final outcome of the discovery is.

We’re trying to get things in place well before the next phase so that we can secure resources and socialise the plan ahead of any work starting. The idea is that we will be able to move faster, overall, if we are well prepared for different possible futures. We have a pretty good sense of where the discovery will land, but not all of the specifics. We also don’t know how those results will be received. Taken together, the result is that this process is a little speculative, but we can play with various permutations and combinations to get a sense of how different tunings feel.

In play are the usual topics:

• what is the problem to be solved?
• what should result from us addressing the problem?
• are there any guiding principles to align to?
• what sort of team do we need?
• how much time are we going to allot to exploring the subject?
• in what order should things proceed?
• how will we know when the work is done?

Perhaps most interesting to me is that by adding or removing detail, we can make the problem space tighter or more open. We can also skew how the results of discovery are perceived by placing emphasis in different areas. This feels like one of the harder challenges for this activity: we want to give the team space to explore and find their own answers, but we also want to make sure they are able to remain focussed on solving the right problem and don’t go down blind alleys or waste too much time. Ok, fine, but how to do that without adding in too much bias or pre-conditioning?

Imagining a variety of ways to approach a problem based on different sets of drivers and constraints is a nice exercise. I suppose it is a kind of prototyping, except that instead of designing alternate versions of a component or screen or flow or service, you’re developing different descriptions for how you frame and approach a problem. It is a meta-design activity akin to writing a lesson plan for a university class, which was something I used to really enjoy (and labour over endlessly) when I was teaching many moons ago. You design a prompt that determines the context and starting point for the work, but it is up to the class or team to take it forward as they attempt to produce the intended outcome (more or less).