
Performance-related pay doesn't encourage performance - 10ren
http://www.management-issues.com/2009/6/25/research/performance-related-pay-doesnt-encourage-performance.asp
======
fnid
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."

~~~
ramanujan
> 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.)

------
waterlesscloud
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.

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

~~~
fnid
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.

~~~
houseabsolute
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.

------
julius_geezer
"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.

