Hacker News new | ask | show | jobs
Ask HN: KPI's for Developers / Metrics for Devs?
2 points by kpithrowaway 2725 days ago
We didn't ship the things we wanted to last quarter because we were too ambitious in setting goals (we should have committed less)...and our director also happened to leave mid-quarter. The leadership team is now asking us to implement KPI's. The rest of the company has them, so shouldn't the dev team? In their best world, every individual in the company would have KPI's...so you can see when someone is doing their shit and if they're not, you can address it.

Honestly, I'm skeptical. "When a measure becomes a target, it ceases to be a good measure." (Goodhart's Law). I especially don't believe in individual KPI's.

What kinds of metrics could we look at using to satisfy the rest of the company without making devs lives harder? How hard should we push back against individual KPI's? Are individual KPI's even possible? What about team KPI's? Are there any good books or articles out there that can help solve this problem?

Thanks!

2 comments

I found Accelerate[0] by Dr. Nicole Forsgren, Jez Humble, and Gene Kim has a lot of good analysis on metrics one might use.

I think it's important to keep in mind that ultimately a dev is part of team that delivers value for a company, so the metrics one uses needs to take that into account. It can definitely be harder if others in the group (company, team, whatever level you want to consider) are viewing things on a more isolated, individual level, but I think it's in part those isolated, individual level metrics that keep one from viewing the bigger picture and one's role in it. You have to figure out what metrics you can put into place that are meaningful and practical for your given situation. I think Accelerate can provide a good starting point for what those metrics can be. Along with OKRs[1] for goal setting, I think you can find something that works for you.

[0]: https://itrevolution.com/book/accelerate/

[1]: https://en.wikipedia.org/wiki/OKR

One approach I can recommend against: making "% of sprint commitments completed" a KPI. When that was implemented, suddenly time estimates (we used hours instead of story points) on everything tripled.
That's fair.

Exactly the kind of measurement I'd like to avoid. Same thing with velocity. If that's the metric, it makes you want to bloat estimates, create additional tickets with lots of points, and you are insensitivized into avoiding helping eachother out because it doesn't help your individual points.