Digital Transformation at Scale

When GDS started in 2011, mobile apps were that day’s special on the fad menu. Ministers all wanted their own. Top officials thought they sounded like a great idea. Delighted suppliers queued up to offer their services to government. We’ll talk about apps in more detail later. For now, all you need to know is that GDS blocked 99% of requests for them. Government wasn’t ready for apps, because the people asking for them didn’t really know what they were for. They just sounded good. The blogpost explaining the apps policy, written by Tom Loosemore in 2013, quickly became the digital team’s most widely read post. 16 We have seen too many chief executives and department heads proudly explain their organisation’s pioneering work on artificial intelligence, say, while in the same breath conceding their back office systems can’t reliably pay employees on time. Or running pilots with connected devices while thousands of their customers still post them cheques. This is not to say that preparing for the future isn’t right and good. Responsible leaders need to keep their eyes on the horizon. The successful leaders are those who can do this while remaining mindful their view will be ruined if they step in something disgusting lying on the floor.

To transform an organisation, you will often need storm clouds to gather. You need a crisis. In the commercial world, crises tend to focus the mind because they can be genuinely existential. Fail to respond, and all of a sudden your company name is no more than the punchline to a bad joke.

The good news is that a crisis is almost always an essential condition for digitally transforming a government, and there’s no shortage of them. The challenge is choosing the right crisis. There are two kinds that work. The better kind is something truly shocking, a failure that presents an irresistible political opportunity. These episodes are so appalling –cock-ups that hit the tabloids –that they cut through to the popular consciousness. Few voters will know or care about the intricacies of why a technology failure almost brought down a flagship policy, but they’ll remember that it did. Few people vote for visibly incompetent governments.

Nine out of every ten government projects with an initial budget of at least £ 1 billion end up spending more than originally planned. 28 As a comparative study by the Institute for Government on large and small projects notes, big projects tend to be inflexible, expensive to finance, encounter lots of opposition, hard to predict and often fail to deliver the transformation they promise.

The ideal sponsor knows that public service reform is no vote winner. However, they also know that if they wish to achieve anything of personal and political value –the reason they got into their impossibly taxing job in the first place –they need to get to grips with means as much as ends. To take the long path of changing government demands someone who understands the high cost of leaving the status quo alone. The most successful champions of digital transformation therefore tend to be ministers who have served in two or more different administrations. Most will also hold a position that can legitimately exert influence over a wide array of government business. This generally means they will be in a central department, such as the Cabinet Office in the UK or the Treasury Board in Canada. This gives them a fulcrum to interfere in the affairs of other departments –hence their need to be a politically strong figure. There is also an argument to say that the political sponsor should not be too senior. Delivering change in the face of inertia takes a lot of time and energy as well as political capital. Presidents, prime ministers and finance ministers who need to spread their resources and favours over a very wide playing field will struggle.

The disadvantage of presenting yourself as the solution to a crisis is the danger of scope creep. If you pull one thread, a hundred things begin to unravel. The interconnected nature of problems in large organisations makes it all too easy for people to put forward objections or delays. ‘Of course, you’re absolutely right that this state of affairs is completely unacceptable,’ they say, ‘but once this project is finished in six months we’ll be in a much stronger position to get started.’ The variant on this tactic is for those people to say, ‘Well, if you’re going to fix x, then of course you’ll need to fix y and z at the same time for it to be really worth doing.’ This is not a new problem. ‘Pushpin politics’ was a phrase used to describe this phenomenon as far back as the 17th century. In the more recent words of one very senior former UK official, this tactic is described as ‘collecting rocks’. It can be done forever. There is only one response to these kinds of objection, and it is an uncomfortable one. You have to ignore it. If you want to deliver change, it is imperative you set a single, clear goal of something you will deliver, preferably by a specific date.

The initial goal you set does not have to be the same as your mission. In fact, it is better if it is not. Your ultimate aim may be to save billions, improve public services for their users, and transform government. That is what inspires your political leader and attracts your team. However, your initial goal should stick to something smaller, tangible, realistic, low-risk and strikingly different from what is ‘normal for government’. Achieving momentum, however small the beginning, is essential.

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.’

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.

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.

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.

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.

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.

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.

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.

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.

The early pioneers of e-government in the UK had long said that a goal for the new GOV.UK should be to make better use of the ‘golden page’ –the final page of a transaction. In companies, the golden page had become known as the best point to cross-promote additional or complementary goods. Having experienced the jolt of endorphins that came from buying something, the end of a transaction was the place people were most likely to extend their shopping basket.

