Lessons learned from building a government service

Last year, I was fortunate enough to spend some time with MHCLG as the technical lead on a project to replace the ageing Energy Performance of Buildings Register. Kev Keenoy has written a good summary of the work. The project is now live and serving citizens across England, Wales, and Northern Ireland.

I’d worked in government before, but this was the first time I got to see a central government project through from inception to go-live. I held a personal retrospective to capture some important feelings that I wanted to explicitly write down somewhere.

Here are my main (entirely unoriginal) thoughts, which might be useful to people taking on their first digital leadership position in the UK government.

Policy as urban legend

I spent a lot of time worrying about policy that didn’t exist. That sounds mad, but I suspect there are many teams in government doing the same thing.

It helps to understand what people mean when they say policy on a digital government team. They can mean a number of things:

• Legislation passed by parliament
• Secondary legislation
• Documents that make some sort of commitment to internal or external stakeholders.

I think it is easy to assume that the things people tell you are policy are mostly legislation, but when you dig into it they are often just internal documents. Policy documents can be found to articulate any number of decisions that you might assume would be too low level for somebody concerned with “policy” to care about. Actual examples of real policies I have come across in the wild are:

• What members of staff will wear in citizen facing roles.
• That there will be a “button” on a page allowing the user of the page to filter their search results.

In short, they are the artefacts from the Civil Service’s unique culture of making decisions through essay writing contests. The upshot of this is that many of the things I assumed were intractable restrictions turned out to be easily-ish overturned.

Additionally, many of them simply didn’t exist. People will tell you with full confidence that a particular policy is restricting your choice in some way: it is your team’s job to figure out exactly what they are talking about, because sometimes the trail runs cold and you learn the policy is an urban legend.

I first noticed this when GDPR was introduced, I was working for a different part of the government (which I won’t name) and senior people would confidently make absurd statements about some particular implication of GDPR on our work. Those are repeated in meetings and emails and start to take on a life of their own.

Compliance is important for government teams, it’s a line you can’t cross, but cultures of compliance have a nasty habit of weaponising knowledge of policy to avoid important decision making. Not always, but occasionally, you’ll find that “it’s policy” is the government equivalent of “they’re the requirements”: a phrase which Jeff Patton observed really means “shut up”.

Service owner as sceptic

We started the project without a full time service owner, but when one joined it made a massive difference. Having a service owner who understands that some policies don’t exist and how policies that do exist can change is the only way around this. Our service owner knew this and cut short our journey into a number of rabbit holes that would ultimately have sabotaged launch had we pursued them.

I now see a good service owner as being like Adam Connover from Adam Ruins Everything. They must be the person who knows the facts and isn’t afraid to introduce them, even when it’s socially inappropriate. A well timed “Actually, the legislation only says…” is priceless.

The service owner needs to help you pick your battles. If I could change one thing about the project at MHCLG, it would be to fill the service owner role right from the beginning and frame the whole thing around a realistic timeline of decision making and political challenges.

Keep expectations high

You can build high performing engineering teams in government. Contrary to popular belief, you do not need scores of engineers with glittering CVs and a truck full of venture capital to achieve all of the things that we know work.

My team was a small team of mixed seniority, the type of experience mix that you’ll easily find in every government department. They built a process that could release to production 50 times every day, where the lead time (between committing code and that code being used by an external user) hovered below 15 minutes, where all infrastructure was defined in source code and completely replaced on each release. Stories went from being accepted to being completed in predictable time frames. The team was consistently open about their own abilities and performance, and had each others backs.

I’m extremely proud of how we managed to do that with an unremarkable budget and a team with multiple junior members.

As I entered the orbit of the civil service, I was told multiple times that none of this was possible. Because of more mythical policies about how crucial pull requests are (they aren’t), but even worse because of a perceived skill gap between the public and private sector.

But the highest performing teams don’t work well because they self select for prestige, they work well because they create the conditions where actual people who exist in the real world can safely achieve more.

I’ve got opinions about what high performance looks like (continuous integration, test driven development, intense collaboration, diversity, safety in software changes, psychological safety, outcome driven, empathy, etc.) — but I don’t really want to make this into generalised advice about what high performing means.

I do want people to have the confidence to fight back against excuses for low expectations and aim for something that lets people experiment and get better results. I’m grateful that Made Tech (my employer at the time), gave me the freedom to pursue this without compromise.