A Revenue Operator's Guide to Change Management
Because you can't achieve impact without adoption
Almost any work in operations affects other people and requires their adoption or support to be successful.
You may not be trained for this—but if you’re an operator, you’re also a change manager. It’s as simple as that.
It’s core to the job
The most common change management strategy might be described as “hope for the best.”
Even when it’s included in the plan, change management is often treated as an extra—an afterthought to be tacked on to the end of a project and perhaps addressed with a bit of training or documentation.
This usually won’t be sufficient. Change management has to be incorporated into the foundation of how you operate, starting with initial planning of a project and extending well beyond the go-live date.
The impact when change isn’t managed well
What happens if you don’t manage change properly?
Best case: it will make your job and life harder, forcing you to spend time on re-work or re-enablement.
Worst case: it will cause your initiative to fail, damaging your credibility and job security.
Practical examples:
- You design a new dashboard without consulting all stakeholders. Executive leadership doesn't adopt it and continues to use other ad-hoc reports, leading to fragmented sources of truth.
- You want your sales team to start asking prospects "how did you hear about us?" so you roll out a process and some new fields. Sales doesn't see the benefit and generally ignores you. The field has a 1% completion rate.
- You roll out a new CPQ system. Despite the training and extensive documentation you prepared, reps feel blindsided, leading to general confusion, anger, and frustration when the system goes live. You find yourself under intense executive scrutiny for the impact on pipeline and forecast accuracy.
- You create a self-serve model for marketers to launch their own campaigns in your marketing automation platform. You have templated assets and clear documentation, but marketers struggle with the new process and continue to barrage you with questions. It's harder to get campaigns out the door, and word trickles up to your CMO.
- You rearchitect your lead flow to make it more streamlined, robust, and scalable. The new design is objectively superior, but some operators on your team don't understand it and now struggle to make changes that interface with it.
The last example is interesting, as it shows how even largely “technical” or internal operations projects aren’t exempt from needing change management.
Operators need to manage their own change cycles too.
Why we struggle
Few of us have formal change management training.
Also the type of people who enter operations tend to be left brain thinkers—analytical and process and data-oriented.
A poorly functioning system is frustrating, but at least it can be de-bugged, re-architected, and optimized. It’s a logical machine.
Human beings are far more complex to “debug” and often aren’t entirely logical. Sometimes they can be irrational, unreasonable, and even hostile.
The solution
I have no silver bullets for you, only insights and tactics learned over the years, usually through repeated mistakes.
Make change management a priority
It’s critical to recognize the necessity of managing change and to integrate it into our workflows.
It should be part of the discussion whenever a new project / idea / initiative is brought to the table and fully baked into the plan,
Develop situational awareness
Your change management requirements are going to be driven by your context and your project.
Regardless of the project, driving change in a young startup of five people is far easier than in a massive 10,000 person company.
And regardless of your context, implementing a small change that requires no behavior modification is different than a huge project that requires people to completely change their routines.
So as you consider any new initiative, take stock of your context and how people will be affected.
Some questions to ask yourself:
What teams and people will be impacted by this change?
Does it require an active change in behavior?
Does it affect information or systems people use regularly?
Does it impact sensitive topics like incentives, performance reporting, financial data, etc?
Is there a company “history” that might come into play? Personal sensitivities? Baggage or tension?
Practical example:
Your company's suite of products is growing in complexity, and you see a clear need to roll out a CPQ system in your CRM.
However, there was a similar initiative that failed miserably a few years ago. Many reps remember this failure and the pain it caused.
This company history will dramatically increase the change management requirements for any new attempt in this area.
Understanding and addressing concerns
There are always reasons why people don’t embrace (or even actively resist) change.
“Stages of Concern” is a useful tool to help identify and address those reasons.
It’s part of a broader framework called the Concerns-Based Adoption Model, originally designed for use in an educational context.
The Stages of Concern model how an individual moves through different attitudes towards a particular change, progressing from indifference / apathy to a focus on broader impacts and eventually to collaboration.
Here’s a table of the different stages and a typical statement associated with each (I’ve adapted them to a RevOps context, continuing with the example of our hypothetical CPQ project).
You can use this framework in a few ways.