[mystickphoenix]

Always good to remember "what gets measured gets managed". I.e., every single one of these metrics can easily be gamed in a way that would be hard for a non-technical manager or "bean counter" to determine.

Ex: oh, you're measuring number of commits, well, I'll stop squashing and start breaking commits down to single lines. Boom, I'm a 100x software engineer.

Does anyone have a decent list of individual contributor KPI's that are actually useful or insightful? I've, so far (~20 years of experience), never run into individual KPI's that weren't able to be gamed and were actually meaningful.

[dboreham]

The whole concept of KPI is bogus and worthless.

[aleph_minus_one]

I somewhat disagree; I rather like Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".

> 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.

[parpfish]

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.

[hdjjhhvvhga]

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.

[pomatius]

...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.

[jostiniane]

we use the number of closed tasks/user stories but also came across people gaming those too. Lower the scope and cut corners (shitty design, superficial meaningless unit tests, ...). The point I understood, is stay away from people gaming things and have a management tech savy too.. I wroked in a company where the CTO is tech illeterate and everyone is gaming everything, I worked somewhere else where the CTO is the smartest and most tech savy person I have ever met and gaming anything there becomes obvious and people are shown the door out of nowhere (yet for a good reason).

[cosmotic]

Measuring commits, loc, tickets, and story points, individually, might be gamble, but seeing all those consistently higher or lower seems like an okay indicator.