More often than not, governments and large organisations have outsourced the skills that they don’t prize as highly to consultancies and suppliers. As unloved specialists bleed out of the organisation (often in the direction of the suppliers), those organisations become progressively less well informed buyers of those specialists’ services. Before long, officials with little experience in the specialism they are buying resort to continuing arrangements with suppliers that seemed to work well enough last time, as far as they know. In the meantime, technology and the world it serves have moved on. This is how 10-year, 9-figure IT contracts of doom are born.

Agile teams work in the knowledge that the future is unknowable. The problem that needs to be solved will change over time, and so will the ideal size and composition of the team. There are really only two golden rules for putting together the right group of people. If all the people in that team are good at different things, you’re probably on the right lines. If the team is collectively good at solving different types of problem over time, so much the better. Both of these statements are countercultural to how most governments and large organisations arrange themselves. Organisational design tends to be the output of a powerful blend of inertia, power dynamics, unwritten office politics and leadership behaviour. In general, institutions operating at the scale of government organise themselves into as many silos as possible. The most visible of these are the departments or ministries, where activity is broken down into policy buckets of ever-diminishing size, like Russian dolls. On top of this is an additional layer of arrangement where people with different skills –IT, HR, economics, science, policy, and so on –are clustered together according to what they’re good at. A good agile product team must ignore both sets of walls to combine different skills (from different ministries if the product demands it) in a single team and place.

The product manager is the first among equals in the team, and the public face of the project. They define and articulate the vision for what is being built, explaining that to the team and the wider organisation they operate in. As well as being the voice of their product’s users, they must also understand the environment they operate in. They need to be able to judge the right time to come to a compromise, and when to go into battle on the user’s behalf. The product manager ultimately prioritises what get built, when. They choose what the team’s next hypothesis to test will be.

The ideal developers for an agile team working in government are those who care far more deeply about building something that works for users rather than the programming language being used. They should have an up-to-date knowledge of programming languages, but not be too concerned about using whatever happens to be the bleeding-edge code of the moment.

Depending on the project and how mature it is, different design skills come to the fore. For a small team in the early stages of building a new service, an interaction designer who can do a bit of front-end coding is gold dust –they can get you through to the point of producing early prototypes with effective visual cues while you find the right developers for the medium term. As the service touches on more dependencies elsewhere in the organisation, service designers with a view of the bigger picture become ever more valuable.

Like user research, content design was not given enough emphasis at the very beginning of the GDS.

Job titles in the digital job market evolve on an almost daily basis. In the GDS, we used this to our advantage, creating new job titles in order to differentiate more clearly the skills and attitudes we needed in the team. The differences between ‘content design’ and ‘copywriter’, or ‘engagement’ and ‘communications’, might look very subtle to an non-specialist eye, but that is the point –you don’t want to hire a non-specialist who can tick the standard job application boxes.

waterfall-based projects treated building IT systems the same way as building bridges and submarines. Gather a list of requirements first, build, test, launch, done. Waterfall-style methods can work perfectly well in controlled environments. You build a bridge because you want to go from x to y, and you build it from steel and reinforced concrete because they are the best materials. Neither of these things will change that much in 50 years. Waterfall works much less well in a landscape where people’s needs and the underlying technology are constantly changing. Agile is a rejection of applying false certainty to delivering policy with technology. Digital public services are infrastructure, but of a different kind. When they’re live, they’re just that –live, as ongoing, maintained services. Services whose users will have needs that will change over time. That means teams have to keep updating and iterating them.

Agile teams are at their best when they’re small, autonomous and self-organising units, trusted to get on with it. A good product manager will set the direction and make sure it is in tune with the wider organisation, and a good delivery manager will corral the team members to run in the same direction. From that point on, however, the team is a group of peers. The vast majority of strategic decisions are discussed collectively. Far more often than not, the role of the product manager in these discussions is to act as chairperson and referee, not despot.

For a digital team to exert enough influence to transform how a government works, the sponsoring minister must consider its success as one of her very highest priorities: number one or two. If she does not choose to spend her political capital on it when things get difficult –and is seen by the organisation not to be spending it –then those happy with the status quo will know they can see the threat of change off without too much bother.

