Agreed. And "personal metrics" can also end up having a lot of consequences that were not planned for. Incentives are tricky that way. There's always a long tail of things that need to get done on occasion that doesn't show up in these types of metrics and it becomes difficult to find takers when everyone is optimizing themselves around the core metrics as bonuses, promotions, and even keeping your job in today's climate could be determined by those. It also makes allocating load to play to contributors strengths (which is often what they enjoy most) far more difficult.
We wanted the metrics to create the right set of incentives to make people improve the right parts of the system.
For example, we did present deploy frequency prominently. This gets people to see it, managers to want their team to be in the upper percentiles, etc. which drives a set of practises that, in general, and backed by research, are beneficial.
One of my favourite features was putting two graphs together: size of PRs vs. time to review. Time to review went up more or less linearly to size of PRs, but past a certain threshold (different per team!) time to review dropped sharply with larger size of PRs. This made for a good conversation to topic with teams that sets the right incentives for smaller PRs, iterative development, etc. (and it happens to correlate with deploy frequency).
Might also suggest a size limit for PRs. Theres always that Golden Child who gets away with things because they are prolific. But they tend to screw up architecture because they make too-big moves that discourage feedback and negotiation.
