The desire to measure developer productivity is reasonable. Engineering is expensive, much of its output is intangible, and leaders want to know whether the organization is becoming more effective.
The problem starts when a complex system is reduced to one convenient number.
Lines of code measure lines of code
More code does not mean more value. Sometimes the best engineering result is deleting code, simplifying a solution, or deciding not to build a new system at all.
The same is true for commits, pull requests, and completed tickets. These can help explain how work flows, but they become dangerous when turned into personal KPIs.
People quickly learn to produce what the system rewards.
Ticket counts are easy to game too
If a team is judged by the number of closed tickets, large tasks get fragmented, difficult problems become unattractive, and helping colleagues barely looks productive.
An engineer who spends a day helping three teams avoid the wrong decision may look less productive than someone who closes five small tasks.
The measurement system starts punishing exactly the work that makes the organization stronger.
Measure the flow of work
It is more useful to understand how well work moves through the system than how busy an individual appears.
How long does a change take from decision to production? Where does it wait? How much time goes into defects and rework? How often do releases create problems? How quickly does the team recover?
These questions point to system constraints rather than individual blame.
Connect engineering metrics to outcomes
High release frequency is not a goal if users are not better off. A low defect count may mean quality, or it may simply mean very little is changing.
A useful measurement system usually combines several levels: the team's ability to deliver change, the quality and resilience of the result, and the effect on product or business outcomes.
One metric rarely tells the whole story.
Do not turn team metrics into individual rankings
One of the most damaging mistakes is taking a metric that makes sense at team level and using it to compare individual engineers.
Software development is collaborative. A strong senior engineer may write less code because they work on architecture, reviews, difficult investigations, and developing others. Their contribution is designed to make everyone else more effective.
If the evaluation system cannot see that, it will gradually push those people away.
AI makes old activity metrics even weaker
When code can be generated faster, the volume of text produced becomes even less connected to engineering quality.
Problem framing, architecture, review, testing, risk recognition, and the ability to decide what should not be built become more important, not less.
Faster code generation does not turn a bad decision into a good one. It only gets you to the bad result sooner.
Measure the system, discuss the person
Engineering organizations need data. But evaluating an individual still requires context: what problems they solve, how they affect the team, what level of decisions they can make, and what gets better around them.
A metric should help leaders ask better questions. The moment it starts automatically answering “who is a good developer?”, it is probably measuring the wrong thing.