If You Want to Manage Change, Learn How to Manage People
It's not rocket science — it might be harder
If you've been wondering why Elon Musk is having such a hard time managing Twitter, he's trying to drive change before learning to manage people.
During change, people tend to be more challenging to deal with. That's because they are anxious — and they are anxious because they are uncertain.
When faced with the unknown, we often "fill in the blanks."
When imagination takes over, reasonable people may become irrational, unpleasant, and uncooperative. The same known and trusted colleagues you've grown fond of over the years may suddenly act like children — questioning and sometimes even sabotaging efforts to effect change.
This article is based on 40 years of experience making change happen in various industries of varying sizes — private and publicly owned. In every case, managing fear and anxiety was a key factor in my successes — and failing to do so was, in hindsight, the key to my failures.
During those 40 years, I held jobs ranging from Business Manager to Sr. Operations Analyst. In every job, advocating for change became the most challenging and rewarding part of my job.
Here is what I learned.
People resist change for a reason
I realize this is not a big "aha!" for most of you. But I start here because the first challenge in managing change is to make a clear case for it. CEOs, directors, and managers who try to implement change by fiat miss this.
When changes are implemented before the people affected can process the implications, they will almost certainly backfire. Too often, the blowback isn't related to the change itself; rather, it's a natural human reaction to being ignored or dismissed.
This happens when changes are based on a business rationale without considering the people who will ultimately be tasked with implementing the change. Yet the personal reactions to proposed changes will determine the success or failure of whatever change is being deployed.
If you look back on failed attempts to implement changes where you work, you've probably seen what I've seen. Poorly managed efforts at change management inevitably lead to damaging behaviors. For example, some people will refuse to buy into the change and will sabotage the effort. Others might become resentful when their input is only considered after the change is implemented. Finally, some may question the validity of the change itself.
Both business and personal perspectives should be considered to avoid the pitfalls outlined here.
The business case
The four main points to consider from a business perspective before implementing change are:
It must solve a specific problem.
It must result in a specific outcome with measurable results.
It must benefit some, if not all, of the people required to deploy it.
Finally, the benefit of deployment must outweigh the cost of deployment.
The personal perspective
The two main points to consider from a personal perspective are:
Employees involved in implementing the change must believe it will be beneficial in a way that's meaningful to them.
Employees must believe the extra work required to make the change is worth it to them.
Once you know the criteria you must meet, you'll need a solid rationale for the change.
The rationale for the change
Why are we doing this? Good ideas are easy to come by. Good ideas that solve specific problems — not so much. Sometimes it's necessary to break down exactly what the problem is, and often it's not apparent.
When I worked at Dolby Labs as a Sr. Operations Analyst, I interviewed a lot of engineers to find out what went wrong when we ran into problems with technology we had already released. Unfortunately, sometimes it felt like pulling teeth to get people to talk about what led to the issues because people were reluctant to "point fingers."
The first challenge for me was to engage with them in a way that did not feel threatening to them. I would often find myself saying something like this: "I'm not here to find out who did something wrong — I'm here to find out how we can improve processes that lend themselves to human error."
See what I did there? I clarified that the problem is not the people — it's the process. This diffuses the kind of defensiveness that can block open communication.
Once people are willing to talk, providing a framework for the discussion is helpful. A favorite of mine is a set of questions known as the 5 Whys.
Here is how it works:
Frame the problem, then ask why it happened. Then, ask that same question again for a total of five times.
If, for example, your car won’t start, this is how you’d use the 5 Whys:
Why? — The battery is dead.
Why? — The alternator is not functioning.
Why? — The alternator belt has broken.
Why? — The alternator belt was well beyond its useful service life and not replaced.
Why? — The vehicle was not maintained according to the recommended service schedule. (A root cause)
And there you have it! In this case, had the vehicle's owner followed the recommended service plan, this problem would likely have been prevented.
While this example may seem overly simplistic, it's good for teaching the methodology. You may even use it for the same problem multiple times. The beauty of this exercise is that it focuses on the operational issue you need to address.
As you do this exercise, try to keep the following key ideas in mind:
Answers should be backed by facts and data whenever possible.
Look for causes step-by-step; don't jump to conclusions.
Assess the process, not the people.
Specificity is key. Don't settle for "human error" if the cause was forgetting a step; use the 5 Whys again to discover why that step was missed.
If you lacked resources, what caused that problem? Don't stop at "not enough resources."
Be open to finding multiple root causes.
Focus on learning what happened (and why) rather than placing blame.
You will only find the solution if you understand the problem. This exercise can help you understand where you are now — then, you can start to envision solutions.
Designing the solution
Who knows the most about this issue? Who is in the best position to design a solution?
When we designed solutions at Dolby, we talked to a lot of people. This is because we needed to see the problem from the perspective of people with various roles in the organization so we could systematically address all the potential areas our solution would touch.
Our goal was to ensure that anyone seeing the change would be ready for it. We also wanted to ensure that everybody involved in implementing the change was on board before we committed to it.
One approach we used was enlisting a team to brainstorm solutions. Sometimes it was hard to get a commitment even for an hour a week, so as the change manager in this scenario, I made commitments to the people I enlisted to help me.
Here is what I promised them:
I'll handle all the scheduling and provide an agenda at least 24 hours before each meeting.
I will only ask people to devote an hour per week to the cause.
I will spend my time between meetings conducting the research I need to follow up on any business the team agrees upon.
If needed, I will take responsibility for securing funding to implement the solution we develop together.
Their sole responsibility would be to honestly answer questions and use their unique knowledge about the issue to contribute to the solution.
When I first attempted to recruit a team to help me, I heard a lot of excuses for why people couldn't participate. The list above was designed to address all of them — and it worked.
Eventually, I enlisted a team that included Application Engineers, Product Managers, Program Managers, and Platform Architects from Dolby's audio and vision teams.
When it was time to implement the solution we came up with, everybody was on board. Each team member then became an ambassador for the change — communicating with their colleagues to ensure no one was blindsided by it.
Implementing the solution
Unfortunately, implementation took much longer than it should have due to a single person who chose to override the team's decision.
She refused the money I'd worked diligently to secure for the upgrade and insisted the work be done in-house — by one of her people, in his 'spare time.' As a result, what SalesForce had committed to completing within a month took over a year.
She ruled by fiat.
Still, when I left the company in 2020, the implementation and the training we designed to roll it out were complete. I was, admittedly, editing the final training modules on my last day of employment, but I made it happen.
The takeaway
Change management is complex because people resist it. Breaking down that resistance takes work. If you don't want to manage people, you will not be successful in managing change.
And even if you are willing to do everything outlined in this article, you will encounter obstacles. Still, if you are ready to do the work and don’t leave the success of your endeavor to chance, you can succeed.
The bottom line is simple — not easy — but simple: If you can manage people, you can manage change.
Now the real question is: Do you want to?