Stop the Bad MBOs

Fight the Good Fight Against Abusive "Management by Objectives"

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 requirements, 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. The few who complained to the manager about these objectives were hit on the forehead with the big red "Not a Team Player" stamp that all managers have in their desks. Despite the absurdity, most of them decided they would do the right thing, as best they could tell what the right thing was-to totally ignore the performance evaluation scheme imposed on them, and just do their work.

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

Case Study Three: Stepping on your Own Landmine
In both of the case studies above, the managers imposing these 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. However, in some cases, we encounter managers who are actually using MBOs for nefarious purposes. And sometimes they get what they deserve for doing so.

Not too long ago, I heard of a perfect example of cynical manipulation of the MBO process which backfired in a spectacular way. In that case, a secret management email memo from the CEO directed that due to a cash crunch brought on by excessive mergers and acquisitions, no manager could give more than one member of his staff a raise. Furthermore, the memo stated, each manager was required to manipulate the (already established) way of counting people's MBOs. This was to make sure that everyone but one person in their staff rated "satisfactory" or below, therefore, giving only the person that rated  "above expectations" a whopping two percent raise.

A very short period of time after that email going out, someone-whether a rebellious manager or an individual contributor who had intercepted the message-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 anonymously 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.

As the saying goes, when you find yourself in a hole, the first thing to do is stop digging. So, if you're digging a punji trap for your employees with MBOs, put down the shovel and step slowly away from the sharpened bamboo.

But I can't stop, you might well protest-the big corporate kahunas

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.