Stop Destroying My Team with Bad MBOs

A Manager's New Year's Resolution

It's 2003, and you're a manager casting about for a good New Year's resolution. Sure, going to the gym, quitting cigarettes, cutting down on the cheeseburgers-those are all good resolutions for you personally. But how about a resolution that helps you professionally, and will help everyone who works for you? How about resolving to stop destroying your team with bad MBOs? Find out how, in this week's column by Rex Black.

MBOs, or management by objectives, are commonly used as part of yearly performance reviews. In theory, the perfect set of objectives define exactly what the employee is to achieve over the coming year. At the end of the year, in the annual performance review, the manager simply measures whether-or to what extent-the objectives were achieved.

In real life, however, there is no "perfect set of objectives." Some management-by-objectives approaches backfire in dramatic ways. Let's look at a couple of case studies of bad MBOs, how they undermined the team, and how the managers could have done better.

While You're at It, Please Walk across the Atlantic Ocean
I recently heard of an organization whose testers were evaluated on the same two objectives every year:

  1. How many bugs were detected by customers after release in a subsystem tested by the tester? The tester's performance evaluation rating goes down as  this number goes up.
  2. How many bug reports did the tester file that developers returned as "works as designed," "irreproducible," etc.? The testers performance evaluation rating goes-yep, you guessed it-down as this number goes up.

These two metrics are at least partly under the tester's control. But notice how only a perfect tester-or a tester testing a completely trivial subsystem-could ever hope to get a good performance rating under these objectives. Furthermore, note that any attempt to drive one of the metrics toward zero will tend to drive the other metric up. Also notice the power of the developer who, in some gray areas of design, may or may not return a report with "works as designed." If a tester finds a problem in the design, or a conflict in equirements, he better not say anything, because a "works-as-designed" report will hurt his or her evaluation! Finally, while the testers did more than simply run tests, they weren't measured on any of those other activities.

The testers subjected to these objectives were totally up in arms. But most of them decided they would do the right thing, as best they could tell what the right thing was, and totally ignore the performance evaluation scheme imposed on them.

As a start, the manager here could have at least made the two objectives realistic. There is some natural level of error and variation inherent in any process. A realistic and attainable pair of target metrics for these objectives would have alleviated some of the most caustic effects.

Stepping on Your Own Landmine
In the case study above, the managers imposing the objectives probably had their hearts in the right places. They had been told and led to believe that quantitative performance evaluation schemes are eminently fair and would align employee behaviors with company needs. In some cases, however, we encounter managers who are actually using MBOs for nefarious purposes. And sometimes they get what they deserve for doing so.

In one case I know of, a secret management email memo from the CEO directed that, due to a cash crunch, no manager could give more than one member of his staff a raise. Furthermore, each manager was required to manipulate the (already established) way of counting people's MBOs to make sure everyone but one person in their staff rated "satisfactory" or below, with only one person rated "above expectations" (for a whopping 2 percent raise).

A short time after that email went out, someone (perhaps a rebellious manager) decided to forward the email anonymously to everyone in the company. A huge hue and cry resulted, of course. Many talented people with other options left. Someone posted an email that read, "Pay freeze =

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.