Mike Gallagher

I’m currently the lead designer for the NHS App at NHS England

Right now, I’m re-making this website as a way of trying to trick myself into writing on the internet. It is a bit of an experiment and mostly weeknotes. We’ll see.

Resisting entropy

Weeknote, w/c 23 June 2025

This past week we had the latest instalment of quarterly planning for NHS England’s Products and Platforms (the sub-directorate that the App team live in). These kind of cross-portfolio events can be tough – there is so much material to get through and so many details to try to keep in your head – but I found this particular instance of the event to be interesting, productive, and even kind of fun. My hat’s off to Trilly for running the event so well.

With the much-trailed 10 Year Plan due to be released any day now, this was was always going to be a weird event. Attempting to make plans for what digital delivery teams will do over the next quarter in these conditions necessarily involves a certain amount of guess work and an acceptance that things may get uprooted at short notice. And yet, plans still do need making to make sure the show stays on the road. We’ll see what, if anything, needs to change once the wider NHS directives are publicly issued. It is a form of meta-level agile delivery, I suppose.

The exciting part of the event was workshop on a set of themes that intersect all of our various teams, programmes, and portfolios. It took a while to figure out how to approach the discussion (definitions are hard!), but we got there in the end and I left with a sense of energy and enthusiasm for the work to come. In the current climate of change and uncertainty, this is not nothing! The group I was part of managed to make what felt like significant progress, and maybe even a breakthrough, on working through ideas that connect all of the teams represented in the session.

We discussed how a few different services are related, where we were failing to make the best possible use of what we already have at our disposal, and why. To fix this problem, the main lever we have at our disposal is how we arrange ourselves and how we define our internal boundaries. My main takeaway was that there is more enthusiasm than I had imagined for reconfiguring how our teams relate. This could in turn improve our products and services, possibly in a pretty radical way. As ever, connecting stuff is hard, but we have the right people involved. Now we just need everyone to be able to focus on the next steps for long enough to get product teams off the mark. Unfortunately, this is is a place we’ve stumbled in the past.

With so much work to do and so many priorities, staying focussed on cross-cutting work that could reshape the operating environment is extremely hard. When things get hectic (and they are often hectic) there is a natural sort of entropy that sets in, causing people to retreat to working inside their well-defined project or programme boundaries. It is a coping mechanism for dealing with mess and stress, but it needs to be resisted or nothing will ever change. We need to stay with the trouble, so to speak (no, this is not what the book is actually about).

Coming out of the planning event, my main question was what work could be stopped in order to create space for teams to think about, and then act on, the big ambitious ideas that everyone wants to go after. Stopping things we had planned or committed to in favour of trying something that might not work out is a hard sell to the powers that be. Everyone wants the delivery train to keep on rolling. I think this is one of the main reasons consultancies get brought in to explore new terrain. That makes sense, but it also means that the people with the most knowledge of how things work never get a chance to reshape their world in the ways that they’ve been thinking about for a long time. We know what needs to change, we just need space to do it.


For examples of what happens when we aren’t able to fix the routing and connect the bits, see Tom’s monthnote and Ian’s blogpost, both of which are accurate and harrowing.

Permalink

The work and your work

In praise of the personal development plan (sort of)

I know that a lot of people hate personal development plans. The process can feel artificial, forced, like a distraction. When there is always so much “real” work to do, having to periodically review some arbitrary goals you set nine months ago is no one’s priority. When modern admin systems (e.g. Jira) already involve so much pro forma data entry, filling out yet another document that no one is going to read seems like a waste of energy. When the organisation you work for is in a state of flux and people don’t know if they will have a job next year, the endeavour can feel pointless. What a drag.

It isn’t surprising to me that people feel this way. Viewed through a cynical lens, a personal development plan can seem like tick-box exercise forced on everyone by HR because it is what we’re supposed to do, for some reason. I know at least two people who prefer to work as contractors specifically because they don’t want to be bothered with this aspect of having a permanent job. The name alone makes it sound like something that belongs in a wonky Word template that will be filed away in Sharepoint, never to be seen again. And yet, this idea is a common feature of most organisations. There must be something underneath the forms and frameworks and annual review cycle that has value, right?

I think there is a better, simpler way to think about the underlying concept. It goes like this:

It is important to distinguish between the work and your work.

In this formulation*, the work is the thing you deliver for your client or your organisation: the research summary you share with your team, the design proposal you review with stakeholders, the code you commit to Github. Your work is the set of things you are learning while doing all of that: the experiments in design methodology you are testing, the unfamiliar programming language you are playing with, the new approach you are taking to engaging with peers. The work can be on fire, but so long as you are learning, things will be ok. The distinction is thus between what you deliver and what you are learning.

To a degree, this approach is baked into an agile (or just plainly iterative) approach to design and development. The work is always more complicated than we initially imagined and things don’t always go perfectly. The important part is to learn from the ways in which things didn’t go perfectly last time. We have team retrospectives for this precise reason. This concept, of the vs your work, extends the approach to cover what you as an individual want out of a career.

One of the things I love about the field of design is that there is seemingly no end to what you can learn. It is a vast space and it keeps changing. That can be daunting, but it can also be an opportunity to try new stuff. There are always new methods to try, and every method you are familiar with can be done better as well. That should be exciting (“infinity in the palm of your hand”, etc.), and I think this is what all those personal development plans that HR makes you complete are about – making space to grow beyond what the work requires; making sure your growth is seen as “real” work too. It should be a central element of my work (as a manager) to make sure that your work gets as much attention as the work.

* I didn’t invent this formulation, but I can’t remember where I got it from. My best guess is that I learned it from either Martin Wright or Lily Dart.

Permalink

An oral history of the US Digital Service

Suffice to say that things in the US have been chaotic over the last six months. One result of said chaos was the dissolution of 18F and the takeover of the US digital service, both at the hands of DOGE. (Technically the US digital service was renamed the US DOGE service, but that is just too moronic to lend any credibility to.) As an american, this act of national self-harm has made me incredibly sad.

One small ray of light: two of the people involved in the formation of the USDS (Kathy Pham and Emily Tavoulareas) have set up an oral history of the organisation. They had been working on this for a number of years and now that the USDS is no more, they’ve published it. The site that Pham and Tavoulareas have compiled is quite something. The texts go so far beyond describing the organisation itself, layering in stories of individuals and their path to public service. From their intro letter:

While there’s certainly a need to think strategically about the future, it is also critical that we understand and learn from the past, because hard-won lessons shouldn’t be overshadowed by controversy or politics.

I think it is important to tell the stories of how public sector organisations have adapted to the digital technology and ways of working. Given the propensity for UK ministries and departments to refactor themselves every few years, there is a danger that the organisation forgets how it achieved past successes, leaving the people still working there with the task of figuring it all out again. That has some resonance for me, now, given the changes coming to the NHS. I’d like to think the merger with the Department for Health and Social Care will be less chainsaw and more, I dunno, well-thought-out-org-design, but we’ll see. Certainly there are plenty of people devoting huge amounts of energy to this work. My fingers are crossed for them and us.

Permalink

Older posts: