In this sense I do consider many KPIs often to be good metrics to find out whether the company is on the right path, or as an early warning system for problems that the company might become confronted with in the future.
But as soon as you use KPIs to assess managers, they will become gamed, and thus loose a lot of their value.
i think that KPIs often make sense at an organization level of a business, such as "We want to boost revenue from this product line by X%".
but when you try to translate that to the individual level, it's almost impossible because it's hard/impossible to properly attribute value to individual actions.
I think this is the key distinction. After two decades in the industry I can easily game any variable. Ant things change constantly. A person who seem unproductive today may surprise you tomorrow. You may consider yourself an excellent problem solver and then bump into something that is very difficult for you - but turns out easy for someone else. And so on and so forth.
...and attitudes like these are why most Software Engineering theory is BS. We refuse to measure things in a reproducible way, and would rather stick with subjective pre-scientific concepts such as "clean code" and hit-or-miss rules of thumb for project estimation. You need an objective way of measuring and testing whether your hypothesis (be it that clean codes improves maintainability, or that X strategy is reducing dev churning) is true, and good KPI's are that.
> https://en.wikipedia.org/wiki/Goodhart%27s_law
In this sense I do consider many KPIs often to be good metrics to find out whether the company is on the right path, or as an early warning system for problems that the company might become confronted with in the future.
But as soon as you use KPIs to assess managers, they will become gamed, and thus loose a lot of their value.