Is your company's reward structure counter-productive?
A recent issue of Inc. magazine had a article where a sales manager said, based on his experiences, that he'll never recommend using commissions to reward salesmen, because it damages the company that does it; specifically it works against team-work and causes the company owners to not trust their salesmen. Check it out: http://www.inc.com/magazine/20030501/25416.html.
Some managers complain that pair-programming prevents them from seeing clearly which programmers are accomplishing more than others, to be able to reward their individual accomplishments. Emphasizing individuals over teams rewards territoriality, rewards competition more than cooperation. Cooperation is more productive than competition at getting products developed and shipped. Do you really want to discourage cooperation?
When programmers are working solo, how do you know they are actually doing something useful? Could it be that someone is working alone because what he's doing is NOT useful to anyone else?
Software is a team effort. Even when its done by a bunch of soloists, they are still using each other's work by building on each other's libraries and code. Could it be that the guy who demos a flashy application has only done some of the GUI, and the functional parts of the application were done by his coworkers? Are you going to reward the flashy demo guy because he can show you something more visible than the other programmers who wrote the functionality?
Robert Martin wrote on the IXP mailing list:
In one case we transitioned a team that had technology project leads. There was a lead for the database, a lead for the middleware, and a lead for the UI. (I'm not kidding!) When we transitioned them to XP these folks rapidly realized that the practices of pairing and collective ownership were diluting their power base. Two of them made abortive attempts to seize power back, and wound either resigning or being fired. The team was much happier once they were gone.
Are you rewarding last-minute, late-night heroics? When you do XP well, you have measured progress every iteration, and you can predict how much scope can be accomplished a long time before the end of the project. Check out what happens when rewarding heroism meets XP...
In another case we had a cowboy. This fellow used to rescue the project at the eleventh hour by pulling all nighters. His manager learned to depend upon this behavior and just "knew" that the cowboy would save him at the last minute. As we transitioned to XP the cowboy actively sabotaged the planning meetings and the iterations. He did not want the team to make progress. We went through three iterations of *zero* velocity. (Count them, zero.) And then the manager dissolved the team and reformed it months later in a different way. (I'll leave it to you to predict how it was restructured.) -- Robert Martin.
Do you think that even before XP came along, that this cowboy might have been doing some sabotage to make sure his heroism would always come into play? I think XP just made it more visible.
Ken Auer, who runs RoleModel Software, a consulting company that does XP, writes:
I've always had a reward structure here that was based on the concept "share the risk share the reward" while still acknowledging that "socialism doesn't work... Some people do provide more value than others". At first, I could only come up with a "how much money did we make due to your billable hours" measures, with a few other criteria to make sure it wasn't abused. Worked fine while everyone was billable most of the time. When it wasn't, it had people lobbying for billable time against each other e.g. "I think I should be on this project (instead of Joe) because...".
Finally, I came up with a formula for individual value to the company that could be identified, peer-reviewed, and steps taken to move the number up. That number was used to figure out shares in the pool of money. It wasn't perfect, but it completely got rid of all of the bad behavior (fighting against each other) and produced good behavior, i.e. I got help figuring out how to divvy up resources for the best of our company, the client, and the individuals.
Amy Shwab reminds us:
In the January Harvard Business Review (all about motivation) there was a wonderful piece about the longer term effects of performance metrics and tying results to those metrics. The company, indeed, got what they were rewarding but it did not translate into what they wanted or needed. It fragmented the organization and served the customers very poorly. The most important things are often the most difficult to measure -- like 'fun'.
Developing intellectual property like software is always a learning experience. External rewards can hinder learning. Kohn said "Rewards are most damaging to interest when the task is already intrinsically motivating." Check out "Punished by Rewards? A conversation with Alfie Kohn".
Rachel Davies and John Nolan will hold a workshop on this topic at the Agile Development Conference
.
Thanks go the people mentioned above, and Brad Appleton and Steve Berczuk on the XP mailing list.
No comments:
Post a Comment