[srvaroa]

Yep, this is an important point.

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

[hinkley]

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.