Saying No to Change

I know my title is provocative, and I hope it made you stop to come read this. What I really mean, and well beyond a simple title’s ability to explain, is that not all change is good, and there are many times as a performance improvement professional that you should just say NO!

Here is a simple example. When someone first learns to drive, even little twitch of the car causes them to react at the wheel. What happens as a result is an oscillation down the road, and more importantly a diversion of attention. This is why new drivers are more prone to accidents, because they are focusing on the mechanical aspects of the process.

We often do the same thing with business change. We make changes without understanding the root cause. We change simply because we are asked, ordered, rewarded, or threatened. We change without understanding if the data is telling us that we are operating within the normal oscillations of the system. Data can tell us if we are seeing something remarkable, that should be duplicated, or something that is just a normal random fluctuation in system as it is setup. It will also tell us who will have to make the changes.

Here are some examples that I hope will add to this discussion.

1. Your new software release has serious bugs. Customer support scores are dropping. You implement a new customer satisfaction process with training for the support analysts. Is this a good change?

2. Your new software release has serious bugs. You analyze the data, and while customer support scores have dropped, one support analyst is consistently satisfying customer at a much higher rate than their peers. What would you do next?

3. Your new software release has serious bugs. Would it stop you from releasing the software in the first place?

All three (3) of these questions are meant to provoke thought, and to encourage you to want to dig deeper into the data. While each question might have an “obvious” answer, it might surprise you that there are deeper answers.

Thoughts on Question 1: Would you think this is a good change is the serious bugs already have simple patches that can be applied by the time the customers get the software release? Would it change your mind if having a better customer satisfaction process allowed you the possibility of salvaging your customers from this unfortunate software release? What if the software is so poorly written that customer satisfaction skills are essentially meaningless?

Thoughts on Question 2: What if the high performing support analyst is manipulating the data to improve their bonus? What if the manipulation was intentional? unintentional? Research tells us that asking someone who is rating you to give you the opportunity to improve or keep your rating at the highest level will improve your scores. What if the analyst is using this knowledge. Should you teach this skill to all analysts? If you do, is your customer satisfaction score an accurate representation of how customers actually feel or act?

Thoughts on Question 3: What if your company was under threat of take-over, by releasing the software you could buy the company time to respond to the take-over threat. Would you release the software? What if the fixes were simple and patches were already available by the time the software got to customers, would you release it? What happens if the bugs were really bad, but it didn’t impact your four (4) largest customers, who account for 80% of your revenue. But, your other 96 customers are badly impacted. Would you release it?

Hopefully, this gets you thinking. Thinking in systems. Thinking about change, root causes, problem analysis, and change management in a whole new way. For sometimes, the most important change you make may be to make no change at all.

Leave a Reply

Your email address will not be published. Required fields are marked *