Where to start
Just start.
By accident or design, you’ve arrived at a moment where there is an opportunity to make some changes. There are so many things to fix. Where to begin?
There are three big challenges you face coming into any large organisation about to embark on an overhaul. The first is that some will expect you to start by fixing whatever crisis precipitated your arrival in the first place. While that seems reasonable, the crisis in question is often just a symptom of deeper problems. Solving it might provide some clues for what’s to come, but the task is also likely to be a dirty, lengthy and unpleasant process. You might spend all your political capital on the sticking plaster before you get close to the real wound. The GDS took its first steps soon after the NHS Programme for IT, an 11-figure failure, was read its last rites. The nascent digital team didn’t even try to get involved, because it would have drowned before having the chance to get started.
The second problem is that your new colleagues will say they have seen it all before. White knights flying the banner of the latest management fad are an occupational hazard for the incumbents of any large organisation. More often than not, these interlopers make lots of noise, embarrass themselves with a weak grip on the organisational ‘realities’, leave some nice slides, and disappear – and things stay much the same as they were before they turned up. In government, officials learn that ministerial enthusiasms often have a short shelf-life, and wait for the winds of change to blow themselves out. Anybody bearing promises of ‘change – for real this time’ is likely to be greeted with caution, if not outright cynicism. Change fatigue is a common problem; a sense of exhaustion experienced when an organisation is always transforming but not getting any better. ‘Digital transformation? We’ll believe it when we see it.’
Your third challenge is the deer-in-the-headlights problem. Having signed up to fix a multitude of problems, new digital institutions often find themselves greeted with a to-do list where everything apparently needs fixing right away. Security holes abound in the technology, contract renewals are arriving or already overdue, good employees are poised to walk out the door. No sooner have you stepped out into the road than several trucks are bearing down on you. Arriving as an outsider, your instincts will be screaming, ‘I must pause my plan and get on with these first!’ There are some things that probably really do need to be fixed. However, don’t forget that many of these issues will have been quietly festering for some time before you turned up, often for several years. Ironically, institutions that are notoriously slow tend to be suckers for false urgency. If the organisation hasn’t fallen over yet, there’s little chance it’s about to right now.
Confronted with a large bundle of big, urgent problems and a sceptical audience, there’s a great temptation to become purely reactive. That won’t be enough to get you past managing a decline. To get on the front foot, you must begin by setting out how you’re going to work.
Design principles
The ten design principles were one of the first things published by the GDS:
1. Start with user needs.
2. Do less.
3. Design with data.
4. Do the hard work to make it simple.
5. Iterate. Then iterate again.
6. This is for everyone.
7. Understand context.
8. Build digital services, not websites.
9. Be consistent, not uniform.
10. Make things open: it makes things better.
Lots of organisations have something like the design principles. Some call them values, or a philosophy. Unfortunately, most are awful things dreamt up in boardrooms or management away days, in isolation from the way work is actually being done by the organisation. The most important quality of the design principles was that the GDS didn’t publish or even draft them until we’d done quite a lot of designing. Writing down the principles didn’t precede delivery, they were written as a result of delivery. Moreover, they weren’t written by the ‘leadership’. They were written by a team with lots of actual designers working alongside a wide variety of other experts.
The principles sat behind all the best things the team delivered, and helped the digital team avoid the trap of being drawn into reactive firefighting. They’ve since been endorsed by the World Bank, and emulated by countries and companies all over the world. Tim O’Reilly, the driving force behind open source movement, described them as the ‘most significant piece of user interface guidance since Apple’s in the 80s’.33 We forgot them at our peril.
There are several reasons to publish your design principles. For new digital institutions, the most important is to start capturing a new approach that can work at scale for the whole of a huge, distributed organisation. In the UK government’s case, the principles were not written to replace the civil service’s own four long-established and admirable values: honesty, integrity, impartiality and objectivity. They were written to do something those values were not designed to do – provide instructions for how to actually deliver things. The original values offered a guide for how officials should provide policy advice to ministers; one of the fundamental tasks of central government. Many public officials aren’t in the business of giving advice though; fewer than one in twenty of civil servants are likely to ever meet their political bosses. The rest are on the frontline, delivering public services.
Choosing the word ‘design’ was important for the GDS. Designing services was something that the UK government hadn’t actively done for a long time. They had become passive, outsourced verbs – tasks that government officials paid companies to do on the government’s behalf. In the 15 years or so before the creation of the GDS, the UK civil service tended to see its role in terms of activities like ‘commissioning’ or ‘tendering’. The argument for using officials’ time in this way was largely explained by taking a particular view of risk. In paying companies to design and deliver public services, governments then passed on the responsibility – and therefore the risk – to them. This is intellectually satisfying, and not necessarily wrong; outsourcing can work well, especially in the business world. For government, however, practice sometimes fails to follow the theory. As the public outcry over the behaviour of outsourcers shows – G4S’s provision of London 2012’s Olympic security and IBM’s spectacular 16,000% overspend on Queensland’s health department payroll services,34 to pick two examples – it doesn’t matter if a company contractually carries the can. The fallout still ultimately falls on the ministers. In recent months, the UK’s experience with the collapse of outsourcing firm Carillion has put the issue firmly back on the political agenda. Framing the GDS’s principles as design-led was partly a statement about public servants; digital transformation meant taking some control and responsibility for delivery back into the organisation.
The design principles themselves had to walk a tightrope. Too radical, and they would be dismissed as unrealisable ideals. Too safe, and the organisation would find itself drawn into the gravitational pull of a much bigger and older institution. The ten GDS principles were selected as behaviours that are standard practice for organisations that have grown up with the principles of an open internet. They weren’t standard behaviours for government.
Few officials paid much attention to the GDS design principles when they were published. The first audience for the design principles was those outside government, peering in. The principles provided a clear signal to talented people with digital skills that the new team – and by implication the UK government – was taking this seriously. Being public about a digital team knowingly representing a new way of working doesn’t see off all the sceptics. However, it can make some cynical heads begin to give some benefit of their doubt.
A word of warning about principles. Distilling the way you work down into a handful of short statements makes it easier to explain and enthuse about building a digital culture to a large number of people in one go. However, the reality of delivering that kind of culture change in a large organisation is invariably messier than those clean messages. Those involved in drafting them at the outset know that principles have to be tempered with pragmatism. Those who join your organisation later on specifically because they admire the principles will not necessarily have an appreciation for the nuance that lies behind them. Left unchecked, this can lead to a bizarre form of ideological debate, where purist adherence to the rules inscribed on stone tablets is more important than getting the right thing done at the right time. Guard against this, and reward those who break any of your rules rather than do anything obviously unwise.
Starting small
Having told the world how you are going to go about your work, you will be in a stronger position to determine where to begin.
The first challenge for a new digital team is to prove to those watching that it can deliver something that works on the web quicker than the organisation has ever been able to manage before. This can be a relatively low bar, so your true ambition should be to produce something that is not just a little more timely and attractive, but a whole order of magnitude faster, more beautiful and of genuine value to users. The strategy for your first project, like all that follow, should be delivery.
Producing working code must be a far higher priority than writing elegant strategy papers that explain what you’re up to, defining your organisational structure or getting your office space right. All these things are important, but secondary to demonstrating things of value to real people outside your organisation. Many other teams in your organisation, be that business or government, will have proved themselves perfectly capable of writing good papers and having exciting ideas. What they haven’t done is put working prototype digital services in front of users in a few weeks, tested them, and made them better based on their feedback and other data. If you haven’t either, there’s not much point in you being there.
When we say quick, we mean quick. Quick in some organisations is a year, say, or 18 months at the outside. A working alpha version of GOV.UK was built in 13 weeks. The UK’s e-petitions service went live having been delivered from scratch in 11 weeks to a hard deadline set by parliament. These are government projects, remember. That didn’t mean those services were completely finished; all are still being iteratively improved today. All began small, simple, clearly designed and user tested. They started as good enough, rather than perfect, and got better.
Your instinct should be to put your work out in the open while that still feels slightly uncomfortable. This can be hard, especially for those working in governments. Officials often keep things under wraps until they are completely sure nothing can possibly go wrong. So concerned are they that by the time the project does see the light of day, the world has completely moved on. A successful digital team tells users very clearly that what they have created is imperfect, but that with their help it will be made steadily better. The vast majority of people will tolerate a quick, flawed attempt at improvement over no change at all, as long as those flaws are acknowledged and fixed.
There are four questions you should bear in mind when selecting your first project. The first two are about impact, the second two about risk. Your first projects should deliver tangible benefit to users while taking on little or no political risk.
How many people will benefit, and how much?
The goal of your first few projects should be to quickly introduce a small but noticeable improvement in experience for a large number of people. This might mean solving a very simple problem that the existing websites cannot. A classic example is the search query asked millions of times every year: ‘when is the next national holiday?’ In the UK, there was no easy way to find a clear, obvious answer from the government without trawling through several pages of Google. Fix it once, and fix it well. People notice.
Is this solving a common problem?
You will quickly discover that your organisation is solving the same problem many times over in different places. Ideally, you want to create services that, having met a particular user need effectively, can then be easily lifted and adapted by other teams trying to do something similar.
How institutionally complex is it?
The single factor guaranteed to lengthen how long it takes to get things done is the number of teams involved. This multiplies exponentially when those teams are from different organisations or departments. A good rule of thumb for estimating typical project durations in government is to add six months for every department involved. For your first projects, you want to avoid this tangle at all costs. Pick projects with clear institutional boundaries as much as possible, and ideally start work with projects entirely owned by your organisation.
Is it greenfield or brownfield?
A greenfield service is one built to meet a user need that is new (or at least, newly identified). There is therefore not much to think about in terms of how existing laws, norms, expectations or choices provide a guide or constraint on how the users’ needs should be met. Brownfield services, on the other hand, come with differing levels of attached expectations.
Getting involved in existing brownfield services and processes is tempting, especially when they’re clearly not working well, and are a source of political heat, public complaint or wasted money. The problem with these opportunities is that they always come with more baggage. Technology choices have been made, behaviours set. This makes everything much heavier work, and slows the pace of delivery down. After a point, there is no avoiding these; to become a digital organisation, you have to fix or close your brownfield services. That doesn’t mean you have to begin with them. If possible, start with small services that are completely new (as the early exemplar e-petition service was) or so irretrievably broken that you have a completely blank sheet of paper to work with.
Armed with these four questions, you should be able to filter and prioritise different ideas for projects. If you don’t have any ideas, various people in your organisation will be delighted to supply you with some. Be wary of taking those ideas without digging into their motivation; they may have no connection whatsoever to what your organisation’s users actually need. The most reliable source of good ideas for new digital services is usually the operational people nearest the public frontline. They will know the kinks and gaps in existing processes, and have already worked out how to route around the dysfunction out of necessity.
As a general rule for digital teams working in government, bear in mind that the quality of ideas diminishes in direct proportion with the distance a person making suggestions has from the users of public services. Some senior policy officials, in particular, have notoriously shaky instincts for what people actually need or do in reality. The exception to this rule is those ministers who are more exposed to the frustrations of dealing with the state via their contact with the public. In the UK, the regular surgeries held by ministers in their constituencies often tells them more about their department’s failings than time in the office. Hearing repeated complaints about their own ministry in person from an anguished member of the public helps focus the mind.
Relying on anecdotes for ideas is not enough, of course. Your other source of intelligence should be data. There are various sources worth exploring. The web traffic data from your existing websites is a good place to start, not least to help identify how many of the thousands of web pages maintained by your organisation are visited by almost nobody. Data from call centres is also rich with insight about what your users are failing to find out from your websites. Gathering any unfiltered information you can get on user complaints is extremely powerful too, not least because it ensures that those with access to louder megaphones aren’t given a falsely high priority. A digital team may need to get creative about getting hold of such data, because colleagues in other parts of the organisation can be decidedly reticent about handing it over, especially if they haven’t acted on it themselves. In the UK, data from the Citizens Advice charity revealed many of the government’s operational issues, some of which government officials had simply chosen not to explore.
Digital teams should use their specialist capabilities to build tools that allow them to filter and prioritise good projects. To make headway on the immense task of identifying and filtering the most important needs of a single website for government, the GOV.UK team created a web app tool called the Needotron. The Needotron allowed the team to work out which needs should be in scope, see if any could be merged, and agree which should be prioritised according to how often they were searched for.35 This helped them to narrow down a longlist of 1,800 possible needs to a prioritised list of 900. A lot of work, yes, but a much better use of time. Although the Needotron was never intended to be anything more than a fairly blunt tool, it helped neatly bring together data analysis with user needs.
Finding the right balance in applying principles to how a digital team works is forever a moving target. Different projects will need different emphasis on either marrying insights in abstract data with insight that comes from speaking to real users or finding the right mix of risk and reward when moving quickly to put working code in front of real people.
Having set out how you are going to work and what you’re going to do, you will need to find some people to do it.
Summary
34 An episode labelled ‘the worst failure in the history of public administration in Australia’, where a $6 million contract led to a $1.2 billion bill and 80,000 medical staff being paid incorrectly.