In the pursuit of data-driven management, many engineering organizations fall into a common trap: when a measure becomes a target, it ceases to be a good measure. This phenomenon, known as Goodhart's Law, is particularly relevant in software engineering, where the complexity of our work often defies simple quantification.

The Allure of Metrics

It's understandable why engineering managers are drawn to metrics. In an industry where outputs are largely invisible and progress can be hard to track, numbers provide a sense of control and objectivity. Lines of code, commit frequency, bugs fixed, and story points completed all seem like rational ways to measure productivity.

But here's the problem: the moment these metrics become targets, they begin to shape behaviour in ways that can actually harm productivity and code quality.

When Measurements Go Wrong

Let's examine how common metrics can lead to counterproductive behaviours:

Lines of Code (LOC)

Remember the days when developers were evaluated by their LOC? This classic example shows exactly how metrics can backfire. When developers are incentivized to write more code, they often write unnecessarily verbose code, avoid deleting obsolete code, and shy away from refactoring that could make the codebase more maintainable. As Bill Gates famously said, "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

Commit Frequency

When managers start tracking commit frequency, developers might begin breaking up logical changes into smaller, less meaningful commits. This can make code reviews more difficult and obscure the actual pace of development. Worse, it might encourage pushing incomplete or untested code just to meet daily commit targets.

Bug Closure Rate

Tracking the number of bugs fixed seems reasonable until you consider the perverse incentives it creates. Developers might begin labelling minor issues as bugs to inflate their numbers, or worse, might be tempted to introduce easy-to-fix bugs intentionally. This metric can also discourage thorough investigation of root causes in Favor of quick, superficial fixes.

Story Points Completed

While story points were meant to be a relative measure of effort, when they become a target, teams often begin gaming the system. This can lead to inflated estimates, artificially broken-up stories, and a preference for easier tasks over important complex work that could deliver more value.

A Better Approach

So how should we measure developer productivity? The answer lies in taking a more holistic, outcome-focused approach:

1. Focus on Business Outcomes Instead of measuring pure output, track how development work impacts business metrics like customer satisfaction, system reliability, or feature adoption rates.

2. Monitor Team Velocity Over Individual Metrics Teams are more than the sum of their parts. Measuring team-level outcomes encourages collaboration and knowledge sharing.

3. Emphasize Quality Indicators Consider metrics like test coverage, time to recover from incidents, and technical debt reduction as part of the overall picture.

4. Create Learning-Focused Environments Foster a culture where metrics are used for learning and improvement rather than performance evaluation.

The Path Forward

The key is to remember that metrics should be guides, not goals. They should spark conversations, not control behaviour. When we use metrics as tools for learning rather than instruments of evaluation, we create an environment where true productivity can flourish.

Engineering leaders would do well to remember that the most valuable work often can't be measured directly. Innovation, mentorship, code quality, and architectural improvements might not show up in daily metrics, but they're crucial for long-term success.

Practical Steps for Engineering Leaders

1. Use metrics as conversation starters, not performance evaluators

2. Combine multiple metrics to get a more complete picture

3. Focus on trends rather than absolute numbers

4. Regularly review and adjust which metrics you track

5. Create space for unmeasurable but valuable activities

Conclusion

In the end, the best measure of developer productivity might not be a measure at all, but rather the sustainable delivery of value to customers. By focusing on outcomes over outputs and creating an environment that values quality and collaboration, we can avoid the metrics trap and build better software.

Remember: Not everything that counts can be counted, and not everything that can be counted counts.