Two-thirds of developers believe current productivity metrics fail to capture their real contributions. That’s 66% of 24,534 developers across 194 countries telling JetBrains their managers are measuring the wrong things. While 85% of developers now use AI tools, the industry still measures productivity with velocity charts and story points designed for 2010. This measurement crisis is destroying team collaboration, inflating technical debt, and driving 40% turnover in metric-obsessed organizations.
The Traditional Metrics Are Broken
Velocity and story points measure activity, not outcomes. A developer who ships three features quickly looks productive. A developer who spends a week preventing a catastrophic architecture mistake looks idle. Guess which one gets the better performance review?
Story points are shared fiction. They’re entirely subjective – a “5-point story” for one developer might be a “2-pointer” for another. Teams under pressure inflate estimates or avoid complex but valuable work. Code review, mentoring, unblocking teammates? Doesn’t count toward sprint velocity, so why bother?
The consequences are measurable. Collaboration breaks down because helping others hurts individual numbers. Developer satisfaction drops 60%. Quality degrades while metrics “improve.” Some organizations see 40% turnover within six months as developers flee cultures that measure them like factory workers.
When two-thirds of developers feel misunderstood by their performance measurements, that’s not a communication problem. That’s a systemic failure.
What Developers Actually Want Measured
The JetBrains 2025 survey reveals a striking disconnect: 62% of developers cite non-technical factors – collaboration, communication, clarity – as critical to their performance. Only 51% cite technical factors. Yet current metrics focus almost entirely on technical output like lines of code and commit frequency.
Developers aren’t asking for participation trophies. They want to be measured on what matters: impact instead of output, architecture decisions that enable future work, code review quality that prevents bugs, mentoring that multiplies team effectiveness. The shift isn’t from “how fast” to “how slow” – it’s from “how fast” to “how well” and “how sustainably.”
Consider what velocity metrics miss: the developer who identifies a design flaw before it ships, preventing weeks of rework. The senior engineer who unblocks three teammates instead of writing code. The architect whose upfront design enables rapid feature development for months.
When you optimize for velocity, you get fast code. When you optimize for impact, you get valuable code. These are not the same thing.
Better Alternatives Exist (But Companies Won’t Use Them)
The frameworks already exist. DORA metrics – deployment frequency, lead time for changes, change failure rate, mean time to recovery – focus on delivery efficiency rather than individual output. Research shows elite DORA performers are twice as likely to meet organizational goals.
The SPACE framework goes further: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. It’s a holistic view of engineering effectiveness that includes the human factors velocity metrics ignore. Used together, DORA identifies what’s happening in your delivery pipeline while SPACE illuminates why.
GitHub, Microsoft, and Google use these frameworks internally. They work.
So why doesn’t your company? Complexity is the excuse. DORA and SPACE require sophisticated tooling and nuanced interpretation. Managers want simple numbers – “team velocity is up 15%” fits in a status report. “Our SPACE metrics show improving satisfaction but declining flow due to increased context switching” requires explanation.
But the real reason is control. Better metrics require trusting developers more and measuring managers more. That’s not a technical problem – it’s a leadership failure.
AI Made Everything Exponentially Worse
Here’s where the measurement crisis becomes acute: 85% of developers use AI tools, but we can’t measure AI-assisted work accurately. A METR study found experienced developers took 19% longer with AI assistance – contradicting their perception of being 20% faster. Sixty percent of engineering leaders cite “lack of clear metrics” as their biggest AI challenge.
The problem is fundamental. AI inflates traditional metrics without adding value. Lines of code go up. Story points completed per sprint increase. Velocity charts trend upward. But features built with heavy AI assistance take 3.4 times longer to modify six months later. You’re optimizing for the wrong timescale – by the time you realize the technical debt bomb has detonated, the quarterly bonuses are already paid.
If 85% of developers use AI and we can’t measure AI-assisted work accurately, then current metrics are measuring the wrong thing for most work being done. The dirty secret: we have no idea if AI productivity actually works.
What Needs to Change
The solution is obvious: adopt DORA, SPACE, or similar frameworks with executive buy-in. Measure management effectiveness – interruptions, slow CI pipelines, unclear requirements – instead of just developer output. Focus on removing impediments rather than tracking velocity.
Most companies won’t do this. They’ll keep using story points because they’re familiar, even as developers quit and quality degrades.
Here’s the uncomfortable truth: if 66% of developers say your metrics don’t work, the metrics aren’t the only thing broken – your management culture is broken too. You can fix the metrics and keep the same command-and-control mindset, or you can question why you’re measuring developers like assembly line workers.
The radical alternative, suggested by Hacker News discussions: stop measuring developers entirely. Measure outcomes – did the product ship, does it work, are customers happy? Treat developers as customers of the management team rather than units of production.
The measurement crisis is real. The alternatives exist. The question is whether leadership has the courage to admit their current approach is actively harming the teams they’re trying to optimize.
