{"id":1940,"date":"2015-03-09T08:00:00","date_gmt":"2015-03-09T08:00:00","guid":{"rendered":"http:\/\/www.diogonunes.com\/blog\/?p=1940"},"modified":"2020-05-15T14:23:49","modified_gmt":"2020-05-15T13:23:49","slug":"think-twice-before-creating-bonus-system","status":"publish","type":"post","link":"https:\/\/www.diogonunes.com\/blog\/think-twice-before-creating-bonus-system\/","title":{"rendered":"Think twice before creating a bonus system"},"content":{"rendered":"

\"dinheiro\"<\/p>\n

Before opening the Pandora Box, read this or regret.<\/h3>\n

<\/p>\n

What should you do when your team is underperforming or misaligned with your company’s strategy? One solution you might think of is implementing an employee bonus system, after all humans reward desired behaviors for centuries, either with sugar cubes, toys, or bonus paychecks. Be advised that you’re playing with fire.<\/strong> One misguided step and you might reduce to ashes your authority, your teamwork environment, and your products’ quality.<\/p>\n

Metrics<\/h3>\n

\"horse<\/p>\n

Since “you can only manage what you measure”<\/a>, first you need to define how you’ll evaluate your employees. Simple, objective and consensual metrics will be the foundations of your bonus system. Evaluators and appraisees should understand how each metric score is calculated — that means that in the event of the evaluator being replaced by another person, the new evaluator reaches the same scoring. After several drafts and meetings, you finally reach a conclusion of how and which metrics will evaluate employees<\/strong>.<\/p>\n

\n

The point is, no matter what you measure, humans (not just programmers) get very good at optimizing to meet exactly that thing. Joel Spolsky<\/a><\/cite><\/p>\n<\/blockquote>\n

For a moment now, recall the days when you were at school. Imagine that a teacher gives out in advance the questions of next week’s exam. Will you study everything or just the best answers to those specific questions? Now back to the present. Will your employees waste time and energy doing things that do not contribute to a better evaluation<\/strong>? Time for things like tests, teamwork, innovation, documentation?<\/p>\n

\n

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead is to check in lots of buggy code and fix it, rather than getting it right in the first place. When you try to correct this by penalizing bugs, they’ll hide them. You can’t win. Joel Spolsky<\/a><\/cite><\/p>\n<\/blockquote>\n

Those who work for the metrics<\/strong> will get ahead of those who work for the people<\/strong> and keep spending time on unmeasured things. And when the latter group figures that out, they’ll eventually join the former. At this point you either give up on metrics or add up all the missing metrics describing every employee’s responsability. So much for your simple scoring system…<\/p>\n

Rewards<\/h3>\n