the chances of a digital team embedding itself in the wider organisation are far higher if the political sponsor is secure in their post for several years. Anything less than three years is likely to be insufficient. The reason for this is obvious. If government ministers are transient figures, anyone with objections to what they are trying to do can simply run down the clock. Delay tactics can be deployed very easily in an organisation that on its best days moves with brick-like fleetness.

A third component of effective political cover is which department the minister is responsible for. Putting responsibility for the first digital team under a minister with a specific policy remit –like justice, say –risks boxing it off. Government departments often believe they are special, and in various ways different from their sibling institutions. Attaching the digital transformation agenda to a specific ministry allows others to say: ‘Well, that’s all well and good, but it wouldn’t work here. Tax is completely different to justice. It’s tax! Be reasonable.’ The ideal political cover, therefore, must generally come from a minister responsible for a central ministry. In the UK this was the Cabinet Office; in other jurisdictions, it is often the finance ministry or prime minister’s office. In all cases, the institution needs to have the political expectation that it can operate across departments and policy areas, and practical levers to shape departmental behaviour.

The leaders likely to most flourish in transforming government will be of the internet era, but understand what preceded it. They have changed the direction of organisations operating with significant amounts of technological and human legacy. They will have replaced old tools and old thinking without killing the company. The nature of this kind of experience implies a few other essential qualities. They will have a good working knowledge of the technology of the open internet. That doesn’t mean they have to be hackers, but they should be able to explain what actually happens when you click on a hyperlink, and what API stands for. They should also espouse the working practices outlined in earlier chapters –agile teams, iterative development, openness –and have proved themselves willing to stick by their staff when times get tough.

While the digital team is there to act as an agent of change for the organisation, that does not mean it has carte blanche to be ignorant of the current rules, much less rip up or ignore them all. If you go back to first principles, many of the most frustrating aspects of working in a bureaucracy –the paperwork, the delays, the acronyms and language –are grounded in perfectly reasonable intent. Often there are very good legal, security or moral reasons lying behind the way things are. The problem arises when wise intent is smothered by many layers of abstraction. As experienced hands within the organisation, the job of the bureaucratic hackers is to the get to the bottom of the intent behind the rules, explain this to the digital incomers, and ensure that the new teams follow them to everyone’s satisfaction. Over time, the hackers can steadily push for replacing the rules and processes for alternatives, on the basis that the digital institution has now proven (rather than just claimed) that they are simpler, clearer and faster at meeting the original intent.

Pretending that changing the way government operates is like a military campaign is a little silly, but there are some common strategic traits. Though you often hear of careless haste in conflict, strategic skill has never been associated with long delays. And claiming territory –or, to be more precise, claiming a mandate to be the legitimate decision maker on certain parts of government business –is something you have to do quickly, preferably before anyone (including yourself, sometimes) has recognised the implications.

the first 100 days is also the time for a CDO and the collective digital team to establish the peer relationships that generate soft power. Holding face-to-face meetings with all the top officials and ministers who will be key partners in the first year is a must for the new CDO. Of course, one of the best ways to win friends and influence people is to give them things they want that they’ve never been able to get before, especially if it makes them look good. The GDS enjoyed an early coup when it built Prime Minister David Cameron an app that allowed him to show off about the success of Tech City at a major conference –and by implication show that his officials were capable of keeping pace with the start-ups. Finding out exactly how to please your future trickiest customers is not a bad way of spending your first few months.

In hindsight, we shouldn’t have taken on the overhaul of so many services where the teams on the ground had limited control over the biggest choices defining the future direction of the project. Be wary of brownfield, especially early on.

Good digital work is a million silent nods of approval, not one loud round of applause.

The risk of building everything to be ready for an unknown future is that it encourages a form of dangerous perfectionism. In the early days, it is more important to build good services that ship even if they don’t translate easily into common components. A service made of near-perfect parts that never actually sees the light of day is the most imperfect service of all.

