[A picture of private offices at Fog Creek Software] Alert! This ancient trifle retrieved from the Joel on Software archive is well-past its expiration date. Proceed with care.

Joel on Software

2002/07/15

by Joel Spolsky
Monday, July 15, 2002

Measurement

"Thank you for calling Amazon.com, may I help you?" Then -- Click! You're cut off. That's annoying. You just waited 10 minutes to get through to a human and you mysteriously got disconnected right away.

Or is it mysterious? According to Mike Daisey, Amazon rated their customer service representatives based on the number of calls taken per hour. The best way to get your performance rating up was to hang up on customers, thus increasing the number of calls you can take every hour.

An aberration, you say?

When Jeff Weitzen took over Gateway, he instituted a new policy to save money on customer service calls. "Reps who spent more than 13 minutes talking to a customer didn't get their monthly bonuses," writes Katrina Brooker (Business 2.0, April 2001). "As a result, workers began doing just about anything to get customers off the phone: pretending the line wasn't working, hanging up, or often--at great expense--sending them new parts or computers. Not surprisingly, Gateway's customer satisfaction rates, once the best in the industry, fell below average."

Measuring and Managing Performance in OrganizationsIt seems like any time you try to measure the performance of knowledge workers, things rapidly disintegrate, and you get what Robert D. Austin calls measurement dysfunction. His book Measuring and Managing Performance in Organizations is an excellent and thorough survey of the subject. Managers like to implement measurement systems, and they like to tie compensation to performance based on these measurement systems. But in the absence of 100% supervision, workers have an incentive to "work to the measurement," concerning themselves solely with the measurement and not with the actual value or quality of their work.

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.

Fortune 500 CEOs are usually compensated with base salary plus stock options. The stock options are often worth tens or hundreds of millions of dollars, which makes the base pay almost inconsequential. As a result CEOs do everything they can to inflate the price of the stock, even if it comes at the cost of bankrupting or ruining the company (as we're seeing again and again in the headlines this month.) They'll do this even if the stock only goes up temporarily, and then sell at the peak. Compensation committees are slow to respond, but their latest brilliant idea is to require the executive to hold the stock until they leave the company. Terrific. Now the incentive is to inflate the price of the stock temporarily and then quit. You can't win, again.

Don't take my word for it, read Austin's book and you'll understand why this measurement dysfunction is inevitable when you can't completely supervise workers (which is almost always).

I've long claimed that incentive pay isn't such a hot idea, even if you could measure who was doing a good job and who wasn't, but Austin reinforces this by showing that you can't even measure performance, so incentive pay is even less likely to work.

UI for Programmers in Polish


Have you been wondering about Distributed Version Control? It has been a huge productivity boon for us, so I wrote Hg Init, a Mercurial tutorial—check it out!

Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.



About the author.

I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, easy web-based collaboration software, FogBugz, an enlightened bug tracking and software development tool, and Kiln, a distributed source control system that will blow your socks off. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky