Mike Gallagher

I recently joined a call of a neighbouring team (hi Tom!) to tell everyone about the work we’re doing to make the NHS App more native. What we are doing, why, how it’s going to affect everyone, and so forth. I’ve done this kind of thing about 10 or 11 times now and I can do it blindfolded. But this time, I got one question that people don’t tend to ask, even though it is the most important question: how did you get permission to do this?

There isn’t a satisfying answer. Or, there isn’t an answer that makes people feel good about themselves. In an ideal world, new and hard problems are turned into projects through official processes and channels. Issues are observed in the live environment, a team does research, and then makes an argument about why the work should be pursued. This is how a lot of work is prioritised. It is a logical and methodical approach. But it isn’t how things work all the time, and it tends not to produce major leaps.

The work we’re doing now happened because someone new and very senior said some derogatory things about the app. It wasn’t a massive crisis, but it was serious – and it was an opening. I might have taken issue with the comments if I didn’t also agree. In this instance, I was able to respond, “Yes! I too think that sucks! And I know how to fix it!” because I had been thinking about those deficiencies for a good long while. It was an opportunistic seizing of a lucky moment, but one that I was prepared for.

The common aphorism for this is “chance favours the prepared mind”. A more pop-culture variation would be “chaos is a ladder”. More elaborately:

Only a crisis – actual or perceived – produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes the politically inevitable.

That this quote comes from a bad person with dangerous ideas (Milton Friedman) is hopefully neither here nor there. It is true. Serious change requires novel opportunity and preparation, together. The opportunity part simply requires patience and a degree of sensitivity to your environment – you must remain alert and ready to pounce. The preparation part is harder.

Getting and remaining prepared for potential openings that might never arrive isn’t the kind of thing most delivery environments encourage (unless you work in cyber security). Many of the places I’ve worked have an infinitely long list of small things to fix and extend, so the idea is to just keep going. But this approach can preclude the possibility of radical improvement, since amidst the day-to-day churn, it is difficult to scan the horizon for something more, new, farther away. Standard delivery rhythms don’t have a radical change-forcing function.

Most of the time, stepping out of the river of delivery flow isn’t something people can just do – not without working late or on the weekend, and I would never encourage that. This means that a different mode of work needs to be planned for and put on the calendar in order for new dreams to be dreamt. It is draining work because it is likely to amount to nought.

It wouldn’t have taken a huge change of circumstance for this whole native re-platforming thing to have never gotten started. In that world, I am deeply frustrated and maybe not even in this job anymore. But life is full of forking paths and coin tosses, and there is nothing like a minor crisis to focus the mind and kickstart change. Big new things are scary and no one wants to venture off into uncharted territory if they don’t have to. But that can result in a kind of agile stasis: small iterations that chip away at knowable problems, all of which are good but none of which makes a huge difference. To go further, to make a great leap forward, you need a rupture, into which you can plunge, if prepared.

Amidst all of the strategy and re-platforming and various bits of normal delivery things, we are trying to get better at building this app as a kind of loose federation. As I’ve probably mentioned six thousand times: everyone wants and/or needs their thing to be in the NHS App. Ok, fine, but how?

New teams are constantly asking to add a thing. Probably one new request every week. We also get new teams going “Oh hi, we’ve redesigned your home screen for you”, which rankles. Everyone thinks they can do it better. Mostly they don’t yet know what they don’t know about why things are the way they are. We could do more to help teams to understand how it all works as they are beginning to engage. Certainly. And sometimes these other teams have really good ideas that I’d like to be able to incorporate or build on. We don’t have a good process for this yet.

In an attempt to make it easier for these teams to come at the work with the right mindset, here is a list of the typical problems we see:

• teams over-estimate how important their thing is, relative to everything else
• teams believe their thing is a discrete thing
• teams can’t or won’t change their thing to benefit all of the other things
• teams don’t realise how much variation there is in the live app
• teams haven’t considered anything but the happy paths
• teams don’t know what can and can’t be segmented in the app
• teams don’t realise how messy the underlying data is
• teams come to us late, when very little can be changed

These mistakes are made so often that it is probably safe to assume that there are structural causes behind them. I’ve written about the incentives involved before. Every team here is responsible for some small domain, making it entirely natural to focus on improving that specific area. Occasionally, this works out. Most of the time, it leads to us shipping our org chart. We could publish guidance (we do, but there are major elements missing), run communities of practice (same), set up an assurance function (this too, but not for everyone), alter our structure (oh dear, please not again), or change the incentives (now we’re talking).

One challenge is that teams don’t know how changing their thing would benefit the rest of the app. That is hard analysis to do because it requires you to know about, well, everything. It mostly falls on us to do it for other teams, and we already have a version of this analysis, even if it doesn’t go far enough. Teams then need the time and willingness to act on the analysis. It is a lopsided arrangement, with us always telling other people how to change something they’ve put a lot of effort into. That’s essentially the other side of non-app teams saying they’ve redesigned our home screen.

Some people showed me the sketch on Friday about how to rework a fairly chunky bit of the NHS App. It is an area of the app that involves about six different teams, making it a contested and complicated space. The sketch is precisely the kind of thing we get really worked up about – “Hands off!”, “The nerve of these people!”, etc – but it is also a very good idea. I’d like to pursue it. Doing so without pissing off all of my colleagues might be difficult. Or not. We shall find out this coming week.

