TLDR; Two-thirds of developers say current productivity metrics do not reflect their real contribution. The data reveals what actually matters: communication, tool reliability, and well-being. Here is how to measure what counts.1
A few weeks ago I sat in a leadership meeting where someone pulled up a dashboard showing lines of code per engineer, closed tickets per sprint, and pull request velocity. The numbers looked clean. The team looked exhausted. Nobody in the room could explain why the metrics were up but morale was down. That disconnect is not unusual. It is the norm.
The 2025 JetBrains Developer Ecosystem Report, based on 24,534 developers worldwide, exposes the scale of the problem. Sixty-six percent of developers do not believe, or are not sure, that current productivity metrics reflect their real contribution.1 That is two out of every three people on your team looking at the scoreboard and wondering if it is even measuring the right game.
What Actually Drives Productivity
The same report asks what influences developer productivity. The answers split into two camps, and both matter more than most organizations track.
Eighty-nine percent of developers say non-technical factors influence their productivity: job design, clear communication, peer and manager support, and actionable feedback.1 Eighty-four percent say technical factors matter too, specifically the performance and reliability of development tools.1 What is striking is that both numbers are far higher than the percentage of companies that actually measure these dimensions. Most teams have dashboards for deployment frequency and lead time. Very few have dashboards for communication clarity or tool friction.
I think the reason is comfort. Output metrics are easy to collect. They live in GitHub, Jira, and CI/CD pipelines. Input metrics—like whether developers feel supported, whether feedback loops are tight, whether tools are reliable—require talking to people. That takes time, and it does not fit neatly into a spreadsheet.
Who Is Responsible for Productivity?
Here is another uncomfortable finding. Most companies do not have specialist roles dedicated to developer productivity. The responsibility falls on team leads and even developers themselves.1 Teams focused on delivery are also expected to master measurement methodology, often without resources or proper training. We are asking people to optimize a system while they are still trying to ship features inside it.
This shows up in the investment gap. Technical managers say they want twice as much focus on communication issues and nearly twice as much investment in reducing technical debt as their companies currently deliver.1 The people closest to the work know where the friction is. The gap between what they want and what companies fund is a structural problem, not a tactical one.
The AI Trust Factor
The 2025 Stack Overflow Developer Survey adds another layer. With 49,000-plus responses from 177 countries, it is one of the largest snapshots of developer sentiment available.2 This year, 36.3% of developers learned how to use AI-enabled tools for their job or career.2 Adoption is no longer experimental. It is standard.
Yet trust is thin. More developers actively distrust the accuracy of AI tools (46%) than trust them (33%). Only 3.1% say they highly trust AI output.2 Experienced developers are the most cautious: their highly trust rate is just 2.6%, while their highly distrust rate is 20%.2
What this means for productivity measurement is that code volume is an even weaker signal than it used to be. If a meaningful portion of your code is AI-generated and a significant portion of your team does not fully trust it, then counting lines of code or PR throughput is measuring activity, not value. The real work is shifting to verification, context integration, and architectural judgment—activities that are hard to count and easy to ignore.
What I Changed on My Teams
At Wawandco and Symbol, we have started three practices that cost almost nothing and surface the signals that actually matter.
First, we replaced our weekly “what did you ship” standup with a weekly “what slowed you down” retro. We do not track the answers in a dashboard. We just listen. Patterns emerge fast. One team discovered that a slow staging environment was costing them two hours a day. Another found that unclear requirements were causing rework on half their tickets. The issues were invisible to Jira but obvious to the humans.
Second, we started a quarterly tool reliability survey. Three questions: which tools are fast, which are slow, and which ones make you want to switch careers. The results feed directly into our platform roadmap. Eighty-four percent of developers say tool reliability influences productivity.1 We treat that as a feature, not a feeling.
Third, we made one-on-one conversations about environment, not output. Managers ask about blockers, context, and support before they ask about deadlines. The shift is subtle but it changes what gets surfaced. When the conversation starts with output, people hide friction to look productive. When it starts with environment, friction becomes the agenda.
Measuring What Counts
None of this means throwing out DORA metrics or cycle time tracking. Those matter for understanding system health. But they are lagging indicators. They tell you what happened. They do not tell you why.
If you want to understand why your team is fast or slow, measure the inputs: communication clarity, feedback speed, tool reliability, technical debt load, and psychological safety. The JetBrains data is unambiguous. Eighty-nine percent of developers say these non-technical factors influence productivity.1 If you are not measuring them, you are managing by half the equation.
The best engineering teams I have worked with do not optimize for dashboard aesthetics. They optimize for the experience of doing the work. The metrics follow.
References
[1] JetBrains, “The State of Developer Ecosystem 2025,” 2025. https://www.jetbrains.com/lp/devecosystem-2025/
[2] Stack Overflow, “2025 Developer Survey,” 2025. https://survey.stackoverflow.co/2025/