Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Performance-related pay doesn't encourage performance (management-issues.com)
15 points by 10ren on Dec 25, 2009 | hide | past | favorite | 8 comments


There's a classic experiment where people turn some pegs a quarter turn for an hour or so. There were three groups, the first was paid a dollar, the second $20, and third was control, paid nothing. Of the three groups, which do you think enjoyed the work the most?

Well, the one dollar group said they enjoyed it the most and indicated they were most likely to do an experiment like it in the future? Why? You can read more here: http://psychclassics.yorku.ca/Festinger/

So what this says is, when you get paid enough money, you can admit to yourself that what you are doing for the money isn't that great and you don't like it. If you aren't paid that much, then you have to justify to yourself why you are doing it and this might include that you enjoy it, you're helping a group, "doing your part," or some other reason besides being fairly compensated. Otherwise, you'd say, "I do it for the money."

I wonder if collectively, programmers/hackers/IT people work for less than their value and so they (we) compensate for the lack of compensation with "passion for the work."


> the one dollar group said they enjoyed it the most

Counterintuitive. Interesting. But not really definitive.

Here's the key quote:

> The difference between the One and Twenty Dollar conditions reaches the .08 level of significance on a two-tailed test (t = 1.79).

The sample sizes here are tiny, about 20 people per.

Without meaning any offense to you in particular, I've often observed that "interesting" social science findings like this take on disproportionate significance when verbally summarized as "enjoyed it the most" or "more effective". That only tells you a tiny bit about (respectively) ranks or the sign of the difference. Lacking detailed knowledge of the experiment (= effect sizes + confidence intervals), one doesn't know how robust those ranks or orderings are if the experiment was repeated...which is, in this case, what the citation boils down to: a tacit suggestion to repeat the experiment with compensation at your business!

Again, zero offense intended. My only point is that social science type findings like this should be handled with great skepticism, particularly if the results are counterintuitive and involve small sample sizes.

(PS: I do agree that money is often the most expensive way to motivate people. It does not motivate me. But I think some of Dan Ariely's work is more persuasive in this regard.)


I think it is important to consider how comfortable a person is with the pay they receive.

That is, if I have to think and worry about necessities then I'm not fully mentally engaged in my work. Being paid enough to live a comfortable life is important.

Conversely, if the difference between 2 jobs is whether or not I can afford something I consider a luxury, then job satisfaction and other non-monetary benefits start to mean something.

Clearly necessities, luxuries, and comfort all being subjective.


The problem in my experience has always been that management can't just leave well enough alone and make it straight performance based. They have to tie in all these things that they think should lead to good performance, whether they actually do or not.


What you said makes a lot of sense. How would you define straight performance based for developers?


Some ideas that quickly come to mind.

Number of bugs caught in test. Number of lines of code written, fewer would be better, but it's difficult to measure this, because more functionality is often correlated to lines of code.

Number of hours of maintenance required after release. Bugs found after release. Downtime caused by code written by the developer. Amount of time projects are delayed due to the developer. Number of hours or days code is ready before deadline. Speed of the application or functionality they write. Longevity of the code.


All of your proposals have serious flaws.

* Bugs caught in test - testers file more bugs given the same number of defects.

* Lines of code (less is better) - People talk more, do less.

* Hours of maintenance required after release - Developers delay release excessively for testing.

* Bugs found after release - Developers look less hard for bugs.

* Downtime caused - Developers avoid working on things that might cause downtime.

* Time delayed due to developer - Impossible to measure.

* Ready before deadline - Developers test less rigorously, cut features.

* Speed of the application - Application will do less, or developers optimize beyond what is necessary.

* Longevity of code - Not strongly connected to quality, dependent more on organizational use case.

My point is not to get you to come up with new proposals, because they will likely fail too. It's to get you to realize that the entire idea of coming up with these metrics, or balance them, does not make sense. You would not say to a water colorist that you would compensate him based on how little red paint he wastes or how many square inches he paints.


"While compensation reform is needed, it must come from within--from executives and boards, acting in the company's best interests," he added.

I don't like the pay Czar notion. However, I doubt that the executives will reduce their own pay, and boards have often been in management's pocket on this issue.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: