No Room for Improvement
How delivery pressure keeps software organizations from improving how they work
Consider what it takes to deliver a relatively ordinary software change in a large engineering organization.
An engineer implements a feature, writes tests, and opens a pull request. But the change touches several modules, each with different code owners. Reviews take time. CI fails, sometimes because of unrelated or flaky tests. Jobs get rerun. The engineer investigates failures that have nothing to do with the feature.
Eventually, the change is merged.
But it isn’t necessarily delivered.
Another team may need to integrate it into a service. Other teams may need to test and validate the resulting build. Integration problems emerge, bugs are filed, and changes make their way back through the same process.
The implementation might have taken a day. Getting the feature into customers’ hands can take weeks.
Engineers work evenings and weekends to navigate these obstacles. When the release finally ships, they’re congratulated for their heroic efforts.
While they deserve appreciation, delivering ordinary software shouldn’t require heroics.
None of these problems are new, and we know a great deal about how to solve them. Decades of research and experience have given us better ways to build, test, and deliver software. The harder question is why organizations that know these practices, and sometimes invest in adopting them, still struggle to deliver software effectively.
With AI coding tools promising dramatic productivity gains, the pressure to deliver more, faster is only increasing. But that pressure can come at a cost. When immediate delivery takes priority over improving how we work, we undermine our ability to deliver faster in the future.
We Can Afford Inefficiency, but Not Improvement
Here’s a paradox I’ve encountered repeatedly.
Organizations routinely absorb the costs of inefficient engineering systems. Developers spend hours investigating flaky tests, waiting for approvals, coordinating changes across teams, and attending meetings to discuss release blockers.
Those costs are spread across everyday engineering work. They’re rarely measured, and they’re often accepted as simply part of the job.
But propose taking a few engineers away from feature development to systematically eliminate those problems, and suddenly the cost becomes very visible.
There’s a release to deliver. There’s a roadmap commitment. An engineering productivity initiative may already be underway, and the organization can’t afford another.
The cost of improving the system is treated as a discretionary investment. The recurring cost of operating an inefficient system is treated as unavoidable.
This isn’t a new problem. In their 2001 paper, Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement, published in California Management Review, Nelson Repenning and John Sterman described the capability trap.
When organizations face performance pressure, they divert effort from improving their processes toward getting immediate work done. That helps in the short term, but leaves the underlying problems in place, increasing pressure and making future improvement even harder.
Organizations do invest in improvements, of course. But often through temporary initiatives.
A persistent problem becomes painful enough that leadership funds an initiative. A group of engineers is assigned to work on it for a few weeks or months. They make progress, delivering incremental improvements that may genuinely help.
Eventually the initiative ends, and everyone returns to their regular work. The improvements may be valuable, and some may even last, but the organization hasn’t fundamentally changed how it approaches improvement. Working smarter remains something we make time for occasionally, rather than a continuous part of how we operate.
The deeper, more difficult problems often remain unresolved. Not because the engineers didn’t do good work, but because addressing those problems requires sustained attention, investment, and sometimes changes to how teams are organized and work together.
When code reviews become a bottleneck, an organization might introduce response-time targets. That may help reduce delays, but it doesn’t necessarily address why so many changes require coordination across teams in the first place.
Sometimes we’ve made it easier to manage a problem without making the problem itself any smaller.
The organization can point to real progress while engineers continue struggling with many of the same underlying issues. And when the next release becomes urgent, improving the system once again takes a back seat to getting work through it.
Measuring Parts Instead of the Whole
The current enthusiasm for measuring developer productivity introduces another risk.
Metrics such as time from ticket to pull request or pull request to merge can reveal bottlenecks. But consider a team developing a shared library that must be integrated into another service before customers can use its features.
The library team might substantially improve its PR cycle time while the time required to deliver a working feature remains unchanged. Integration, validation, and deployment still happen elsewhere, and the delays between teams may not be measured at all.
Each team can appear to be getting faster while the overall organization isn’t.
This is one reason DORA emphasizes loosely coupled teams: teams that can develop, test, and deploy their work without extensive coordination with other teams are better positioned for continuous delivery.
AI coding tools make these distinctions even more important.
Suppose implementing a feature takes one day, but getting it through reviews, integration, testing, and deployment to production takes another fourteen days. If AI cuts implementation time in half, the total drops from fifteen days to fourteen and a half.
Implementing the feature takes half as long, but getting it into production is only about 3% faster.
It’s an illustration of Amdahl’s law: speeding up one part of a process has limited impact when most of the time is spent elsewhere.
But the consequences can be worse. If AI enables developers to produce changes more quickly, more work may queue up for review, integration, and testing. As those activities approach capacity, queues can grow disproportionately, increasing delivery times.
We may be accelerating the production of code faster than our organizations can absorb it.
DORA’s 2024 research found that greater AI adoption was associated with lower software delivery throughput and stability, despite improvements in individual developer productivity. Its 2025 report found a more encouraging result: AI adoption was now associated with higher throughput, although delivery stability continued to suffer.
The researchers concluded that AI acts as an amplifier of existing organizational strengths and weaknesses. Faster coding can improve delivery, but the benefits depend on the engineering systems and practices surrounding it.
That doesn’t prove that AI is slowing delivery through overloaded queues. But it reinforces an important point: improvements in individual productivity don’t automatically translate into improvements in software delivery.
We need to understand the entire journey from idea to working software, not just the parts that are easiest to measure.
Making Improvement Part of the Work
One of the original Agile Manifesto principles calls for teams to regularly reflect on how to become more effective and adjust how they work.
It’s one of the most valuable ideas to come out of agile, regardless of how we feel about its ceremonies.
Yet in organizations under constant delivery pressure, improving the way we work becomes something we do only when we find the time, or when management funds a special initiative.
I think we have that backward.
Improving engineering effectiveness should be part of the ongoing work of engineering, with real ownership and protected capacity.
One approach would be to establish a small, ongoing engineering effectiveness team. Its job wouldn’t be to own everyone’s CI pipelines or take over other teams’ responsibilities. It would work directly with engineers to identify persistent obstacles, experiment with improvements, and help successful changes become part of normal development.
For example, the team might work with a few feature developers to make local service integration and end-to-end testing a routine part of feature development. They could measure whether this catches problems earlier, reduces handoffs, and saves time during release validation.
The experiment might take a few weeks.
Experiments can be temporary, but responsibility for improvement shouldn’t be.
To make this sustainable, we also need to make the costs of the current process visible. Measure how long it takes to deliver a working feature, how much time is lost waiting or recovering from failures, and how much engineering and management effort goes into coordination.
Then use those measurements to evaluate improvements, not just to report productivity.
That creates a more meaningful investment case. Rather than asking leadership to fund another initiative on faith, we can demonstrate the recurring costs we’re trying to reduce and the value of improvements already made.
Leadership still needs to protect capacity for this work when the next release becomes urgent. Otherwise, the capability trap simply reasserts itself.
The engineers using these systems should be the customers of the improvement effort. Their experience, supported by meaningful delivery metrics, should tell us whether we’ve actually made things better.
What We’d Get Back
Consider how much management attention goes into coordinating software delivery: daily bug triage, lengthy status meetings, release readiness reviews, and escalations when things don’t go as planned.
These activities exist for understandable reasons. When delivery is unpredictable, managers need information and coordination to reduce uncertainty.
But more reliable engineering systems, clearer ownership, and teams capable of delivering independently could reduce the need for much of that coordination.
What would happen if we invested as much sustained effort in improving how we deliver software as we spend managing the delivery of software?
Managers could spend more time supporting their teams, understanding customers, exploring new opportunities, and improving the organization itself. Engineers could spend more time building useful software and less time navigating the machinery required to deliver it.
I used AI as a sounding board and editorial aid while developing this essay. The share image was generated with AI.