Why Developer Productivity Engineering is Underrated

#developerproductivity #dx #ai #dpe

This article was originally published on igorvoloc.com
I write about Developer Productivity Engineering — DX, AI-assisted dev, legacy migration, and business impact from the trenches.

I tracked my own time for two weeks, logging each hour. The numbers were discouraging enough that I stopped. Most of what I called ‘development time’ was actually spent waiting, searching, context-switching, rerunning flaky tests, or digging through outdated documentation and message threads.

This isn’t unique to me. It’s common, and most teams have come to accept it as normal. This invisible waste is what Developer Productivity Engineering (DPE) aims to eliminate.

There’s a deeper reason these problems persist: the people with the power to fund solutions almost never hear about them. Developers spot the slow builds, flaky pipelines, and broken docs immediately — but that pain rarely travels up the chain. Most engineers simply work around it, patching things locally or absorbing the friction as part of the job. By the time leadership hears about the issues, it’s usually reached crisis level.

The Waste Is Real

Developers lose hours each week to friction instead of building a product.¹ 58% report losing five or more hours weekly to inefficiencies like slow builds, broken tooling, and knowledge gaps—a number I’ve observed almost everywhere, and which matches the data.

62% of developers cite technical debt as their top frustration, while over 10% work at companies lacking CI/CD, automated testing, or DevOps.²

61% of developers spend at least 30 minutes per day searching for information.³ Over a third are blocked by knowledge silos, and a similar share re-answer questions they've already solved.³ People call it a documentation problem, but it's also an architecture and onboarding problem. Knowledge and culture get little attention, do the most damage, and rarely show up on dashboards.

On a team of 50 developers with an average salary of $150K (based on US developer salary benchmarks), 30 minutes lost per person each day adds up to nearly $500K per year. That’s the equivalent of three full-time engineers lost to inefficiency.

The waste is the problem DPE aims to solve. Most organizations under-invest in it.

Nobody’s Fixing Developer Productivity — Here’s Why

Your sales team gets a CRM. Nobody asks them to manage deals in a spreadsheet. Finance gets proper accounting software. Nobody questions the ROI on that.

Developers, often among the highest-paid and hardest to replace, must work around friction. They deal with broken CI pipelines, undocumented services, and spend time searching for information that should be readily available.

Here’s the part most managers don’t see: staff and senior engineers on your team are already doing DPE work. They just don’t call it that.

They notice the build is slow and spend a Saturday morning tracking down why. They write the runbook nobody asked for. They push for the migration nobody wants to focus on.

This is DPE work: invisible, uncredited, and taking time away from what teams actually measure. I’ve watched good engineers burn out this way — doing the most important work in the company while getting zero credit for it.

Half of tech managers say their companies measure productivity or DevEx, but only 16% have anyone dedicated to improving them.⁴

66% of developers say productivity metrics miss their real contributions.⁵ Most rely on crude measures: lines of code, story points, commit frequency. Engineers can game these in a month. Everyone knows the numbers aren’t real. And 60% of engineering orgs follow no specific measurement framework,¹ though 90% rate improving productivity as a top initiative (8.2/10 on average).¹

DORA’s 2025 research, surveying nearly 5,000 professionals, confirms the pattern: only 40% of teams excel at both speed and stability.⁶ The rest are held back by process friction and foundational gaps — not trade-offs. The “speed vs. stability” compromise is a myth: the best teams do both.

The core issue is that measuring is easy, but fixing is hard. If you track but never fix, you’re just surveilling. Trust drops, and nothing improves.

What Developer Productivity Engineering Actually Is

DPE is broader than developer experience. DX is one part, but not the whole. DPE treats the developer ecosystem as a system with four interconnected pillars:

Developer Experience — feedback loops, cognitive demand, flow state
Engineering Infrastructure — build systems, CI/CD, test automation, platform tooling, legacy migration
Knowledge and Culture — how information flows, gets captured, and outlasts turnover
AI Augmentation — how AI tools sit on top of and multiply whatever the other three produce

