Change management is one of the most popular topics in business literature, and something I first encountered during my evening MBA studies while I was working at Red Hat. The most surprising thing that I learned in business school, which I continue to think of often, is the fact that so many organizational change initiatives fail (some say more than 70%; my professor said 90%), despite the fact that we have a well documented and proven formula for their success. Do 70% of leaders of change initiatives forget to read the book?
My first experience with change was when I stepped into a new role that I had the opportunity to help create: Knowledge Program Manager for our 500-person global technical support organization. Having worked on the front lines for four years, I knew we could work in smarter ways, but I had no idea how to get to a point where our workflow would enable the capture and reuse of knowledge. Our VP of Global Support, Marco Bill Peter, suggested I review John Kotter's eight steps of leading change, and by coincidence I had just started a change management course in business school that discussed the same eight steps.
Being a student, and in a new role, I took them seriously, mapping out a plan that detailed what we would do for all eight steps. Then I shared the plan with anyone who would look at it. The lesson for me was not just following the steps, but doing so in a transparent way and continually revising the approach based on feedback. This happens to be at the core of the open source philosophy: work transparently and iterate often.
I knew if that if this program was successful—if we could really change the way the majority of our associates did their work to continually capture, reuse, and improve knowledge in a searchable system rather than constantly re-solving every problem—it could represent dramatic savings for Red Hat and allow us to focus on driving next level improvements to the customer experience. But I also knew that the project wouldn't be successful if the team didn't buy into the concept, help shape its development, and have a chance to thoroughly vet the details.
Typically, a change effort can't get off the ground without executive sponsorship. Unfortunately, people often forget that executive sponsorship is just the first step; you must also have the support of the people affected by the change for the change to stick. Because the Red Hat culture involves continual (and sometimes brutal) open questioning, skepticism, and debate, we could never take for granted the fact that getting buy-in from the entire support team was a critical ingredient for success.
To explain how we approached the challenge, I'll walk through each of Kotter's eight steps and how we approached them:
- Create a sense of urgency. If the people who are sponsoring and living the change don't see a reason for it, then it can't succeed. The important thing to remember here is that you can't create a sense of urgency using the same message for different audiences. Each stakeholder will respond to different triggers. For the associates on the front lines we made it clear: if we don't change how we work, we will not be able to support the increased load from our growing customer base. We couldn't keep hiring new people in response to higher volume, so either we find a smarter way to work or we'll all go insane from the workload and eventually be unable to keep up with it. For higher-level managers the message was different: if we don't change, we won't remain competitive and we'll start to lose customers to companies putting more focus into their customer experience—or to free alternatives.
- Build a guiding coalition. Having leadership support was key here. We worked with the leadership to identify the most influential people on each of their teams around the world. We built a formal group of supporters representing every team and every region—about 25 people total. We worked with them until they not only supported the change, but were excited about it and able to convince others.
- Form the vision and initiatives. We brought our group of people together for a week to design the nuts and bolts of how the new world would work—going over every question and potential pothole. At the end of that week, we had the mechanics of our plan laid out and were able to articulate it to others.
- Enlist a volunteer army. Our group of 25 was our army, but working with them we identified a team of about 75 people that could be our first adopters of the new approach. They didn't all volunteer—some needed a lot of convincing—but we made it our mission to convert them to supporters before they officially started the new workflow. We put a line in the sand: eight weeks in the future.
- Enable action by removing barriers. Those eight weeks were critical. In that time we had to take the mechanics we had outlined and figure out how the new workflow could actually be implemented with the first team of 75 associates. We had to design the workflow, adapt the technical systems the associates used, train the associates, train the people managers to reset their expectations and definitions of success, and make sure everyone was on board. Those were long days with many late nights and a lot of phone calls with our original team of 25 people worldwide. Much of what we did during this time could be classified as removing barriers—understanding every possible objection and making a plan to work around it. This included system problems, emotional reactions, disagreements, and genuine process flaws.
- Generate short-term wins. Every step of the process is important, but this one is critical. It's also difficult and a little scary; it's the first test of the new strategy. Can you get short term wins? You have to have faith in your strategy, but also be open to a sobering truth. We set up a pilot program to test the new workflow that would give us data to demonstrate the value of the program. We were open about the process and shared the results freely—and luckily for us they were, on balance, positive.
- Sustain acceleration. We planned our pilot to last three months, during which time we communicated continuously and steadily adapted the program to to adjust for the "real-life" scenarios you can't plan for. We had created a lot of momentum, and we couldn't wait too long before expanding the pilot or we'd risk losing it. We accelerated adoption by doing a lot of communication and training for the "next wave" of the program throughout the pilot.
- Institute change. After the pilot we made a lot of tweaks and adjustments to the workflow, performed training for every team, communicated continuously about the changes coming, and "flipped the switch." On one day, literally 400 people came to work with expectations of following a new workflow. There were rough spots for sure, and it continues to be a journey, but overall it was a success and we did realize significant productivity gains.
Why did it work? I believe there were several factors at play:
- We followed the process. Kotter's eight steps, a business school classic, implies core open source elements: work in the open, build a community, continually revise and improve.
- We included associates who would be affected by the change at every stage.
- We did everything in a transparent way. That doesn't mean just keeping documents in a place where they are accessible, but proactively pushing communication and updates through multiple channels continuously—internal blogs, newsletters, visiting team meetings in person, video recordings, and video calls with associates in other offices—anything we could think of to drive awareness, questions, and engagement.
- We responded to concerns and objections. In some cases, we made changes in response to concerns, and in some cases we talked through the objections. But we addressed all of them.
- We focused on good criteria for what success looks like.
- We motivated associates to change by communicating WIIFM (What's in it for me) as individual team members). Why should I commit to this change as a team member?
Follow the conversation on Twitter #theopenorg
Comments are closed.