The typical bureaucratic response to scale pressures is closely related to the organisation’s relationship with risk. Bigger services with more users have higher stakes. Lots of governments and businesses try to mitigate the risks by talking them death, adding more layers of management and governance to the mix. This places a great overhead of paperwork on the team, slows down delivery and ultimately doesn’t protect from the biggest risk of all –actually making sure something useful ends up in front of users. Part of the reason why this happens is because of the divide that exists between strategy and delivery. As a service becomes bigger, absorbing more resources and reaching more users, it also becomes more important to the organisation. Policymakers who consider themselves the most important people in the room elbow their way in, often in large numbers. The voices that guided the service’s early development based on data, user insight and operational knowledge become diluted or disappear altogether. Rather than adding more management, the best way to scale digital teams is to scale the unit of delivery to cope with discrete tasks as they arise. This means replicating the product teams. As a digital service gets more complex, you should add more multidisciplinary product teams with a mix of skills and perspectives to add complementary problems. The teams should be loosely coupled, but tightly aligned to meeting the needs of the same users. Crucially, these teams will include people with deep knowledge of frontline operations who can provide insights based on reality. This is not a quality traditionally associated with the layers of management that tend to accompany the process of scaling up a service.

The chances of creating a perfect environment for changing an old, legacy-driven organisation –and holding that scenario steady in an ever-changing, event-driven world –are zero. One of the biggest mistakes we have seen new digital institutions make is waiting until they can see the very bottom of the pool before diving in from the highest board. Taking a shallow dive into murkier waters is the wiser way to go. Digital teams should feel comfortable (or at least, get used to feeling uncomfortable) with working things out as they go along. Win arguments as they arise. There is no perfect end point for a digital organisation to aspire to. In the UK government, the digital team tried to win the most important arguments that were in front of it at the time. At many times, the strategic question confronting us was very simple. Mat Wall, a GDS technical architect, summed it up: ‘What can we fix to help our teams ship better products this Friday than last week?’ Having your strategic priorities led by what is blocking delivery and meeting user needs right now (rather than some unspecified point in the future) is a good way to maintain focus. This week’s delivery niggles are a valuable source of suggestions for where to invest the efforts of the bureaucratic hackers that can fix them.

You will not be able to effect change within a government machine or large corporate body if you cannot operate levers of influence from a central position. This leverage over the various parts that make up the whole organisation, be they government departments or subsidiary businesses, is critical. The levers must allow the digital team to consistently modify behaviour and overcome inertia. If your digital institution has reached the stage of delivering new products and services relatively easily but has no leverage over the existing legacy, it is probably time to prioritise creating a stronger cross-organisational mandate.

It takes surprisingly few individuals to completely gum up a huge government machine. Not many people are obstructive for the sheer hell of it. In most cases they will have very good personal or professional reasons to maintain the status quo. When your digital team turns up to upend their position, they will hide, delay or fight. Faced with this, influence, charm and friendly wheedling may only get you so far. Teams trying to start digital institutions (especially in governments) therefore shouldn’t underestimate the value of acquiring hard powers. You don’t get many chances to ask for them, and they are much more easily removed than conferred.

knowledge transfer is a process that should go both ways. In new banks challenging the industry’s status quo (such as Monzo in the UK), teams have invested significant time in making sure their coders and designers understand the technicalities of banking, as much as they are helping the bankers get a grip on digital. Challenger banks often run internal training on banking for their web engineers for this purpose. Investing this time gives those bringing new skills into an organisation more context about the situation they now find themselves in. It also makes clearer which rules, regulations and responsibilities cannot be ignored in the interest of innovation. For a balanced multidisciplinary team to work well, both the digital and bureaucratic experts need to recognise they have an obligation to spend some time learning more about the other.

The UK government’s transaction data contained a couple of insights that prove common in most large organisations. No matter how many services an institution is running, as a general rule the vast majority of transactions take place in a relatively small number of them –the top 10% in terms of volume typically account for 90% of all the transactions taking place across the whole of government. The rest make up the ‘long tail’. Quite a lot of these will be very small indeed. The UK’s environment department receives around 10 applications a year for burials at sea, for example. For the digital team, prioritising how best to achieve the strategic ambitions for digitisation suddenly becomes more straightforward. Fix the top 10% of services, and you can deliver the vast majority of benefit to users.

In government, measuring user satisfaction picks up false signals: about how happy people are about paying tax, even about how happy they are with the government’s political performance in general. These are not things that any digital service team can do anything about. In the end, the most reliable way to measure user satisfaction was in the research lab, watching real people use the service. This was difficult to scale, but always worth the effort.

For the UK government between 2010 and 2015, austerity was the biggest game in town. It is no exaggeration to say that the economic conditions and resultant squeeze on public finances was the single biggest factor emboldening the digital agenda in government. Without it, making the political case for institutional reform would have been a much bigger challenge; good times make defending the bureaucratic status quo a much more straightforward task.

