Over the last few years, I’ve gotten very into Formula 1. For the uninitiated, F1 is essentially the top racing series in the world with the cars that kind of look like airplanes that can hit 200 miles-per-hour and hug a corner better than just about any other vehicle on earth. 

In the US, ESPN broadcasts the feed from Sky Sports, with the announcing duo of David “Crofty” Croft and Martin Brundle handling the primary race broadcast duties. In typical sports-announcing fashion, Crofty is more of the play-by-play guy, announcing the race in detail, while Brundle, a former driver, handles the “color” commentary, giving insight into what it’s like to drive a Formula 1 car at ludicrous speeds.

The best color commentators across sports typically have a few signature sayings. One of Martin Brundle’s is “ambition over adhesion” to describe a driver who goes for an aggressive move and loses the car. The point he’s making is that you can see and go for the perfect gap (ambition), but if your tires aren’t planted firmly (adhesion), it’s not going to matter much. 

Ambition over adhesion is an interesting way to articulate what happens in digital transformation. A lot of those wasted dollars are ambition over adhesion: big ideas about what’s possible that aren’t always connected to the on-the-ground realities of the organization.

The question, then, is what can you do to drive “adhesion” and ensure that your change projects land? This is something we’ve spent quite a bit of time thinking about: both in our prior lives at Percolate, where we implemented a large-scale marketing system into Fortune 500 companies, and now at Variance, as we think about how we help everyone master their tools. “Adhesion” in the form of understanding, adoption, and, ultimately, change sits at the center of our mission.

The Five Components of Change

When your driving change in any organization—whether it’s a multinational industrials company or a local elementary school—there are five critical components:

  1. Vision: The “why” of change. A broader explanation for what’s happening, why it matters, and what the long-term results will be when the change is accomplished.
  2. Skills: The “how” of change. These are the specific tactics, approaches, and knowledge necessary to deliver on transformation. They can be something as small as how to use a feature in an application, to something as large as building out a strategy and sharing it.
  3. Incentives: The “what” of change, as in what is my motivation to do this?
  4. Resources: This is the toughest of the components for people to get their heads around. It represents the network of support available to help drive the change forward. Those could be the people responsible, the tools available, and even the time at your disposal to carry out your responsibilities. 
  5. Action Plan: The timing and tasks needed to deliver on the vision. Without lining this up and making it available to everyone involved it’s hard to articulate the vision, identify the skills, find the resources, etc. … and easy to lose momentum and send yourselves back to the start (hence “false starts” as the negative outcome).

Where things get interesting is what happens as you start to put these together. What makes change so hard—and why Timothy Knoster, who brought this model to education, said that “managing significant change … can serve as a proving ground for martyrs”—is that you need to nail all five. 

Miss one, and the whole thing falls apart. But the component missing actually determines exactly how the change fails. In fact, there are five corresponding ways for change to fail:

  1. Confusion: Why are we doing this?
  2. Anxiety: How do I do this? Am I not doing my job well?
  3. Resistance: What’s in it for me?
  4. Frustration: Where is my support?
  5. False Starts: Another one?

Here’s what it looks like when you put it all together:

Having spent time talking to folks about digital transformation generally and this model specifically over the last few years, I’ve started to develop a slightly more nuanced take on things. While I absolutely think having clear answers to each of the five factors is critical, I also know that, depending on the project, one of the components may be stronger while another is weaker. This is a reality of working inside large organizations across a variety of projects. Sometimes you’ve got a strong vision but weaker incentives, while other times your skills are weak but incentives are strong. So rather than just thinking of each of these factors as a binary that is either on or off, I think it’s better to think of them as sliders: with one needing to go up if the other goes down. It would look something like this:

Now instead of just on or off, we’re trying to reach a state of equilibrium where the total effect from all the sliders is always equal. If one is off, even just a little bit, you still get the same effect as in Knoster’s original version:

