Wednesday, October 20, 2010
Does your enterprise promote discordant reward mechanisms...
Let's talk about some of the worst practices witnessed in large enterprises...
Let's have the CIO send kudos to those who are successful in bringing together a team of people to finish a project as the delivery date nears. Let's also avoid acknowledging that the reasons things aren't getting done is because the time has been preoccupied with either useless meetings (under the banner of socialization) or simply slacking off. In the same voice, the CIO needs to forget those who are viewed as the Tortoise that move ahead slowly but surely and always hit their dates. Heroic efforts are the crack that every CIO smokes.
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. Even better, let's just close tickets without actually solving the problem at all. If it is important, someone will open up a new ticket. In the meantime, I get credit for the closed one.
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.
The HR classic has to be at annual review time where HR pulls out the competitive compensation ratio which employers base salary on the average salary of people doing similar jobs in the same area. They of course forget that, if an employee has a 100% comp ratio, half of the other companies they could work for would pay him better. Shouldn't pay equate less with market surveys and more with how badly you want to keep someone?
Management regard developers 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. This mindset is especially encouraged by management that worked for a large insultancy where billable hours and facetime were more important than a successful business outcome. Business outcomes can always be addressed via change order.
Isnt it fascinating how HR determines compensation sometimes at the individual level while knowing even less about IT than the person's manager...
| | View blog reactionsLet's have the CIO send kudos to those who are successful in bringing together a team of people to finish a project as the delivery date nears. Let's also avoid acknowledging that the reasons things aren't getting done is because the time has been preoccupied with either useless meetings (under the banner of socialization) or simply slacking off. In the same voice, the CIO needs to forget those who are viewed as the Tortoise that move ahead slowly but surely and always hit their dates. Heroic efforts are the crack that every CIO smokes.
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. Even better, let's just close tickets without actually solving the problem at all. If it is important, someone will open up a new ticket. In the meantime, I get credit for the closed one.
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.
The HR classic has to be at annual review time where HR pulls out the competitive compensation ratio which employers base salary on the average salary of people doing similar jobs in the same area. They of course forget that, if an employee has a 100% comp ratio, half of the other companies they could work for would pay him better. Shouldn't pay equate less with market surveys and more with how badly you want to keep someone?
Management regard developers 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. This mindset is especially encouraged by management that worked for a large insultancy where billable hours and facetime were more important than a successful business outcome. Business outcomes can always be addressed via change order.
Isnt it fascinating how HR determines compensation sometimes at the individual level while knowing even less about IT than the person's manager...
