Discordant Reward Mechanisms

Are you really looking for ideas, or are you looking for someone to develop and provide a full-blown AntiPattern? A couple of ideas:

1) Kudos going to those who bring together a team of people to finish something as a project's end date nears, when the reason it isn't getting done is because they've been slacking off all along. In the same time frame, the Tortoise who moved ahead slowly but surely and met the date gets little recognition.

2) Rewarding people based on the number of problem statements they closed. This is problematic because some people will solve multiple problems with one problem statement, while others will open and solve as many problem statements as they can to inflate the number of problems solved. Or, someone may knowingly leave problems in a piece of work so that he can come back later and "solve" them.

-- DanKendell?

Addendum: A major problem in support organizations is that closing a problem ticket is more important than resolving the problem that the ticket represents. This may be an AntiPattern by itself. Actually, I guess it might be a case of TemporaryCargoCult.

-- KielHodges

How about: 3) People quickly size up the effort-reward ratio and avoid low ratios. This stems from the fact that the rewards are precomputed and are unlikely to model precisely the effort.

4) People will adjust the effort so that the effort-reward ratio is beneficial. If one person puts a task with a 6 e/r while a colleague continually pulls 1's then it is likely that the job will become slap-dash. (That might be what was wanted instead of a perfect job). Often someone has to do these non-remunerative tasks. It behooves the managers to find some other way of rewarding the person who sweeps in the corners.

-- NeilPitman

5) Rewarding management for hitting aggressive schedules while rewarding engineers for achieving high-quality goals. This creates a tension that is very difficult to resolve. -- DaveSmith

The classic is surely rewarding programmers for lines of code produced. Using better methods of measuring the complexity or difficulty of a project doesn't always help; we don't want more complex or difficult programs.

We say we want programmers to reuse code, but we don't always institute policies that reward accordingly.

-- DaveHarris

6) Employers who base salary on the average salary of people doing similar jobs in the same area (the infamous "comp ratio") and forgetting that, if an employee has a 100% comp ratio, half of the other companies he could work for would pay him better. Related to the YouGetWhatYouPayFor AntiPattern. Amelioration: Pay your employees commensurate with how badly you want to keep them. -- RussBrown?

7) In this breeding ground for AntiPatterns in which I dwell there is a common practice: playing a (generally managerial) role in the resolution of a crisis is more rewarding than working to prevent crises even when the crisis is a result of one's own failure! Though the mechanism of this case is not explicitly spelled out, it is quite real. -- KielHodges

8) Management regarding programmers who work 16 hours a day as inherently more valuable than those who put in 9 to 5. Working that hard usually is just a sign that you did a terrible job of estimation and planning up front, and that probably there is a great deal of code-rewriting going on. -- JeromeKaraganis

9) I think you can summarize this by saying "you get what you measure". If you want your programmers and managers to solve problems instead of producing "stuff", then the measurement should be "problems solved", not stuff or "code" produced. -- TerryRaymond?

10) Managers getting rewarded for cutting development time/costs because "Developers always pad their schedule".

"I said it is going to take six months minimum to do the project and I meant it."

Coming back and telling me I can have 3 tells me:

) You don't trust me.
) You don't care about my personal life.
) You're going to be another blip on the chart of failed projects.

But Most of all!

) You watched too many _Star Trek_ episodes.

<RANT>

: Scotty is a FICTIONAL character! Real engineers who do 6 months of work in 10 minutes blow everything up and kill LOTS of people.

</RANT>

-- BrentSchwartz (26Jan00)

See also: CaptainHornHair

This has happened to me a few times. I have since realized that I should have stopped and ReQualifiedMyEmployer.

Let's look at this from a different direction. In many projects, the delivery date is the firmest requirement that they have. If the manager comes back and says that delivery is required in 3 months, put together a plan for what can be done in 3 months. The choice is simple, either the manager allows the developers to cut back the scope, or the manager does it on his own and just informs the developers after the fact. In this light, which approach is providing the most respect for the developers?

Scotty appears on one episode of Star Trek: the Next Generation (Relics). In one scene, after La Forge has given Picard an estimate for an engineering repair, (something like) the following exchange happens:

Scotty: "Why'd you tell him that, laddy?"

La Forge: "Because that's how long it will take."

Scotty: "No, laddy, no. Always tell him you can't possibly do it in less than 10 hours. Then you'll look good when finish earlier."

Correction:

Scotty: Do ye mind a little advice? Starfleet captains are like children. They want everything right now, and they want it their way. But the secret is to give only what they need, not what they want!

Geordi: Yeah, well I told the captain I'd have this analysis done in an hour.

Scotty: And how long would it really take?

Geordi: An hour!

Scotty: Oh, ye didn't tell him how long it would really take, did ye?

Geordi: Well, of course I did.

Scotty: Oh, laddie, ye've got a lot to learn if ye want people to think of ye as a miracle worker!

From StarTrek V: The Final Frontier:

Kirk: "Tell me, Mr. Scott. Why do you always multiply your repair estimates by a factor of four?"

Scotty: "T' preserve me reputation as a miracle worker, Sir!"

Exactly right!

However, I feel it is sad that this AntiPattern is supported by both sides. "I estimate, You assume I am lying, I assume that you assume I am lying, so I lie to account for your assumption that I am lying......."

Personally, I don't lie and I usually suffer for it.

Second, (aside from my ranting, for which I now apologize!) my intention is to focus more on the reward system that encourages the manager to underestimate the project. And the reward system that encourages the team members to follow the other side and encourage the process.

The manager is rewarded for money saved or perceived as being saved. This is understandable because everyone has a short time-to-market and a limited budget to get it done with. However, the team either is lucky to get a reward at all or is STOMPED on for having a bad attitude about a late, untested, buggy, undocumented, unsupportable project.

A divergence between the desired outcome (a properly estimated and executed project) and the actual outcome (a grossly underestimated project, a burnt team, and misplaced blame).

Relevant Black Humor:

"Has anyone seen the ScapeGoat lately?"
"It's always easier to ask for more money when you are late."
"It's easier to ask forgiveness than permission."
"Never enough time to do it right, Always time to do it over."
<Add Your Favorite Here>

: Better yet! see: AlarmBellPhrase

-- BrentSchwartz (26 Jan 2000)

One of the better ways to reward developers is to have their efforts reviewed by other developers. A developer can always pull the wool over the eyes of a business type, specifically because the business type doesn't understand the tech details. It is much harder to do this to people who see and understand your documents, code, and other artifacts. Developers know better than managers which developers are actually doing good work. -- RobMandeville (19 Apr 2000)

Too often, HR department makes final decision to hire/reject people even knowing much less than managers...

ForBestResultsForgetTheBonus challenges the basis of this discussion.

CategoryAntiPattern