As such exactly what it is, will depend on company/industry/market/team/project/etc. It may be revenue or units sold or widgets made or turnover or customer satisfaction or days without accident etc. In principle, it communicates to teams what is important to business and helps everybody focus and sync.... with usual real-world caveats and implementation risks.
I imagine here, for a large-company linux team, a "KPI" was "how many commits you made" - they measure it, they track it, and reward/recognize/punish team members based on it. So people start working toward increasing the KPI in any feasible way - if you only want me to increase the KPI of commits done, OK, fine, I'll do some commits.
This is a great explanation, and I just wanted to nitpick that for some KPI's (e.g. percentage of defective components, or latency), you would aim to "decrease" the KPI, and in some rare instances, you'd want to keep the KPI within a range (e.g. resource utilization, or inventory size, when you want a predefined amount of buffer).
It's a shit system that does exactly the opposite of what it's supposed to do IMHO, but that kind of stuff doesn't belong in an ELI5 explanation :-D.
The issue isn't whether KPIs are good or bad but what you do with them.
KPIs don't need to be tied to actual people, usually they are tied to teams, systems, projects, processes, etc.
For example, a number of users resigning from our services might be a KPI.
KPIs are an important tool to understand what is going on and whether we are going in the desired direction or not and to communicate this to your teams.
KPIs are a tool for telling your organization what you think is important, to set the incentives in the right direction.
KPIs will not help you if you have no effing idea how to set incentives -- they are just a tool in case you know what you are doing.
Because they are just one step from being a target for your teams, you need to be very careful to communicate what you mean exactly when you set KPIs.
Now, if you make number of users resigning from your services a KPI, you immediately need to set some additional guarantees that this is not overused -- for example by making it difficult for your clients to resign. This might be another KPI (user satisfaction with regards to how easy it was for them to resign).
Humans are extremely good at gaming KPIs, and will do so as long as they're rewarded for it.
Organizations have hard time improving without measuring their performance and communicating incentives.
There isn't magical solution you can scribe on a paper and tell everybody -- this is exactly what you need to do to achieve success.
The best what you can do is compromise, it is unavoidable.
So we know setting targets can make wrong incentives. It is also not a reason to not be setting targets. It is a reason to make sure you damn set those incentives right and take close look that you are getting what you have intended.
Metrics are either (1) targets or (2) things that you are trying to analyze in relation to the metrics that are targets or (3) a waste of the time you spent gathering them.
The reason metrics are often bad when they become targets is the metrics arr usually not actual direct measures of goals, but things assumed to be convenient proxies, but when you push hard on optimizing them, they stop being good proxies because as well as being easier to measure than the real objective, once you pick any low-hanging productive fruit they are inevitably easier to improve in ways that don’t improve the real objective as much as the proxy (or at all, or which negatively impact it.)
You have a target that you can't measure directly, hence you measure a proxy. That only works for as long as people don't game it and aim for the proxy instead of the actual target. Also, in addition, at least in research every statistician worth their salt knows that their proxy is not the actual thing and only their best effort at approximating it, hence in good studies, limitations of the methodology are extensively discussed.
Importantly, the moment you realise that your proxy is being gamed, you need to switch proxy.
I think this is only one example of this annoying trend of pretending to be "data-driven" by coopting numbers and fancy statistics without also adopting everything we know about uncertainty and how we can quantify it. "Data" in many businesses often implies a level of clarity ("look, the graph always goes up") that often does not actually exist and I suspect that this can be hard to understand for certain types of managers.
Output metrics chosen correctly also tend to represent things that the team/person has a reasonable degree of control over. For example, a developer KPI probably shouldn't be number of new customers because that's something they have vanishingly little control over, especially at an individual level.
The problem is that those things that a number of different teams are contributing to are probably the thing that the company cares about.
If there's a single KPI and all the reward is tied to that without any balance, sure that will be gamed.
But if there is a well-defined, appropriately complex reward function aligned with the utility of whatever the organization delivers to the outer world, I would consider that a positive.
The original quote is
"Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."
I don't think there is a a good solution. Maybe with radically shortened work hours and less pay disparity, the strives can strive off the job instead.
This isn't just theory. This is precisely why there are laws that prohibit rewarding people based on how they voted.
> This is precisely why there are laws that prohibit rewarding people based on how they voted.
Voting is not an evaluation method of the voter: the voter is the one doing the evaluating. Because the powers should not discriminate between voters as you say, the vote cannot be used to evaluate the voters on and individual basis at all.
Maybe the answer is that: no individual/team assessments of any sort. That makes no incentives. But that also doesn't help with fine-grained strategy.
...by not tieing incentives to it? I feel like I must not understand your question because this seems blindingly obvious...
> Voting is not an evaluation method of the voter: the voter is the one doing the evaluating. Because the powers should not discriminate between voters as you say, the vote cannot be used to evaluate the voters on and individual basis at all.
I don't even get where you got this strawman from.
> no individual/team assessments of any sort. That makes no incentives. But that also doesn't help with fine-grained strategy.
No, just dont use KPIs that are critical to understanding your business in assessments tied to incentices because that will distort your KPIs and make you less capable of understanding your business.
Mondragon please get in the tech biz.
When there as many evaluators as evaluatees, no standard evaluation procedure is needed on the theory that all the different ways and biases will cancel out. That doesn't work over time, as clearly America's electorate gets interested in different things, but I am less worried about that for co-ops.
The hope for co-ops vs state democracy is two fold.
Firstly, because people do work many hours at their job, but don't necessarily spend any time running the state, I hope they are more informed and engaged.
Secondly, the "both options are bad, I hate this" problem should be addressed by A, proportional representation (just like should be done with state democracy states), but also B of switching jobs. The barrier of switching jobs is much lower than immigrating, which ought to more than any thing else reign in defeatist apathy. And Co-ops can still fire people, remember.
/s
Right, but my post, the post I was responding to, the post the post I was responding to was responding to, and the article in the link, was specifically about a situation where KPIs are tied to actual people. I'm not sure what you're arguing for or against.
Use SMART objectives (Specific, Measurable, Achievable, Relevant, Time-bounded) and set a realistic service uptime (e.g. how many nines you want in a given month/quarter/whatever) and KPIs directly enable good decisionmaking at all levels of the org.
Manager up in your grill about a choice you made? Point at the KPIs and say "this will help make it easier to meet our objectives for KPI 1.1" or whatever.
Engineer's performance is measured, in part, by number of kernel commits. So, the number of kernel commits is a key performance indicator for the developer.