| > Each organization can set a wide range of metrics to follow every week, such as: > Number of commits. > Average commit size. > Frequency of code reviews. > Number of code reviews. > Time to review. > and so on... No. This has been tried many times and companies think this is how you measure productivity, but it is not even sustainable. Developer productivity is not about moving the needle, it is about outcomes, and not outputs. An outcome is finally merging an unsustainable PR that has sat for a month. It is not how many comments, reviews, meetings, or commits needed to get to the outcome. The only people I know who want to implement these terrible measurements are the type of people who have ambitions as large as Mount Everest but die on the decline back down. The real goal is to be more like a f1 pit crew where you leave out the metrics and end up performing better than if you measured them. |
What criteria does your team use to measure the outcomes and/or during a post-mortem?
> The real goal is to be more like a f1 pit crew where you leave out the metrics and end up performing better than if you measured them.
But all F1 pit crews have defined measurable metrics for success. I don't see the analogy here? Can you help me understand it?