Here is something that I just read about (again) and have long known it even though I haven’t always thought about it.
“People don’t pay much attention to what management says; they pay attention to what management measures.”
Management is constantly trying to reward and punish behavior in the non-systems-thinking world; they stare common-cause variability straight in the face and see a person. So, what happens is they create benchmarks their employees must adhere to and ding those who miss the lower threshold, and praise those that exceed the upper thresholds. I’ve seen cases where taking these rewards and punishments away had zero effect on variability simply because the praise and punishment came after the fact, and had no impact whatsoever on the subsequent iteration.
However, when it comes to measurement of your business, here is something else that is important to consider: no matter what goals you’ve set, or outcomes you are seeking, be very careful what you measure because that is what will dictate the behavior of your employees and business processes. In other words, measures drive behavior, and measuring the wrong things will have unintended consequences for your business!
Consider these cases:
- If a quality assurance team is rewarded for finding defects, they will find defects; even if the stated goal of the company is to improve quality (and quality is actually improving).
- If a team is rewarded for each hour they bill a client, they will find hours to bill the client; even if the stated goals of the company are customer experience or creating customer value.
- Again, if a team is rewarded for each hour they bill a client, they will bill their clients before they help a teammate for an hour; even if the stated goal of the company is collaboration.
- If an IT department is rewarded for keeping systems up and running, they will ensure that variability is not introduced (new systems) into their ecosystem even though the stated goal of the company is to get new systems up and running quickly.
- A support center is rewarded for keeping call lengths to under two minutes; so calls end before that limit has been reached whether the problem has been resolved or not; when the stated goal of the company is to deliver an exceptional customer service experience.
- A support manager is rewarded for reducing the number of inbound calls, so they design a voice mail system that customers get frustrated with and hang up on; when the company’s stated goal is to solve their customers’ problems.
A key to solving this problem is to first identify the outcomes your customer is seeking. This is true whether you are designing a process and/or designing a new product or service. When you’ve done this, you can easily identify a mismatch between how your customer measures value versus how your organization is measuring activities. And it’s not just explicit measures like counting things, giving kudos for the wrong activity is just as problematic as counting the wrong activities.
Certainly if you’re attempting to identify why an outcome goal is not being reached, measuring local inputs to the process may help in that determination. But they should not take precedence over, or conflict with, what we are really trying to achieve. And one other thing, when you have processes or procedures that add no value at all, don’t measure them, get rid of them. This is pretty common when humans have to perform duplicative work because an organization has failed to integrate systems properly. If a reasonable customer would be unwilling to pay for you to perform that activity, it adds zero value: don’t do it, or measure it!
Simple rules to consider:
- Don’t promote local efficiency at the expense of global waste
- Don’t reward activities that that are counter-productive to your organizations competitive differentiators
- Don’t set goals & objectives that don’t align with what your customers value
I will close with a classic example you’ve possibly heard before. It’s about a team of experts from the West who consulted with a factory from the East after the fall of the iron curtain. They observed a person inspecting a line of new machines and every so often he would scratch something, break something or undo something. As it turned out the person worked in quality control; so why would they be doing that?
The answer is simple: they were being measured on how many defects they found. As the quality of production improved, the defects decreased, which reflected poorly on QA’s ability to find defects. As a result, they did what was necessary to find defects and thereby improve their performance metrics. As I look back on my career, there have been times, sadly, where I have succumbed to the same motivations simply because of the way my performance was being measured. How about you?
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