But what feels more realistic to me is that you don’t always need to dial up incentives to fix that problem. Often it might be impossible, especially if those incentives are financial. So instead you may need to push up another one of your sliders to make up for the position of incentives. One particularly useful slider in these sorts of problems is vision: helping people understand the larger context for why they’re being asked to do something that they may not be directly incentivized for can help them get over that issue. By doing that we can get ourselves back into equilibrium.

The original model’s simplicity is what makes it magic and it’s something we’ve referred back to often as we’ve been in product development mode. But the reality is probably closer to the slider, where we think about how we can offset a deficiency in one area with strength in another.

Let’s Talk Specifics

Anyone who knows me knows I love myself a good model. But I also wanted to take this past just the models and make it as actionable as possible. So I reached out to a few friends who, in various roles, help lead large-scale software adoption to see what they see as the critical questions and tactics to ensure adoption of a new software system inside a large organization.

Here’s some of what I heard:

  • “Build a network of champions in each department or region so there is a distributed network of experts.”
  • “Develop a timed deployment plan that has gates and dates on any technical integrations - training of end-users and broader usage and adoption goals.”
  • “Make sure you set the right expectations with stakeholders - who need to make the project successful - about the time commitment.”
  • “Define an outcome and continuously measure (ex: 15000 weekly users after 90 days)” 
  • “Build a central hub for your documentation and FAQs.” 
  • “My standard advice is that every project is governed by Scope, Time, and Budget.  I want to go into every project understanding how these are ranked by the customer/client.” 
  • “Make sure you get senior members of the team bought in and visibly using the product to ensure that more junior members feel some pressure to adopt.”
  • “As much as you prepare, you will always need a post-launch hypercare support plan to ensure data integrity, app stability, and users are happy.”
  • “Try to create superusers early that can evangelize and communicate usage and adoption across BUs. Deputize people to work as ‘super spreaders’ in a good way.”
  • “Measure daily weekly and monthly end-user patterns and see what you need to modify in your training to increase adoption.”
  • “Define phasing requirements for the initial implementation, so it doesn't end up being a forever implementation.”

These are all great nuggets of advice, and there was a lot more where those came from, but what you’ll notice when you lay them all out is that they’re all very oriented to the right side of our framework.

It’s striking to see this so imbalanced. While some part of it is clearly about the kinds of people I asked and the question I asked them, I also think it points to the broader problem in digital transformation: it too often forgets about the people. Action plans and resources are tangible outputs for vendors, consultants, and implementation teams to produce. They represent a certain kind of work that everyone can see and point to. It’s GANTT charts and spreadsheets and FAQs (and more FAQs and more FAQs). 

Of course, the problem is that the users sit squarely on the left—driven by vision and skills over resources and action plans. It’s not to say you can have one, without the other, but the lesson of the framework is that all five are required for change to occur.


I will leave you with an analogy to how we think of power in the world of geopolitics. In the early-90s, as the Cold War was winding down and political scientists were trying to understand how the world would work when superpowers weren’t pointing nuclear missiles at one another, political scientist Joseph Nye offered up the concept of “soft power.” While “hard power” represented the ability “to get others to do what they otherwise would not,” “soft power,” Nye explained in a 1990 Foreign Policy piece was all about “getting others to want what you want.” America flexed its soft power on a geopolitical stage through its culture: exporting movies and music throughout the world. In digital transformation, this is about nailing the vision, skills, and incentives: the why, how, and what’s in it for me.

So, in addition to the excellent advice so many experts offered, I would add:

  • Communicate the project’s vision at every phase: only when you think you’ve over-communicated is when you have started to repeat yourself enough.
  • Find ways to put your users front and center: feature their success stories everywhere you can.
  • Close the skills transfer gap: make everything you do more user-centric by delivering it where they work with a meaningful context

That’s just three. There’s lots more we’ve learned along the way and are happy to share. Just get in touch.