Lessons Learned: Effective Change Management, Part 1

When it comes to developers and managing developers, their notion of change management has to do more with version control and code updates, typically the stuff that goes with release management. Yet, the term Change Management, as applied to altering the behavior of an organization, is often ignored by development folks and left to the likes of Project Management. This is a mistake because software developers and their managers engage in change management as a way of life. The dynamics of making software—everything from the choice of IDEs, to the test frameworks, to the propagation of ideas—is grist for the change management mill. Sadly, when it comes to developers and software development managers, change management, the formal practice of altering the behavior of a group of people, is often a crapshoot that loses companies time, money, employees, and customers. I know. I was one of those tech managers at the crap table, firing away edicts and emails to get things done. I messed up, a lot. And, I learned. I want to share these hard-learned lessons with you so that you can avoid my mistakes. Here they are.

1. Know the change tolerance index of an organization.
2. You only get one thing: Find your inflection point.
3. Change goes according to levels.
4. It’s a sale. Always was, always will be.
5. There are few do-overs.

It’s taken me a while to figure stuff out, mostly because, as I mentioned above, I messed up a lot. So, allow me to save you some time. This article, Part 1, covers Lessons 1-3. In Part 2, which will follow in a few weeks, I’ll cover Lessons 4 and 5.

Know the Change Tolerance Index of an Organization

Each organization has a level of tolerance for change. It’s like wood. Soft wood, such as pine, can be whittled easily, requiring a knife the is reasonably sharp, by a carver of average skill. A harder wood is more difficult to shape, requiring a knife that must be resharpened often and sculpted by a very skilled craftsman.

Small, newer organizations have a higher tolerance for change than older, bigger organizations. Think about the difference between a five-employee, incubated startup in Silicon Valley vs. IBM, a behemoth company that has been around for over a hundred years. Are each of this companies capable of change? Yes. Does each have a different tolerance for change? Yes. It’s similar to a speed boat vs. an ocean liner. A speed boat can tolerate a fast turn to the left. Slam a fast left turn on an ocean liner and it might capsize. Yet, a speed boat is not designed to withstand the perils a transatlantic voyage. One good storm and it’s all over. Change must be measured in accordance to the organization upon which change is implemented.

When going about trying to implement a change in the behavior of any organization, you’ll do well to figure out for yourself its change index number on a scale of 1 to 10, with 1 being highly accepting of change, and 10 being highly resistant to change.

Table 1 is a tool I’ve devised to help you informally calculate the Change Tolerance Index for an organization. Score each of the four questions listed in the calculator on a scale of 1 to 10. Add the scores and divide by 4. The result is the Change Tolerance Index value for that organization.

Table 1: Organizational Change Tolerance Calculator

Once you understand your Change Tolerance Index value, you can use your understanding to guide your actions toward the change you want.

You Only Get One Thing: Find Your Inflection Point

Thirty-five years ago, I taught high school students with behavioral problems. These were the students who did not want to be in school, nor did the school really want them there. But, both parties were stuck with each other. At the beginning, even getting a student to open a book was beyond a chore. It was a battle. So, here is what my old graduate school professor in Educational Psychology taught me: You only get one thing. “If you want to spend your One Thing on getting the kid to open the book, then you’re going to be fighting for a long time. There are bigger fish to fry.”

I thought about his admonition for a long time. I had to think, what is the real change I wanted in the student? Was opening the book the goal, or was there something else? There was. My real One Thing was that I wanted the student to able to engage in structured but interactive learning activities. I had to find a inflection point, one thing that would open the door to a fundamental behavioral change.

So I threw the book out and went into the kitchen. Turns out that the kid in question worked in a pizzeria after school. So, I took him into the Home Economics kitchen and asked him to show me how to make a pizza, which he did. Then, I asked him if we could make other things. He seemed game. So, we opened up a cookbook and looked for other things to make. Again, we opened up a cookbook! I found the One Thing and the inflection point. I was lucky. I had discovered the inflection point before our interactions turned into one of constant conflict and power struggles.

Fast forward thirty years.

Not too long ago, I was working with an organization of about 120 developers that had significant problems making useful, accurate technical documentation. Most of the knowledge was tribal, handed back and forth by way of verbal conversation. The company was a real risk. The wiki was in disarray and the engineering groups did not interact a whole lot. I put the Change Tolerance Index at a 7.5, on the high side of resistance to change. The company had been in business over 30 years and online since the days of CompuServe. There was no way I could write all the documentation for all the developers and they were pretty set in their ways. Yet, the company was at risk. Something had to be done.

