Possibly the worst idea ever conceived in business is the idea to link payment to key figures. Why? Because it can only work for a single key figure: company profit, assuming that the main purpose of the company in question is to maximize company profit in the long run. If you link that number to the payments of the employees they now have an interest in maximizing the profit of the company. And if the employees expect to stay long enough with the company they have an interest in maximizing the profit in the long run. Great!
But of course the motivation of the employee diminishes when the company grows. A single employee has hardly any influence on the company profit. Now smart people think up new key figures. But since those are by definition different from the company profit, employees get paid for optimizing something that is not company profit, with disastrous results. Let me give you some examples:

• Employees get extra pay for work on billable projects. Undesired result: If an employee is finished with her work she benefits from claiming to still work on the project instead of announcing availability for new tasks.
• Employees get extra pay for the ratio of positive feedback from customers. Undesired result: Negative feedback gets hidden, but the negative feedback is the one you really need to know about.
• Employees get extra pay for the success of their department. Undesired result: Fights between department about who is ‘owner’ of a project; Information hiding between departments.

So should we scrap all key figures? No, I think they are actually quite useful, as long as you never try to tie any kind of automatic action on a key figure that goes beyond some kind alarm, triggering somebody to look into the situation. It also makes the selection of key figures much easier. You don’t have to find a key figure which is fail proof (which you won’t find anyway). Another example: Key figures for Software Development. The aim is to get an indicator when something in the software construction phase is going astray. I propose the following key figures:

• Lines Of Code per man month
• Code Coverage in any of its flavors
• Toxicity

Of course it is a bad idea to base any kind of payment on the lines of code produced. Employees would use cut and paste instead of avoiding duplicate code. The inverse is equally bad. People would probably stop working at all. Yet if you find that one team produces half the lines of code than all the others it is worth a second. Maybe they creating extremely crisp code or they are just lazy, or encounter serious problems. Almost the same applies when code coverage or toxicity deviates from the usual values. If all three numbers evolve as you are used to from other projects, development probably evolves as you are used to. And if something unusual happens it will probably show in the numbers pretty soon.