I can’t understand why people are frightened of new ideas. I’m frightened of the old ones.
—John Cage
As with business and product innovation, unlearning also requires constraints to challenge us to think and act differently. The NHS National Programme for IT (NPfIT) in the United Kingdom is the most expensive software project failure in history, costing £12.4 billion before it was scrapped in 2011 (the original budget was £2.3 billion). Members of Parliament described NPfIT as “the worst and most expensive contracting fiasco” ever. (In fact, some officials have claimed that the final cost was as high as £20 billion since commencing in 2002.)
The NPflT was intended to transform healthcare services in the United Kingdom, digitalizing patient records, connecting 30,000 general practitioners to 300 hospitals, and providing secure and audited access to these records by authorized health professionals. The program was dogged with problems from the outset. The NPflT had a big vision and a big budget. They thought big, built big, and it became too big to fail. A multitude of suppliers, including Accenture, Fujitsu, British Telecom, and CSC, signed on to deliver the program, but when challenges struck, they all pointed fingers at one another instead of figuring out how they could work together to overcome them. Some suppliers eventually terminated their contracts, making them liable for huge sums of money for withdrawing from their projects. Yet, few of these penalties were ever recovered.
Following such a negative run of results, a small group of 30 people took an alternative approach that saved time and money. They learned to unlearn many of the behaviors and accepted thinking to seed the beginning of a radically different outcome with extraordinary results. They thought big but started small to make a systemic and lasting impact on how governments should and would deliver IT projects for years to come.
The path to these outcomes wasn’t an easy one. Not only did the team have to unlearn many of the prevailing behaviors, governance procedures, and methodologies that supposedly reduced risk and provided predictability of successful delivery, they also had to help the United Kingdom government and its civil servants unlearn outmoded information and outdated behaviors, and then relearn new and counterintuitive approaches to innovation. But that they did. They achieved numerous breakthroughs and extraordinary results in the most bureaucratic and regulated environment known to humans: government institutions.
It wasn’t by any means straightforward. But led by Andrew Meyer, a small team showed that the Cycle of Unlearning can work in the most difficult domains; in fact, it excels in them.
The National Spine—the electronic backbone of Britain’s National Health Service—is an IT infrastructure service originally developed as part of the troubled NPfIT and operated for the benefit of all NHS organizations throughout the United Kingdom. It joins together more than 23,000 healthcare IT systems in 20,500 separate organizations,1 connecting everyone from physicians to administrators to records keepers to researchers to patients themselves. The system is comprised of three main components:
• The Personal Demographics Service (PDS). This is a cradle-to-grave record containing detailed information on every patient that follows them throughout their entire life.
• Summary Care Record (SCR). This provides a summary of each patient’s medications, allergies, and adverse reactions.
• Secondary Uses Service (SUS). This supports the payment of £30 billion to hospitals in the United Kingdom. It also supports the planning of NHS services and research, providing access to anonymized patient record data to create business reports and statistics for research, planning, and health delivery.
In addition to these three main components, Spine also has a messaging function to support communication among all the different participating organizations and individuals and an identity and access management service. Users can insert a smart card into their PC or laptop, enter a PIN number, and, depending on their role in the system, gain access to information on Spine.
British Telecom (BT) had been running the notoriously fragile service for the 10 years since its inception and was coming to the end of its contract. Andrew Meyer and his team had lived through the NHS National Programme for IT, and they thought there must be a better way to approach the necessary upgrades and improvements to Spine. The timing was propitious as the UK government—burned by the previous, multibillion-pound overrun and failure of NPfIT, and armed with the extraordinarily high quotes of £1 billion to redevelop the Spine system—was looking for new approaches that didn’t hand over so much control to large private corporations. In addition, the government’s emerging Information and Communications Technology (ICT) strategy, which defined system-level outcomes for large information technology projects, put the kibosh on contracts over £100 million and emphasized the use of agile techniques and open-source technologies.
So, instead of contracting out the work, Andrew Meyer decided to try to unlearn the mistakes of the past and do the work in-house. Spine 2 was born and with it a new approach within government to product innovation. According to Andrew, this was a huge pivot in strategy and behavior for the organization, a tremendous difference from where they were. Says Andrew:
We were an organization that was for all intents and purposes an assurance organization. We went around with clipboards and checked that other people did things the way we thought they should be doing it, as defined in our requirements and contracts. If something went wrong, we would pick up the phone and say, “Something’s gone wrong. It’s not working as specified. You must fix it for us.”
Ultimately, there were three major aspects of the organization’s behavior and mindset that needed to be unlearned to initiate the Cycle of Unlearning that Andrew’s organization required to completely transform how work was done within it.
The first major shift was taking the work away from contractors and moving it in-house. While contractors had clearly not performed well in previous NPfIT projects, there was no guarantee that the government IT team would do any better.
The second major shift involved moving away from proprietary, off-the-shelf tools provided by Oracle and other industry behemoths, to open-source technologies. This approach introduced the possibility of jettisoning whatever stability and limited success the original Spine platform had gained and opening Spine 2 up to greater potential failure.
The third major shift was using a more iterative and adaptive approach to delivery instead of the big up-front design, release, and stage-gated methodology employed throughout governmental institutions. While a better outcome relative to the NPfIT initiative was virtually guaranteed, it would require a wholesale transformation in the culture within Andrew’s IT group and governmental organization.
All the unknowns made people in the organization extremely nervous, and Andrew had a very challenging time getting people to buy into the fact that the organization needed to let go of the past and unlearn to succeed. Getting past this hurdle required Andrew and his team to be courageous while facing tremendous uncertainty. Ultimately, the organization achieved extraordinary results, delivering a robust Spine 2 system that worked reliably while responding to the growing needs of its many stakeholder groups. But this individual and institutional transformation required a great deal of unlearning, and then relearning, to break through.
To begin the Cycle of Unlearning, Andrew’s purposeful, cross-functional team of 30 had to behave quite differently than it had in the past. For example, an IT contract with a large budget must go through a lengthy, internal business case and funding process which could take 18 to 24 months to get fully approved. By the time the sign-off finally occurs, there’s tremendous pressure to complete development within fixed time, budget, and scope constraints—sometimes in just a few months.
Getting around this obstacle required unlearning the old, bureaucratic system that governed large, high-cost projects, and relearning a new approach that would result in much faster, safer, and smaller steps to achieve the team’s desired outcomes. Says Andrew:
I broke the business case up into smaller chunks, which allowed me to ask for smaller amounts of money. That approach allowed us to crack on with development and exploratory work associated with the redevelopment of the Spine 2 service. When you have a big project, you need big budget, which results in a big business case that takes a long time to work through the review and approval process. We came to the realization that if we could leverage the existing system’s natural constraints, it might be more effective to think big but start small.
Andrew and his team unlearned their long-held approach to doing work and getting projects approved in big batches. They relearned that by working in small batches, it was easier to understand the work, complete it end to end, and get feedback more quickly from real users of the system. It also had the added benefit of creating a safe-to-fail work environment as no batch of work ever became too big to fail. It became simpler to scope, fast to fund, and relatively cheap to learn what worked and what did not. Each delivery increment created new information to guide next steps and demonstrated that a new way of working could deliver extraordinary results. The small steps also served to create momentum and validated that their new behaviors were achieving the intended outcomes, helping the team members to feel successful as quickly as possible. They worked within the system to unlearn the system, relearn a new one, and then break through.
By dividing the work into small business cases, Andrew and his team were able to fly under the radar to a certain extent: The projects weren’t so large that they would get the attention of senior civil servants and administrators. But Andrew’s innovative approach didn’t stay under the radar for long. Eventually, a very senior civil servant asked Andrew what he thought he was doing and gave him quite an upbraiding. During their tense exchange, Andrew responded to the bureaucrat, “I did that because that was what was needed to do to deliver this project.” His approach was working, and the civil servant couldn’t deny that.
Andrew asked the government official if he wanted him to stop what he was doing, and the bureaucrat responded simply, “No, don’t be silly. I don’t want you to stop—but don’t do it again.” This was a standard Industrial Era management mindset: You disobeyed—don’t do it again (but I’ll take the results).
This response is really no surprise from a long-serving official in a deeply bureaucratic culture such as the NHS. Even though there was clear evidence that the old system was broken and the team’s new approach was working, the first response was to reprimand Andrew for not following the status quo. Instead of asking, “You’re getting extraordinary results. How did you do it?” or “What can we do to help others adopt your approach?” the response was, “Don’t do it again.”
The easy road is to revert to old behavior and comfort when you are in the trough of uncertainty. When you’re in front of people who are putting pressure on you and your team and banging on the table, saying, “Why are you doing something different?!” remind yourself what prompted you to take that courageous first step, and unlearn. Brené Brown once said, “The middle is messy, but it’s also where the magic happens.” When you’re in the messy middle of the Cycle of Unlearning—as you are relearning new behaviors and methods, challenging the existing paradigm, and beginning to feel it might be too hard—that’s actually when you need to channel courage and accelerate your efforts to get the breakthrough you need.
There’s also deep institutional unlearning that Andrew—and anyone who dares to take an alternative path within organizations—must deal with. The majority of management teams are naturally fearful of supporting or sponsoring a new approach that may or may not work. Managers wonder what’s in it for them. If they green-light a new initiative, it could fail and take them, their rewards, and their careers down with it. The potential downside is too great. This is but another reason to start small, be safe to fail, and demonstrate the effectiveness of how new behaviors can succeed before scaling. Your small steps are the evidence that creates the confidence to secure their support.
Interestingly enough, when Andrew and his team flipped the product development model on its head by making the decision to build in-house, the team was suddenly seen as a supplier—an outsider—and the rest of the organization wanted to assure what they were doing. Andrew explained that he wanted the other parts of the organization to be part of the solution, not walking around with clipboards and checking whether they had completed their work correctly. By saying this, Andrew was trying to help the rest of the organization unlearn its governance approach by way of cross-functional collaboration instead of contract negotiation.
According to Andrew, when he was much younger, he was quick to jump to conclusions, telling everyone: “This is absolutely the way to do it.” Matthew May, author of Winning the Brain Game: Fixing the 7 Fatal Flaws of Thinking, calls this cognition behavioral pattern leaping to solutions without first clarifying or framing the problem you’re trying to solve. The manager’s instinctive reflex is, “This is how I’ve always done it—I was successful as a result, and I’ll continue to be successful by doing what I’ve always done.” But this is a shortsighted way of thinking and behaving. The conditions of the world constantly evolve, as does the situation in which the manager may have solved a similar problem in the past. In addition, there are new technologies, new ways to experiment and learn, and new ways to innovate how things are done.
To relearn and break through, the organization and its leadership must first unlearn:
• Requiring employees and teams to follow a status-quo process even though it’s broken, not longer fit for purpose, and doesn’t produce the desired outcomes
• Punishing employees when they independently take ownership of a problem and solve it
• Causing employees to work under the radar to change the system from within due to lack of support from the top
In short, the organization’s negative results are due to the bad systems of work that the leadership team has designed, implemented, and is responsible for. Leaders must relearn to co-create systems with their employees (they’re customers) that work for all. When they do, the breakthroughs and performance improvements are exponential and potentially endless.
NHS has about 1.2 million employees—that is, customers to serve—and each has different requirements, wants, and needs. There was no way that Andrew and his team could serve all 1.2 million users at the outset of the Spine 2 effort, so they scaled back their focus to a subset of users—about 10,000—and their key needs (there were over 1,000 requirements in the team’s original backlog).
As the team worked on the project, it became clear that they weren’t going to be able to deliver on schedule. So they worked with a targeted subset of users to identify what they thought were the most critical features that would make the service usable from day one, and then they focused on creating those. Other features would not be delivered on day one but would come over time.
The first unlearning is that you don’t actually need the majority of what customers tell you they want. Instead, relearn to co-create and collaborate with customers to deliver what they really need, together. Focus on a small set of needs and deliver them quickly and frequently to your targeted set of users. As they provide feedback on what they need next, respond. Work on that next set and deliver it to them in small, fast, and frequent batches. And so on.
To this day, Andrew’s team has not delivered all the functionality the original business case promised because users realized they don’t actually need the majority of what they believed they wanted. By relearning that software products and services can be delivered in small batches of work quickly and continuously after the first and each subsequent release, the behavior of the users of the system starts to change. Users saw evidence that they were getting the functionality they needed, as well as the improvements that resulted from the feedback they provided to the Spine 2 team.
Most companies need to unlearn how they engage their users and customers. Instead of waiting to engage them at the end of the process, they need to engage them early, often, and throughout the entire life of the product or service. Delivery is only complete when the system is sunset or retired, not when it is first released. When you adopt these behaviors and mindsets, you get tremendously valuable feedback from your customers and you can focus on building the features they actually need. Iterate and improve them, based on feedback from real users, in much the same way as Elon Musk and John Legere do with the products and services they deliver.
To unlearn is incredibly difficult because everything you know is the sum total of your experiences throughout your lifetime. Everything you learn is also not unquestionably good. You can learn the wrong lessons, bad habits, and flawed ideas. Unlearning bad behaviors is harder than learning them in the first place.
The key to find the best results for your situation is to introduce very small, easy-to-do, and safe-to-fail new behaviors that provide people with evidence of something working in a different way, making them feel successful with the new behavior, and enabling them to see progress toward the outcomes or aspiration they wish to achieve. Once they start to experience this new world, they build confidence in it. People cannot think their way to unlearn; they need to take action to relearn and behave in a new way to get the breakthroughs to achieve the extraordinary results they desire.
Many people assert that there are “special circumstances” and differences between them and global innovators and business disruptors such as Google, Amazon, or Netflix that are held up as examples of product development “done right.” I often hear, “We’re unique” and “That won’t work here.” That may be true, but people often look in the wrong places for the obstacles that prevent them from reaching for extraordinary results. Detractors will treat size, regulation, perceived complexity, legacy technology, or some other special characteristic of the domain in which they operate as a barrier to transformation. While these obstacles are indeed challenges, the most serious barriers are found in organizational culture, leadership, and strategy—all of which can be affected by thinking big but starting small to unlearn outdated, legacy behaviors, to relearn better behaviors, and to break through.
A highly regulated and extremely bureaucratic environment is challenging and impacts the effectiveness of people who are used to working in a more collaborative way. But as with any customer, engaging regulators earlier and more frequently can help them see evidence of good governance through the delivery of real working products instead of ticking boxes and checking lists. Stellar outcomes can be had with a small group of dedicated people who are focused on a challenge and funded by a modest investment.
In the case of Andrew and his team, instead of users not finding out what the software would look like for a year as they did under the old behaviors, the Spine 2 system showcased what they would deliver even before the team started to build it. Users had input on the design process. Instead of asking the bureaucrats to fund a multibillion-pound initiative, Andrew broke down the initiatives into tiny chunks with a much smaller and faster funding cycle—none more than £100,000.
The strategies that Andrew and his team deployed included thinking big but starting small, and then introducing new behaviors to somewhat existing routines, such as early and frequent feedback from users of their software. This information helped to inform and prioritize the team’s work—flipping their requirements questions from “Can we build it?” to “Should we build it?” Ironically, this resulted in the team delivering less, but a system that was used more by the users who helped them co-create it.
While Andrew and his team were working on Spine 2, Andrew’s boss came up to him and said, “How do you fancy doing another project on top of this?” The project turned out to be Secondary Uses Service (SUS), which among other things supports the payments and commissioning of work in the secondary care environment.
Spine 2 went live in August 2014. The identity and access management service and the SUS went live in February 2015 without any issues whatsoever—no outages. The transition from Spine to Spine 2 was so seamless that two weeks after the release, people didn’t even realize that they were running on the new service and were saying, “You are obviously late with the Spine 2 release. When will it be?” The cost savings have been considerable for the NHS. Says Andrew:
We are saving £26 million a year on all the various Spine systems. BT have on their websites that it cost them 15,000 man-years to build Spine 1. It took us just 100 man-years to build Spine 2. And we did it with a small group of people with a dedicated mission working on what really mattered to our users.
The extraordinary results didn’t end there. Spine 1 cost more than £50 million a year to run, handling 22 million messages per day sent between thousands of care organizations, ranging from large urban hospitals to small GP surgeries in remote rural areas. System shortfalls, instabilities, and crashes left users frustrated.
Spine 2 handles 45 million messages per day and accesses more than 2 billion records. Release costs are less than 0.1 percent of previous release costs, the system has been 99.999 percent available since going live, and it takes a total team of just 30 people to run it. Spine 2 has significantly reduced response times, giving the NHS back 750 working hours per day to help healthcare patients.2
As Andrew clearly demonstrated, you can do amazing things with a small, dedicated, cross-functional team whose members are clear on what their customers want, work in small batches, and ship the product in an iterative and adaptive manner. He found a variety of ways to drive the team toward the desired outcomes, using the constraints of the failing system to help it unlearn. According to Andrew, he would point to a deadline and say, “Beyond this date we will not have a Spine service unless we do something about it.” That drove the organization and detractors to focus on the desired outcomes that needed to be achieved within the available schedule. You can stoke existential crisis or survival anxiety by highlighting the limited amount of time your team has. This is much the same approach that Drew used at Capital One to drive change in that company’s systems, and that Andy Grove sensed as strategic inflection points at Intel. However, the key to unlocking endless experimentation, growth, and impact is to reduce learning anxiety within your organization.
To a large degree, Andrew believed that one of his most important responsibilities as a manager was to protect his team from the larger organization. His instruction to the team was to get on with their work, and he would make sure they had what they needed in order to deliver. It is absolutely crucial for any leader to protect the team, particularly when those above you in the organization are wedded to the old ways and fear doing something different than the status quo, even when the status quo is no longer working. Andrew could count on the protection of his boss at the time, Rob Shaw, who now serves as Health and Social Care Information Centre’s deputy chief executive.
If you want to unlearn why innovation initiatives struggle in your organization, ask the people doing innovative work who helped make them successful and who provides the air cover that enables them to break through and achieve extraordinary results. Then support them. While air cover is not absolutely necessary to engage in the Cycle of Unlearning, it is a factor that creates the safety required for it to scale more quickly.
Sometimes the constraint is a timeline. Sometimes it’s a budget. Sometimes you’re going to go out of business because a competitor is releasing a new product. These constraints and downward pressure are often a catalyst to unlearn. While all these situations are pivotal moments to unlearn, the ideal state is not to be in a situation triggered by existential threats or crises, and instead adopt the practice of unlearning regularly—habitually.
With ongoing, deliberate practice, every one of us can leverage unlearning instinctively and use it intentionally—not just when there is no other alternative or option. We can then develop a capability to solve any challenge or cease any opportunity we face simply by unlearning what is holding us back, relearning new behaviors to address it, and break through and leap ahead. This unique capability is what enables leaders to continually find new and higher levels of performance—often beyond what they initially thought possible—within themselves, their teams, and their organizations.