If one pillar is weak, the others can’t compensate. Developer experience is where most of that friction shows up first — and the most useful way to think about DX focuses on three dimensions that include most of what matters: feedback loops, cognitive demand, and flow state.⁷

Feedback loops are the most obvious. How long from git push to “did this work?” If the answer is 20 minutes, you’ve already lost the thread.
Cognitive demand is trickier. It’s not only about whether the code is hard; it’s about how much you need to remember to make a safe change. Every undocumented service boundary and each hidden dependency adds a hidden load. You only notice it when a new hire takes three months to become productive.
Flow state is the 2-3-hour window when someone is actually solving a hard problem. How often does the environment protect it?

The biggest influence on DX isn’t tooling — it’s cultural and organizational factors: how product management works, how decisions get made, and how teams communicate.⁷ Tooling matters, but the org sets the ceiling. This is why so many “DX improvement” initiatives fail: they buy tools without addressing the environments in which those tools operate.

Legacy systems are a drag on every engineer who touches them. Patterns like strangler fig and incremental migration work, but only if someone gives them priority. In most organizations, that person is a staff engineer making the case to leadership who don’t feel the friction directly.

And then there’s AI, which builds on top of all three pillars. According to DORA’s survey of nearly 5,000 professionals, over 80% of developers say AI has increased their productivity.⁶ About a third of new code in surveyed organizations now comes from AI.⁸

But AI only multiplies the system you already have. If your DX is good, AI tools make it even better. If your DX is broken, AI just makes things break faster.

The DORA 2025 report — the most comprehensive study of AI in software development to date — calls AI “an amplifier.”⁶ It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. At Adidas, teams with loosely coupled architectures and fast feedback loops saw 20–30% productivity gains from AI and a 50% increase in “Happy Time.” Teams with slower feedback loops due to tight coupling saw little to no benefit.⁶

The Fix Exists — And It Compounds

The ROI Is Real

Intervention	Result	Source
DX Core 4 framework	3-12% increase in engineering efficiency	DX (Core 4) ⁹
DX Core 4 framework	14% increase in R&D time on feature development	DX (Core 4) ⁹
Top-quartile DXI	43% higher employee engagement	DX (DXI) ¹⁰
AI + fast feedback loops (Adidas)	20-30% productivity gains, 50% more "Happy Time"	DORA 2025 ⁶
AI + developer training (Booking.com)	Up to 30% increase in merge requests	DORA 2025 ⁶

A single point increase on the Developer Experience Index saves 13 minutes per developer per week. On a 200-person team, a 5-point improvement adds up to 11,000 developer-hours per year. That’s equivalent to five full-time engineers without additional hiring.

DPE interventions compound over time. Better DX means less time lost to tools and faster delivery. It also improves customer satisfaction — and this is where the numbers get serious.

24.5% of developers are happy at work. 47.1% are complacent. 28.4% are actively unhappy.¹¹ The top satisfaction factor is autonomy and trust.

DPE maps directly onto what keeps engineers engaged — autonomy through better tooling, trust when you eliminate surveillance metrics, and quality because the environment actually supports the work. On a 50-person team, preventing even one or two senior departures per year can pay for a DPE initiative on its own.

Where to Actually Start

You don’t need a large initiative. One person with focus and about 90 days can make a difference. There’s no three-step plan — every organization is different.

The main mistake is treating DPE as a one-off initiative. It’s a practice, like security reviews or performance testing, that needs persistent attention.

But you still need a starting point. Identify the top three pain points by asking, not guessing. A short survey or a few brief conversations across teams is usually enough. The answers often differ from leadership’s assumptions, and the fixes are usually smaller than expected.

Fix one issue and measure the result. Problems are normal: migrations take longer, process changes meet resistance, or metrics don’t move as expected. Use early wins to gain credibility for the next improvement. Bring data.

If you’re a staff or senior engineer who struggles to get leadership’s attention, the data here is for you. You’ve likely been doing DPE work already, even if it’s invisible. Now you have a framework and a name for it.

What’s the one thing on your team that makes you close your laptop and walk away? I’m genuinely curious.