I think our typical reaction to this kind of proposal is a mistake. We’ve been dealing with the realities of assembling and running this contraption for a long time, and sometimes we really do know better. But when you’ve been in the shit for too long, it becomes hard to see new opportunities clearly. We get fixed in our ways, a kind of learned helplessness develops, and we can be a little dismissive of new ideas. The problem with criticising anyone else for wanting tight control over the thing they administer is that we – the app team – do exactly the same thing. Everyone needs to change, us included.

Physician, heal thyself.

The strategy work continues and we’ve made a first draft. It is a video. Ralph and I have been re-learning After Effects, which is a bit like playing an arcane video game with an extremely steep learning curve (i.e. I am driven to keep chipping away at a manoeuvre for many hours beyond the workday while simultaneously shouting at my computer because the game is cheating). Initial reactions to the draft have been positive, and the video is just the starting point. From here, we need to figure out how to refine and disseminate ideas while cataloguing the elements of the wider system that will need to change for any of it to become real.

During the initial phase of the project, we spoke to a great many people. From that work, two things became clear: this place is swimming in ideas for how to improve services and no one has articulated what the experience of healthcare should feel like once you put all of the pieces together.

The surprising part of the research is how there isn’t much that is surprising in what needs to be done. A lot of the concepts we are proposing through this strategy work feel really obvious to me because we’ve known what the main challenges are for ages. Research and analytics tell us the same stuff, over and over. So does a simple walkthrough of core services, e.g. why are the types of appointments listed in the app half-gibberish? Why isn’t the same health record data available at all care sites? Why do patients need an appointment just to find out what they need to do at their next appointment? The main problems are readily apparent, but most of our work is doing what we can get away with. There are loads of very obvious ideas just sitting there, waiting to be attempted, taunting us.

Given that, the natural question is: “Why haven’t we dealt with these problems yet?” The immediate answer we reach for is “Because we can’t”. The reasons for that vary enormously, from a lack of time, to an inability to change how suppliers function, to a confusion about policy intent, to poorly formed data, to competing ideas about which version to go after. Y’know: the usual.

The less obvious answer is “Because we didn’t provide the right kind of picture of what the full experience would be like”. Our plans (of which there are many) lack tangible specificity about how the details might develop into something larger than the sum of its parts. They lack a depiction of form, and while form is not everything, I increasingly think that without it you have nothing. This isn’t so different from the “no air crits” rule we had in grad school – if you don’t show a specific artefact for people to discuss, we can’t have a productive discussion because we might all be talking about different ideas and not know it.

Service designers produce lots of maps, but maps aren’t the service anyone experiences. They are good for analysis, pointing at problems, and planning. For convincing thousands of people to work on one giant problem together for a long time, maybe not so much. (Is that treasonous?) And yet I am convinced that this work is very much service design, even if it doesn’t look like it at first. The whole point is the depiction of a coordinated, macro-level design proposal that drives system-level change, which in turn produces better user experiences. So, yeah, service design as strategy.

Perhaps we assume that all of this will organically form itself into something coherent through some sort of organisational emergence. My nearly four years here have repeatedly shown me this doesn’t happen on its own. I spend unbelievable amounts of time nudging teams to consider how their bit relates to everything else, and to redesign accordingly. Plus, I’m just one person, and this approach doesn’t scale. If we are going to achieve a more joined-up system – a phrase used over and over and over here – it seems like a good idea to describe what the totality should feel like and then work backwards from there.

We have plenty of material to play with, but depicting a complete system that is working in concert with itself requires a decent amount of editorial direction. Some things must be emphasised while others take a back seat as we draw the picture of it all. I am keen to make sure everyone can see themselves in what we produce and have no interest in trampling on anyone else’s ambitions, but some choices about what is most important need to be made. A picture of everything is a picture of nothing. It is an uncomfortable place to be.

This vision also has to be sold back to the organisation, which is a little strange, since all of the ideas contained within it are the org’s own. Last week I was watching this video, in which Dan Hon says something I’ve heard variations of many times before:

The joke about consultants is that they will tell you what the people inside have already been telling you, but because they’re telling you from the outside, you’re going to listen to them.

To a significant degree, this is what I’ve spent the last five or six weeks working toward, except I’ve been doing it from a semi-funky non-team cobbled together from a few different programmes. Our hope is that by describing how the sum total experience should feel for users (patients and staff alike) we can make it compelling enough for teams to all want the same thing and for leaders to clear the way. Or, maybe we just need to make it sharp enough to provoke a reaction.

Russell Davies interviewed Tom Loosemore the other day about the various AI experiments Tom has been playing with lately, and an early exchange gets at this:

Russell: Annoying people is one of your core skills.

Tom: It’s like you got to poke the pig or the pig don’t move, you know? You got to poke the pig or the pig’s going to sleep. So, yeah, I poke.

It is a small moment, but it feels salient to this strategy work. We’re part of this massive constellation of organisations that all operate under a single brand name, all sort of moving to their own tune, but we think there needs to be more coordinated action if we are going to improve the system in a significant way. Maybe we create a video that makes the plan explicit and see if we get a reaction. Maybe we prototype how things will work so people can try it and respond. Maybe this is all a very elaborate exercise in facilitation.

The shape of data, the structure of clinical pathways, the plumbing that moves material between sites and services – they all need to change. We need the vision (in whatever forms it takes) to describe the macro-level design in a way that keeps everyone moving in the same direction for the long haul because this is going to be excruciatingly difficult. That doesn’t answer the question of how you implement design changes when you can’t directly instruct any of the individual parts or when they can choose to ignore you. Solving for that will come later. First: what do we want it all to add up to?