Early in 2012 two of the GDS team visited NASA in Houston. They saw the patches the astronauts designed for each mission and inspiration struck. From then on, each GDS team was awarded a mission patch for delivering a public-facing, time-bound project. They designed it themselves, including the GDS motto ‘TRUST, USERS, DELIVERY’ and featuring an animal somewhere on the patch All the patch design rules were broken. That didn’t matter. Something as simple as a few stickers (which the teams paid for themselves) created very visible signs of progress, and a form of creative expression that was owned by the teams themselves. They put in the hard work to deliver something; they could then display that effort with pride. Allowing individuals to express themselves and feel ownership of the delivery stories they played a part in is a huge part of the culture behind successful transformation.

Being a good presenter does not mean being a charismatic, articulate extrovert (these can be the most self-indulgent presenters). It means doing the basics properly. Say what you actually think. Restrict yourself to a handful of words per slide, so it can be read from anywhere in the room. One idea per slide. Plan your story from end to end. Explain what this structure is to your audience before you dive in. Practicing beforehand. Keep it short –no one has ever complained about a talk being too short.

Read www.doingpresentations.com for practical tips on good presenting, and especially the three blog posts on making presentations big, clear and bearable.

You need integration designers, front-end developers, graphic designers and service designers. Which designers the team needs depends on the service your organisation is building and where you are in the process. Interaction designers work on the interactions throughout a service. Should this form be one page or split one question per page? What’s easier for the user? They make prototypes. Front-end developers code the front-end of a website, seen by the users. The best ones overlaps with back-end developers and the designers. They have a good eye for what works best for users. Graphic designers think about the aspects of design that are perhaps more familiar; what font a website should use, or how to structure a page so it’s easy to read. They can provide a vital link between interaction design and service design. Service designers think about the whole service end to end. They can join all the parts together and often cross over with business analysts. They do this all with the user in mind.

The user need of government services often boils down to ‘I don’t want to get into trouble.’ Public services should provide that reassurance with the minimum of friction.

The service standard formalised how the GDS would apply one of its two levers of influence: domain power. As a team, the GDS had the final say about what was good enough to go on GOV.UK. As GOV.UK was the single domain for government, if you couldn’t get on GOV.UK, you effectively couldn’t run an online government service. Provided your digital team is in charge of a single domain, this domain power is a valuable lever for changing an organisation’s behaviour. However, a service standard does not have to be based around domain power. It could easily be used as a gatekeeper for determining which teams are entitled to draw down on a specific source of internal funding, for example.

It should not be for a few people in a central team to keep defining the new rules on their own –the wisdom of crowds will ultimately provide a far richer view. The role of the central digital institution as a setter of standards should evolve over time to becoming a chairperson: making sure discussions on what good looks like don’t rumble on indefinitely without coming to a decision, and curating things that capture the current version of best practice.

Without fixing the foundations first, adding yet more new technologies to the mix in a legacy organisation is a recipe for adding yet more complexity.

One indicator of an organisation’s maturity and readiness for this next wave of technologies – assuming that it already has a digital working culture in place – is how it looks after its data. If an institution knows what data it owns, makes it machine readable, and has considered the data protection and privacy issues that come with the responsibility of looking after it, it might have a fighting chance. Without those things, forget it.

Most public services are made of online and offline components that have been rebuilt or bought hundreds of times at the public’s expense. Making payments, taking payments, publishing information, progress notifications through text and email, appointment booking, licences, grant applications. How great it would be if you could build these things once and have hundreds of public organisations using them, while steadily improving the service over time.

The threat to the status quo presented by platforms is that they erode the idea of departments as the organising framework of government, and replace it with something more attuned to what users of public services expect. Some view this as the thin end of a wedge that inevitably concludes with breaking constitutional norms.

replacing the confused, duplicatory and inaccurate data architecture most old organisations sit on with ne , canonical data sources is probably even more important than the user - facing platforms. Having single, accurat , trusted sources of information for all parts of the business or government to refer to cuts out many of the mistakes and burden of data re - entry for users. For most bureaucracies, creating reliable data registers sounds like an unpleasant and near - endless job. It may take a decade to complete the transition from the patchwork of incompatible sources and false information to an architecture a digital native company would recognise as worth having. The longer it gets put off, the further you are from becoming a successful platform organisation.

Until senior officials can trust each other enough to rely on one another’s work, government as a platform cannot and will not happen.