Skip to main content

Why we created a Platform Health team on GOV.UK

Posted by: , Posted on: - Categories: Best practice, How we work

Four members of the Platform Health team looking at a screen.

From a user’s perspective, GOV.UK is a single website, but behind the scenes things are more complex. GOV.UK is actually an ecosystem of around 50 interlocking applications, sitting on a reasonably complicated infrastructure. We created a Platform Health team to make sure that we’re looking after the system as a whole, and not just working on individual parts.

Organising our work on GOV.UK

At any one time, different teams on GOV.UK will be doing active work to add features and improve the user experience on about 10 of our applications. A multi-disciplinary ‘mission’ team will work to make an application better by delivering more value for users.

We might do this by making it easier for people to access information and describe it more consistently across the site, or through building a new interface to help publishers produce better and easier-to-read content.

This is great for enhancing parts of GOV.UK, but what about looking after this ecosystem as a whole? These other applications are relied on by millions of people and we need them to be reliable as well as improve over time.

We have a second line support team who keep GOV.UK alive day-to-day if there’s an emergency, but there are non-urgent problems that need fixing too.

Creating a Platform Health team

GOV.UK’s first solution to this challenge was to make each mission team responsible for a number of applications. In this way, every part of the ecosystem had a team looking after it.

This approach had some drawbacks. For example, teams might not know much about the applications they were responsible for, as they did not always have much in common with that team’s mission work. A team working on email notifications might also be responsible for looking after a large publishing application – 2 different tools serving different needs, running on very different code.

Working on one problem and then shifting your brain to work on another problem – known as ‘context switching’ – is quite inefficient. This approach involved lots of context switching.

This meant it was sometimes hard to look after these applications or to know how to improve them.

We wanted to:

  • get more mission work done quicker
  • provide better support for non-mission applications
  • provide operational support to teams that need developer assistance regularly, but not enough to justify a full-time developer being part of the team

So we centralised support work into a single team – Platform Health.

Goals of the Platform Health team

We outlined goals early on to help anchor what we were doing and get people excited about the new team.

These goals were deliberately quite broad and loosely defined. We were doing a new thing together and we wanted to have a clear sight of this challenge. In a changing and complex environment, leaders should align teams on intent and work out the details together. There’s much more brain power in a team than in one person.

These are the goals we came up with:

“We make sure that we’re prioritising the right types of work”

We need to prioritise proactive, long-run health improvements. Prevention is better than cure. This team brings preventative not emergency medicine (that’s what our second line team is for). We relentlessly optimise our operational processes to buy more time for proactive work.

“We know what’s healthy and what’s not healthy - and how to fix things”

This required us to think carefully about what we mean by ‘health’ of GOV.UK, and the best ways of measuring it.

“We are contributing to the platform’s architectural goals, reducing tech debt and contributing to the GOV.UK roadmap.”

We wanted to make sure that our work was as valuable as possible. This meant that it needed to align with the bigger plans for where GOV.UK is trying to get to in the future.

There was a final objective we hoped to achieve, but did not state explicitly:

“Do interesting, impressive and clearly valuable work.”

We wanted the new team to carve out a legitimate (and perhaps slightly heroic) identity, where it was clear that we were doing valuable, difficult work. This would generate some buzz and excitement around the team to help build a positive, courageous, high-performing culture, and to encourage people to join the team.

GOV.UK values this type of work

Lots of work involves caring for other people. This is often not very well paid or respected. This same cultural bias affects the way that we approach products. It’s easy to celebrate and value new things that are built or discovered. Maintaining things, keeping them working – or gently making them better – is often not very highly valued, but there is a lot of benefit in doing this.

As digital government matures (in all senses) we’ll need to get better at maintaining what we’ve built. Birthing the single domain was tough, but our work does not stop there – we need to nurture it through its lifetime.

We’re fortunate that the GOV.UK Programme team understands the value of caring and maintaining and gave us space to set up this team. If you like the sound of our culture, come and work with us.

Martin is Senior Product Manager on GOV.UK.

You can follow Martin on Twitter.

Sharing and comments

Share this page