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.
Introduction
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:
- 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.
- 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 = code freeze?" Company morale was completely extinguished. The company ultimately failed.
The executives had certainly put themselves between a rock and a hard place by blowing all their cash, but surely there were better options than such a devious scheme. Perhaps the CEO could have called a company meeting, admitted the situation, accepted responsibility for it, and informed people that raises would be deferred to a subsequent year when the cash situation improved. People wouldn't have been happy, and they might have grumbled about the stupidity of upper management, but at least they couldn't have accused them of stabbing them in the back.
Conclusion
When you find yourself in a hole, the first thing to do is stop digging. Put down the shovel and step slowly away. You can still rescue your employees from the MBO trap.
"But I can't stop," you protest. "The corporate bigwigs have all decreed that managers must use MBOs as part of the yearly performance review process." Don't worry, because our resolution is not to stop using MBOs; it's to stop using bad MBOs.
I've written objectives that worked for testers and test teams before, and I've discovered a few helpful practices:
- Identify how the test team provides valuable services to the organization. What roles does each employee play in providing those services?
- Use the SMART mnemonic to remind you to create objectives that are specific, measurable, attainable, realistic, and time-boxed.
- Consider what incentives you're giving employees in each objective. Will the objective point the employee in the direction of serving the customer
better? - Ask yourself what signals you're giving with each objective. Are you directing employees toward what's most important?
- Specify the objective, but leave the means of achieving it to theindividual. You don't want to be a micromanager, do you?
Some managers, it is true, use MBOs successfully. They have learned to apply the tips-and to avoid falling into the traps-I discussed above. So, let's make a New Year's Resolution-no, a New Year's Objective: No more bad MBOs!
Editor's Note: Watch for a more detailed article by this author, with
more case studies. It will appear as a StickyMinds Original in coming weeks.