This was originally posted on the Government technology blog
A short while back I was fortunate to speak at GitHub’s annual Universe conference in San Francisco. GitHub is a tool we use extensively at GDS and it was good to be able to talk with other customers, share how we’re using the product, and discuss the future product direction with their core team.
I was asked to tell the story of GOV.UK and that’s what most of my talk covered. Starting with Martha Lane Fox’s report, the alpha version of GOV.UK and the story from there. I was keen to emphasise a number of points.
Starting small
When we start out trying to do something big, we often think that means we need to start with a big team. You may eventually need a lot of people to make a big change but successful delivery starts with teams that know and trust each other.
The reason that we were able to move fast was that we started small and built trust in the core team before we scaled up. We were able to prioritise trust and the team’s sense of responsibility (to each other and for the work) before working out the co-ordination and governance challenges that come with a bigger team.
Trust, users, delivery
The GitHub audience was naturally interested in our decision to code in the open. Preparing for the talk I’d tried to find some record of the moment that we first started developing GOV.UK code in the open but couldn’t find any, which shows what a simple decision it was.
This was partly because we had a mandate to do things differently, but fundamentally it was because we were working in a high trust environment where the team understood our responsibility and those sponsoring the project trusted us to act accordingly.
When decisions of that sort need to go through multiple layers of sign-off radical change rarely happens, but when teams are trusted significant changes become almost unremarkable.
Getting close to users
Our former colleague Tom Loosemore’s tweet defining digital has been cited continually since he posted it, and this talk was no different.
While some of the biggest challenges in making government work for its users lie far deeper into the system, it’s no accident that we started with a website.
To really reform the deeply embedded culture, practices, processes and technologies of a large organisation you need to get close to your users. You need to go to them with high quality user research, but a website is the primary way that the majority of people now come to you and is an incredibly valuable source of data about what they need and value. As a website, GOV.UK laid out a new vision for what interaction with government could be, and for how we could meet that across our internal silos. Change that’s worth making works from the outside in and GOV.UK was the first step on the way.
Professional responsibility
Having touched on trust and responsibility when introducing opening our code I want to dwell on that point. A sense of broader responsibility is something that naturally comes with the civil service values and public service ethos but there are some areas in which it’s worked out that might be of particular interest to the sort of tech audience that was at the conference. Reflection on responsibility is vitally important as technology professions dominate so much of how the modern world is evolving.
I started with the responsibility to put accessibility over exciting technologies. In an industry so dominated by new JavaScript frameworks and fascinating new techniques it can sometimes feel like we’re constraining ourselves with the very simple interaction patterns on GOV.UK, but our work is more successful when we focus on what’s right for our users before satiating our own curiosity. Robin Whittleton has recently written about why we are committed to progressive enhancement (unfortunately we published just after the conference so I couldn’t reference that).
As you get deeper into transformative change you have to work on the mechanics of the system and I used work to change the security classification system as a striking example of that (and hope I was clear enough that that work was led by some of our Cabinet Office colleagues, not GDS). Those changes were vital to strip away a lot of the complexity and legend that had built up around the old system, to let us adopt new ways of working and to put more responsibility in the hands of specific civil servants and their teams.
What’s been challenging is finding the right way to bring people with us, to make sure that a change that enables the confident trailblazers doesn’t paralyse people who need more guidance or have to make a lot more decisions than they used to. This is still a work in progress but it’s vital to be conscious of that challenge if you want to make changes stick.
More broadly I wanted to acknowledge that very few of the big problems the world faces are specifically about technology. They’re about systems and people. Thinking about the technology and grasping new technologies can help us understand those problems in new ways and find other ways to resolve them, but we need to keep remembering that context.
Everything changes, and often quickly. User needs shift, our understanding of them increases, the way technology can meet those needs evolves. Most of the time our job as technologists is to minimise the cost of changing the systems we inherit or develop so that they can rapidly react to those changing expectations.
Finally
GitHub did an incredible job of creating a diverse, inclusive and welcoming event, and I’m very grateful to them for inviting me. It was particularly good to see a growing presence for public sector work at the event, with Alvand Salehi representing the US government’s new federal source code policy (which GDS provided some support with), Clarence Wardell talking about the Whitehouse’s police data initiative, and Ian Lee from the Lawrence Livermore National Laboratory talking about “developing open source in service to national security”.
Videos of all the talks, including my own, are available on YouTube.