THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is

Picking a Metric


This post is the forty-fifth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about measurement.

What They Like

A local fast-food establishment measures the amount of time between drive-through order placement and order delivery. Their goal is to minimize this time and create a fast-moving drive-through experience for patrons. That’s a great goal for everyone. The restaurant wins; the customer wins.

What I Don’t Like

Sometimes the drive-through staff games the system. The time from order to delivery rocks, but they accomplish this by queuing those waiting to place their orders. This puts one car and, presumably, one order in the queue; between order placement and delivery. The crew of the establishment is able to focus on one order at a time, so their measured delivery times are exceptional.

The Problem

The problem with this is the metric no longer reflects the customer experience at the drive-through.

The Solution

There are lots of options when it comes to solutions:

  • Change the metric
  • Eliminate the metric
  • Fire those responsible for gaming the system

Change the Metric

The metric can be changed if it doesn’t accomplish the goal. The goal is to provide feedback to the drive-through crew about the customer experience. When the crew doesn’t game the system, the metric produces the desired result.

What motivates the crew to game the system? There could be some reward attached to achieving the best numbers. It may not be a monetary reward. In fact, there are a lot of studies that show money isn’t the best reward for certain types of behavior. But these studies are often misinterpreted to justify not paying people enough or not giving people raises – even cost-of-living raises. The lie is: Money demotivates. The truth is rather simple – so simple it’s very easy to overlook: Love motivates. The response should never be: Don’t pay people more. The response should always be: Don’t kill the love.

“Why would someone kill the love, Andy?” Ah. Excellent question. I will answer that later but I will offer this teaser: What do Julius Caesar, Napoleon Bonaparte, and your average freshly-minted MBA have in common? The answer involves control.

Eliminate the Metric

If the metric is sponsoring the absolute incorrect behavior, it can be ditched. On the surface, this seems extreme. But let’s think about it for a minute. Most metrics are designed to provide feedback during the process. The logic is sound – the earlier you discover a problem, the sooner you can correct it. The sooner you correct a problem, the problem is less expensive to solve.

This goes to an analogy about asteroids I use for software projects. There’s a point where you can deflect a asteroid heading towards Earth with a very small amount of force. I equate this to a BB (which, in a purely engineering sense, is not scientifically accurate but I am usually not explaining this to scientists and engineers). Later, when the asteroid is closer to Earth, all the nukes on the planet won’t help. This is my primary argument for testing in software projects.

But abusing the metric by gaming the system has produced the opposite effect at the local fast-food establishment. It’s moved the problem to earlier in the process by queuing patrons before they place their order, thereby magnifying it (from the customer perspective). “Magnified, Andy? How?” For starters, there’s less capacity for cars if cars are not queued between the drive-through speaker and the delivery window. A key tenet of the Theory of Constraints states “Losses accumulate. Gains don’t.” By starting the losses earlier (and by design) there is more opportunity for accumulation. And don’t get me started about entropy

Fire Those Responsible for Gaming the System

Let’s seriously consider this for a moment. Who is responsible for gaming the system here? I can make the argument that it’s the crew. They were presented with a measurement and circumvented the intent of that measurement. I can call that “wrong” or even “evil”. Or I can call it “clever”. The survival instinct is in play. People are intrinsically motivated to do a good job (see Drive – an excellent book on the topic).

I can also make the argument that the person in leadership who chose the metric is responsible. They picked a metric that could be gamed. Or they added motivation to the metric that over-stimulated the workforce at the fast-food establishment. I believe the leadership is more responsible for this outcome than anyone else. Had it worked, they would certainly be responsible – you can count on that.

A Better Solution

The real problem is not that the metric is bad. The real problem is that the metric has been over-enforced. It’s been given more credence – more weight – than it deserves. This imbalance has motivated gaming the system.


I would argue that there’s a single metric that counts in the real world: Shipping. Did you deliver? Does it work? Is your customer delighted? These are simple yes/no questions and at the end of a project they are all that matter. Interim measurements are good and useful as long as they are used for their intended purpose. When they are misapplied, expect gaming.


Published Monday, August 8, 2011 8:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS


No Comments

Leave a Comment


This Blog



My Latest Book:

Community Awards

Friend of Red Gate

Contact Me


Privacy Statement