[A picture of private offices at Fog Creek Software]

Joel on Software

The Econ 101 Management Method

by Joel Spolsky
Wednesday, August 09, 2006

Joke: A poor Jew lived in the shtetl in 19th century Russia. A Cossack comes up to him on horseback.

“What are you feeding that chicken?” asks the Cossack.

“Just some bread crumbs,” replies the Jew.

“How dare you feed a fine Russian chicken such lowly food!” says the Cossack, and hits the Jew with a stick.

The next day the Cossack comes back. “Now what are you feeding that chicken?” ask the Jew.

“Well, I give him three courses. There’s freshly cut grass, fine sturgeon caviar, and a small bowl of heavy cream sprinkled with imported French chocolate truffles for dessert.”

“Idiot!” says the Cossack, beating the Jew with a stick. “How dare you waste good food on a lowly chicken!”

On the third day, the Cossack again asks, “What are you feeding that chicken?”

“Nothing!” pleads the Jew. “I give him a kopeck and he buys whatever he wants.”

(pause for laughter)

(no?)

(ba dum dum)

(still no laughter)

(oh well).

I use the term “Econ 101” a little bit tongue-in-cheek. For my non-American readers: most US college departments have a course numbered “101” which is the basic introductory course for any field. Econ 101 management is the style used by people who know just enough economic theory to be dangerous.

The Econ 101 manager assumes that everyone is motivated by money, and that the best way to get people to do what you want them to do is to give them financial rewards and punishments to create incentives.

For example, AOL might pay their call-center people for every customer they persuade not to cancel their subscription.

A software company might give bonuses to programmers who create the fewest bugs.

It works about as well as giving your chickens money to buy their own food.

One big problem is that it replaces intrinsic motivation with extrinsic motivation.

Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job. They want to help people understand that it’s in their best interest to keep paying AOL $24 a month. They want to write less-buggy code.

Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.

Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things that they actually want to do.  That’s not very controversial.

But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.

Another big problem with Econ 101 management is the tendency for people to find local maxima. They’ll find some way to optimize for the specific thing you’re paying them, without actually achieving the thing you really want.

So for example your customer retention specialist, in his desire to earn the bonus associated with maintaining a customer, will drive the customer so crazy that the New York Times will run a big front page story about how nasty your customer “service” is. Although his behavior maximizes the thing you’re paying him for (customer retention) it doesn’t maximize the thing you really care about (profit). And then you try to reward him for the company profit, say, by giving him 13 shares of stock, and you realize that it’s not really something he controls, so it’s a waste of time.

When you use Econ 101 management, you’re encouraging developers to game the system.

Suppose you decide to pay a bonus to the developer with the fewest bugs. Now every time a tester tries to report a bug, it becomes a big argument, and usually the developer convinces the tester that it’s not really a bug. Or the tester agrees to report the bug “informally” to the developer before writing it up in the bug tracking system. And now nobody uses the bug tracking system. The bug count goes way down, but the number of bugs stays the same.

Developers are clever this way. Whatever you try to measure, they’ll find a way to maximize, and you’ll never quite get what you want.

Robert Austin, in his book Measuring and Managing Performance in Organizations, says there are two phases when you introduce new performance metrics. At first, you actually get what you wanted, because nobody has figured out how to cheat. In the second phase, you actually get something worse, as everyone figures out the trick to maximizing the thing that you’re measuring, even at the cost of ruining the company.

Worse, Econ 101 managers think that they can somehow avoid this situation just by tweaking the metrics. Dr. Austin’s conclusion is that you just can’t. It never works. No matter how much you try to adjust the metrics to reflect what you think you want, it always backfires.

The biggest problem with Econ 101 management, though, is that it’s not management at all: it’s really more of an abdication of management. A deliberate refusal to figure out how things can be made better. It’s a sign that management simply doesn’t know how to teach people to do better work, so they force everybody in the system to come up with their own way of doing it.

Instead of training developers on techniques of writing reliable code, you just absolve yourself of responsibility by paying them if they do. Now every developer has to figure it out on their own.

For more mundane tasks, working the counter at Starbucks or answering phone calls at AOL, it’s pretty unlikely that the average worker will figure out a better way of doing things on their own. You can go into any coffee shop in the country and order a short soy caramel latte extra-hot, and you’ll find that you have to keep repeating your order again and again: once to the coffee maker, again to the coffee maker when they forgot what you said, and finally to the cashier so they can figure out what to charge you. That’s the result of nobody telling the workers a better way. Nobody figures it out, except Starbucks, where the standard training involves a complete system of naming, writing things on cups, and calling out orders which insures that customers only have to specify their drink orders once. The system, invented by Starbucks HQ, works great, but workers at the other chains never, ever come up with it on their own.

Your customer service people spend most of the day talking to customers. They don’t have the time, the inclination, or the training to figure out better ways to do things. Nobody in the customer retention crew is going to be able to keep statistics and measure which customer retention techniques work best while pissing off the fewest bloggers. They just don’t care enough, they’re not smart enough, they don’t have enough information, and they are too busy with their real job.

As a manager it’s your job to figure out a system. That’s Why You Get The Big Bucks.

If you read a little bit too much Ayn Rand as a kid, or if you took one semester of Economics, before they explained that utility is not measured in dollars, you may think that setting up simplified bonus schemes and Pay For Performance is a pretty neat way to manage. But it doesn’t work. Start doing your job managing and stop feeding your chickens kopecks.

“Joel!” you yell. “Yesterday you told us that the developers should make all the decisions. Today you’re telling us that the managers should make all the decisions. What’s up with that?”

Mmm, not exactly. Yesterday I told you that your developers, the leaves in the tree, have the most information; micromanagement or Command and Control barking out orders is likely to cause non-optimal results. Today I’m telling you that when you’re creating a system, you can’t abdicate your responsibility to train your people by bribing them. Management, in general, needs to set up the system so that people can get things done, it needs to avoid displacing intrinsic motivation with extrinsic motivation, and it won’t get very far using fear and barking out specific orders.

Now that I’ve shot down Command and Control management and Econ 101 management, there’s one more method managers can use to get people moving in the right direction. I call it the Identity method and I’ll talk about it more tomorrow.


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!

Next:

The Identity Management Method



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, insanely simple project management, FogBugz, an enlightened bug tracker designed to help great teams develop brilliant software, and Kiln, which simplifies source control. I’m also the co-founder and CEO of Stack Exchange. More about me.

© 2000-2014 Joel Spolsky