Radical How in 2 years

Within the first 2 years, the team will have shifted its focus on to how to scale up and complete a substantial national change within the lifetime of a Parliament, answering the question “Can this be done at a scale large enough to deliver the political intent?”

(Of course, sometimes, the answer will be “No.” In which case, you get a chance to stop the work early, and at a point where the cost of stopping is still low.)

After 2 years, a government with this mission will have achieved some key milestones 

Have a “team of teams” in place

By this point, the team working on the mission will have expanded beyond the initial 12-15 people into a structure formed of many multidisciplinary teams, each working on a discrete problem. Crucially, the mission will have scaled up by adding empowered, multidisciplinary teams, not by adding individual generalist people.

A core service team will continue to iterate and optimise the core proposition as it scales across the country. Additional teams will focus on distinct parts that require extra attention, such as looking at the supply chain to ensure sufficient installers are trained, and that enough heat pumps are manufactured or procured.

By this point, there will probably be a ‘dependencies’ team, making sure the work is connected to other relevant missions elsewhere in government. For example, government might also start on a mission to build a next-generation electricity grid, which heat pumps in millions of homes would rely on.

As the team scales up, there will be changes at the top too. Ministers will be reshuffled to pastures new, but civil service leadership should be more long-lasting. Consistent senior leadership is an enduringly reliable indicator of success in government transformation efforts; longevity of tenure in Senior Service Owner roles is essential. Senior civil servants will need to be given clear, positive incentives that staying in post long enough to make a substantial contribution is to their benefit, as much as it is to the programme as a whole.

Publish real-time data on performance and progress towards delivering the political intent.

By this stage, it should be easy for the mission to communicate its own progress by using automated, even real-time, data flows. In the centre of the mission team’s office space, you should expect to see screens showing the number of heat pump installations last week, last month and last year, updated daily. People would celebrate the numbers ticking past a particular milestone, rather than blandishments in a newspaper editorial.

Making this data transparent improves accountability. Not just internally, but publicly as well. The point is not so much to hit targets, but to show momentum. Being more open with the data helps outsiders get answers to questions like: “Are our decisions helping us make progress towards our outcome?” Or: “Are we moving fast enough?”

(Again: sometimes, the answer might be “No,” in which case data provides a valuable feedback loop, provoking hard conversations early. The absence of real-time feedback in most current government programmes usually means that these questions are asked too late, if at all, and the hard conversations end up being much, much harder.)

This real-time performance data forms an important part of the team’s internal governance and external communications. They run monthly ‘show and tell’ meetings with the responsible minister and other senior stakeholders to talk through the data, show what the service currently looks like for actual users, and raise any issues. The dashboard is also published openly, on the web, so that peers across government, journalists, the public and other stakeholders can see quite clearly what progress has been made, and what level of momentum is building behind delivering the mission.

Test hypotheses that relate to the successful scaling of the intervention, rather than just the core proposition itself.

Even after two years, the team won’t have fully answered all of its questions. It will know a lot about its core proposition, and about installing heat pumps in ‘typical’ homes. But it will still be testing multiple hypotheses, particularly those related to scaling nationally, and handling edge cases in far less ‘typical’ circumstances.

They will be looking for answers to questions like:

  • How might we incentivise new building developments to adopt community heating?
  • How might we ensure the training of sufficient numbers of installers per month? How many is sufficient?
  • Do we need a national public organisation for installing solid wall insulation at the pace needed?
  • How do you effectively incentivise ‘hold-outs’ - the final fraction of homes in an area who have held onto gas heating - so that you can turn off or repurpose the gas network in whole areas?

In the more typical policymaking process, there would still be attempts to answer all these and other questions - but upfront, long before the core proposition was tested in reality with anyone. A mission team applying a Radical How approach will be asking the same questions at a more appropriate time, and addressing new, unanticipated questions as they arise. The team may also be actively looking for lessons learned from similar national rollouts that dealt with hard-to-reach properties, such as the rollout of broadband services.

After two years, the team will also have tried some experiments that failed. A special advisor may have proposed a boiler scrappage scheme that didn’t really work. The team may have found the training of heat pump installers couldn’t actually be addressed quickly enough by the market, confounding an assumption they started with.

A Radical How doesn’t mean missteps won’t happen. It may even mean that more mistakes occur. But they will be far smaller, less costly and less politically consequential than the major programme failures set in train by a waterfall-style approach.

Automate the right things, for the right reasons, in the right order

All governments find the idea of efficiency and value for money appealing. In recent years there’s been a strong push towards using online channels for service delivery, and more recently still towards automation-at-all-costs (with hype about robotic process automation, for example). It’s entirely reasonable to expect that several parts of the heat pump installation journey will involve online services and automated information provision.

But years of experience in government technology and automation have taught us two important things. 

Firstly: applying a purely technological lens to mission-level problems without considering the process, cultural and organisational changes that accompany it is a recipe for disaster. And secondly: focusing on efficiency and cost-saving as an outcome in itself has a strong tendency to lead programmes to deliver the wrong service in the wrong way. Focus solely on the pennies and you lose sight of the pounds - plus the other substantial benefits that could be realised.

The excitement (and hype) that currently exists around artificial intelligence is justifiable, but several governments have already counted the costs of placing too much trust in technology without getting to grips with human reality first. Australia’s ‘Robodebt’ scheme, described as a “massive failure of public administration” by a federal court judge, led to an AUS$1.9bn settlement. Canada’s Phoenix pay system has caused CAD$2.2bn in unexpected costs and is still paying some public servants incorrectly, 15 years after it was introduced.

After two years, our imaginary heat decarbonisation mission team will be able to identify parts of the process that are reliably repeating patterns. These might be needs that crop up in 80% of cases, things that are relatively predictable. These will be ideal candidates for automation - particularly as the heat pump roll-out moves out on a national level, and economies of scale become available.

At the same time, the team will be trying to avoid automating parts of the service that still require a level of bespoke support and/or human contact in order to meet needs. There probably won’t be very many of these, but pretending they don’t exist is a false economy.

If the team tries to automate something in such a way that doesn’t adequately address the user need, it will create additional friction in the service, slowing down progress towards delivering the ultimate outcome. What’s more, mistaken automation will probably degrade the service experience to the point where it creates failure demand: people ringing up to get answers to questions a website chatbot can’t give them, for example.