"I get it. I've seen enough terrible systems to understand the resistance. Most systems fail, thanks to Goodhart's Law. Measure the lines of code written, and people jack up verbosity. Measure the number of PRs, and people start dividing up their PRs. Yet, it all feels like you have to measure something. Every manager knows that some people are more productive than others."
"Here's the uncomfortable truth: you can measure engineering productivity. The goal is not to have a purely objective system where you stack rank people but rather to make it obvious to everyone, including the people being measured, the level of their output, especially compared to people around them. Yes, outcomes matter most. I want to ship features that users love, fix bugs that matter, and build systems that scale."
Measuring engineering productivity is possible and useful for revealing output and informing improvements. Goodhart's Law creates perverse incentives when poorly chosen metrics like lines of code or PR count are used. Outcomes remain the priority, but outcomes often depend on observable output. A measurement approach should make individual output transparent relative to peers without converting metrics into a punitive stack rank. Management should absorb most of the measurement overhead to avoid burdening individual contributors and to reduce gaming. Practical, minimally burdensome systems can encourage rapid, high-quality product delivery and enable targeted adjustments where needed.
Read at Off By One
Unable to calculate read time
Collection
[
|
...
]