Unsung Heroes

Learning how to tame the change management leviathan

Before starting this essay, I wanted to see what else had been written on change management. I was soon filled with a vague sense of dread, however, as I realized just how much material is out there—an indication of how enduring a challenge the subject is. I found most of it frustrating. The truisms, “key points” and formulas often felt more like infomercials.

My experience is that change management will always be hard. It’s a process as unique as the people we encounter, and I like to think most of us are unique. Successful strategies depend on the scope of the change, the initial requirements and the existing culture. Instead of falsely proposing that change management can be painless, I will examine moments where I have experienced discomfort and help discern what is normal (or even promising) versus what is a warning sign that the project will not succeed.

If it is not, I would encourage you to immediately send that team out to spend time in the field. No meaningful change comes without first understanding the problems—understanding like that only comes from being on-site. You need to work side-by-side with teams even if they don’t want you there at first.

Is it ready?

The absolute worst thing you can do is push changes on teams when they are not ready. That smoke you smell—it’s carbonized trust. And it’s not easily regained.

Who are the changes serving?

When rolling out major changes, you need to start by identifying who the changes are meant to help. Is this change making your life or their life better? It sounds like common sense but I’ve seen this happen again and again—particularly at larger companies. Consider the challenge of getting quality data from the field:

The analyst in the central office will say:

“We need better resolution on how this market is performing. Please have the technicians log every time they do xyz task

The technicians hear:

“We don’t care about you or trust your work. Please write your name 13 times and then carefully erase the first 12.”

The change is not saving the technicians time or effort. The request was made without explaining why it’s important or how it will serve the bigger picture. Changes like these will be met with slower adoption than ones that demonstrate tangible benefits to the people on the ground. This is not to say it can’t be done, but there’s a reason why quality teams—with their love of abstract data and gag-inducing acronyms—are often consigned to the third ring of hell.

Is it actually better?

I’ve always thought the snake oil salesman has a hard job. He must create value where there is none. He may be very talented in the art of deception—but in the end, he is swimming upstream against reality. When something is obviously better, it speaks for itself and builds its own momentum. Remember the first time you watched an HD TV—did you need to be convinced that it was better? How about when you wore noise-canceling headphones on an airplane?

When you have an improvement—be it a new tool, process change or inventory system—it should be measurably better. A good exercise is to imagine yourself as a product designer and the team as your customer. If the improvement provides a better experience for your user, little convincing will be required.

Doubt your own work—in moderation. The questions you are asking yourself will be asked by others. If you’ve already answered them for yourself you will be prepared. You will know the nuances, the limitations and the areas that need additional work. This will assure those around you just how deeply you have thought everything through.

Real buy-in

Really, truly, actually standing in the others’ shoes

How different are operations from market to market? Is San Francisco really that different from Seattle—Lisbon from Leon? I’ve found that answer to be a definitive ‘Yes’ and ‘No.’ An operations manager will say she cannot adopt a change because of the unique qualities of her market. She is probably wrong. A central ops manager will say the city operations must adopt every change for the sake of standardization. They are also probably wrong.

Each perspective holds some truth—the art is getting both parties to recognize it. I really love the anecdote from Ben Horowitz about how he dealt with two teams that could not see eye-to-eye. His solution is radical and on the nose:

The very next day I informed the head of Sales Engineering and the head of Customer Support that they would be switching jobs. I explained that, like Jodie Foster and Barbara Harris, they would keep their minds, but get new bodies. Permanently. Their initial reactions were not unlike the remake where Lindsay Lohan and Jamie Lee Curtis both scream in horror.

These two teams quickly found the core to their disagreements and worked well together from that moment on. The technique may seem excessive but it speaks to the need to actually do someone else’s work to really sit in their shoes.

Our team always did all the work before telling people how to do their job. We did every task ourselves. We worked the same hours and in the same place. When we made a recommendation, it was consistent with the reality we were working in.

Surfing on waves of pushback

Most changes will be met with something between skepticism and active criticism. Therefore, don’t count on gratitude. Instead, prepare yourself for discomfort. How you deal with pushback will dictate the success of the project. Here is an example what not to do:

Colleague one:

“The [redacted] operations said they don’t want to adopt the new standard inspection process”

Colleague two:

“Don’t worry. We just need to make it clear they have no choice in the matter”

I get angry just recalling this kind of statement. Machiavellian tactics have no place in any 21st century company. Pulling the “power card” means you have failed. It’s an easy card to pull when you have a timeline and deliverables and you are being met with resistance. Don’t pull it. Remove it from your deck, rip it up and enjoy the pleasant colors when you light it on fire.

Instead, sit on it for a day. This reduces the chance you will respond to pushback with pushback. Remind yourself that it’s not personal. There is no single strategy for convincing a stakeholder. But persistence and calmness always play a part. Let your confidence in the project drive the narrative forward.

The biggest naysayers are able to become your staunchest supporters

I’ve found vehement disagreement usually leads one of two ways. Either you are being trolled, or it’s a sign they care about the subject and they have likely thought about it a lot. It’s a myth that stubborn people don’t change their minds. The one who is most vocal in their dissent, if convinced, will be equally vocal in their support.

While we were in the midst of overhauling our ebike operations across Europe, the ops manager of Berlin—we’ll call her Sam—was not impressed. By many metrics, Sam was running the best operations in the company. She had a rockstar team of technicians and a hundred reasons to be confident in her own methods.

We had three weeks to change her mind. The first week was a training academy where we introduced the concepts behind the process changes and examined case studies. Sam’s questions were surgical. She probed the edge cases and questioned each assumption. I found myself living the part of a school boy, presenting to the stern teacher, rather than the confident program manager.

I can’t say exactly when the inflection point happened. But I do recall a conference call where the general manager of Germany was raising concerns about the project. Sam spoke up, and what she said was concise, passionate and entirely in defense of the project. We had a new ally and a vocal one at that. Towards the end of the project Sam made a confession. “I worked at Daimler. You guys are better at this lean stuff than anything I saw there.”

Long term outcomes

Hero of Your Own Story

Reed Hofmen likes to say that, “Everyone is the hero in their own story.” If you want changes to last you need to find out how to help everyone win. But it also requires a sense of narrative. The change needs to have a beginning, middle and end. The challenges must be overcome and the rewards must be reaped. The more you build the narrative around the team you are supporting, the more ownership they will take in the work.

Projects that are never over

A minute ago I said that narratives have a beginning, middle and end. Forget that. A successful project needs to have an end. But a successful company is always refining, changing and improving. This requires more than the successful completion of any given project. It’s about maintaining relationships. A challenging project and an opportunity and catalyst for building bonds – long hours, tough conversations, raised voices – this is the stuff where trust and effective communication spawn. If there is one outcome that I value the most it would be to hear: “I would like to work with you again”