I knew walking in that I only got One Thing and I had to find the inflection point. The One Thing I wanted was ongoing exchange of information in a structured manner. The writing could come later. The most important thing was for all the engineers to get accustomed to presenting information to a varied audience of engineers in a predictable, structured manner.

My solution was to get management to fund structured Lunch and Learns, which they did. Then, once I had to food and drink secured, I approached each senior member of the engineering staff and scheduled them for a Lunch and Learn according to a format I had created and had been approved by senior engineering staff. Lunch and Learns were scheduled for every other week. I worked with each presenting engineer to ensure that his or her Lunch and Learn was done according to the format. The structure of the format is and was important. But, more important was the fact that each presenter agreed to follow the same format. We were on our way to defining a structure for all technical information at the company and doing it in a very public way. Also, intergroup interaction was being facilitated around the format of the presentations.

Slowly, things caught on. During the presentation period we started to organize the wiki to support the information structure being propagated in the presentation format. Also, we created tools for the wiki that allowed engineers to enter technical information in the structure we were developing. We were hitting the organization on all fronts in a way that was fun and within the scope of tolerance that the organization could accept.

The takeaway here? I understood that I only got one behavior from the organization toward the change we wanted to facilitate. I did not do a lot of things. I did one thing that focused on an inflection point and I did that One Thing over and over and over again. You can, too. The most important thing is to find that One Thing that will cascade throughout the organization toward to goal you want to achieve.

The notion of One Thing is particularly important in smaller organizations that have not been around a long time: startups. In my experience, startups are fly by the seat of your pants undertakings. The excitement is contagious. The willingness to do new things newer and faster is magnetic. This is good. Yet, the overwhelming enthusiasm to hit the market fast and furious can foster a culture of change management that is unfocused and scattershot. Not focusing on One Thing can cost in terms of money wasted and cultural credibility diminished. Unfilled promises of change are sometimes worse than no change. (I will talk about wasted attempts at change in the Part 2 lesson: There are few do-overs.) The important thing for all those attempting a change an organization’s behavior is that the work is best done when it is focused and sustained, not random and impetuous.

Change Goes According to Levels

Change according to levels is a lesson I learned during my tenure with the transnational consulting company, Cap Gemini. Cap Gemini was and is a company expert in planning and managing change. The rule was taught to me by the Delivery Manager of my regional office. His take was that if you have an organization with 5 levels of management, CxO, Senior Vice President, Vice President, Director, and Manager, for a large organization with a few thousand employees, it’s going to take you about six months per level or two and half years for the planned change to propagate. For smaller organizations, you can probably get the time period per level down to three months. The important point is: The more hierarchy you have in your organization, the longer it’s going to take for change to propagate. This is not good or bad. It’s just the way things are. It takes a longer to turn an ocean liner than to turn a speed boat. Be able to project the rate at which change will propagate goes a long way toward measuring success and avoiding the risk of unfilled promises that compromise the Change Manager’s credibility.

Putting It All Together for Part 1

Organizations that cannot change, ain’t. Few enterprises can withstand the forces of innovation and competition without having to alter continuously the way they do business. Organizations must change to survive. How they change and the degree to which the desired change is effective depends on the skill and approach of the Change Manager(s).

In Part 1 of Lessons Learned: Effective Change Management, I’ve introduced the notion of determining an organization’s tolerance for change. I’ve talked about discovering an inflection point for change by identifying the One Thing. Also, I’ve given you a way to understand change propagation in terms of levels of management. In Part 2, I’ll go into an operational perspective for approaching all methods of change with the lesson, It’s a sale. Always was, always will be. Then, I’ll follow up with the lesson that is a forewarning about the dangers of ineffective change management, there are few do-overs.

About the Author

Bob Reselman is an executive software developer, author, technical evangelist, project manager, and teacher with over 25 years of experience in software development for personal computers, mobile devices, and Internet-based distributed applications. Bob has worked for a variety of roles on the technical landscape, for the computer manufacturer, Gateway; the transnational consulting firm, Cap Gemini; and the automotive web site, Edmunds.com. Bob is presently Director of Architecture for Casting Network International, the premiere website for the entertainment industry that connects actors to agents and directors worldwide.