Table of Contents
Open Table of Contents
- Introduction
- Shortening the Cycle of Testing Hypotheses
- Do More Releases Lead to Better Outcomes?
- Physical Productivity and Value-Added Productivity
- What Changes When AI Makes Implementation Faster?
- Faster Development Makes Communication an Even Greater Bottleneck
- Creating a Structure for Testing Hypotheses Together
- Closing Thoughts
Introduction
Hello.
Improving development productivity seems to be a topic of constant interest across software development teams.
Alongside established practices such as automated testing, CI/CD for continuous delivery, and architectures that are easy to change, incorporating AI into the development process to reduce the time spent on implementation and investigation has recently become another part of these efforts.
When thinking about these initiatives, I feel we need to step back and clarify why we want to improve development productivity in the first place.
Being able to write code faster and being able to create business value are not quite the same thing. People also have slightly different ideas about what productivity actually means, so that needs clarification too.
In this article, I want to organize my thoughts on what improving development productivity leads to, and whether improvements within the development team alone are enough.
Shortening the Cycle of Testing Hypotheses
Suppose we have an idea: adding an integration with an external system might help us acquire new customers. A few decades ago, a common approach would have been to build confidence through customer interviews and market research, then spend months or even years (!) developing the feature. But of course, we cannot know everything in advance: how much customers will actually use it, or whether it will be the deciding factor in increasing revenue.
That means we need to do more than carry out the initial plan. We need to deliver quickly, learn from the results, and use that learning to guide subsequent development. If the hypothesis looks promising, we can stay on course and continue developing. If the results fall short of our expectations, we need to reconsider the feature or work on a different problem. Whether we can make that decision in one month or six makes a substantial difference to the options available afterward.
I believe one of the main reasons to improve development productivity is to make it possible to repeat this process of testing hypotheses in shorter cycles. The goal is more than building a predetermined solution quickly. We need to be able to change what we build next based on what we learn from what we have already built.
Do More Releases Lead to Better Outcomes?
Here, we need to distinguish between development delivery capabilities and business outcomes.
Imagine a team that releases ten features every week but never checks whether those features are being used or solving customer problems. Now imagine another team that releases two features a week, checks usage and customer responses for each, and continuously improves business metrics.
Looking only at the number of features released, the first team might appear more productive. But I think what matters is whether the team can see what changed as a result of what it built, as the second team does.
Of course, feature counts alone cannot tell us how capable a development team is. Features differ in size and difficulty, and work such as improvements to reduce incidents does not count as a new feature. The essential point of this example is that increasing output and improving outcomes are different things.
Releasing a feature → Delivering value that keeps customers using the product → Supporting contract renewals and revenue
We need to follow that whole chain.
Still, improving development productivity does not necessarily increase revenue or profit. Testing an idea may reveal that it never had the value we expected. Even then, discovering that sooner lets us stop investing in it and explore other possibilities.
With that in mind, I see improving development productivity as a necessary investment in increasing the likelihood of achieving business outcomes, rather than a guarantee of those outcomes.
Physical Productivity and Value-Added Productivity
Two perspectives help organize this discussion: physical productivity and value-added productivity.
Physical productivity looks at the quantity of output produced relative to the resources invested. Value-added productivity looks at how much added value those resources generate.
The difficulty with software is deciding what counts as the quantity of output in the first place. More lines of code are obviously not always better. Removing unnecessary code can actually make software easier to change. As discussed earlier, feature counts are not directly comparable either.
Development teams therefore need to look beyond output volume and examine delivery performance: how quickly and safely they can deliver changes.
For example, where does work wait between implementation being completed and a release? How much manual checking is required for each change? Can we restore the previous state when an incident occurs? These are areas where development teams can readily work on improvements.
On the other hand, what to build with that capability, and how much value it creates, unfortunately cannot be determined within the development team alone. We also need to understand customer problems, set business priorities, get people to use what we build, and examine the results.
That is why we need to improve the development capabilities within our control while also thinking about the collaboration needed to turn those capabilities into business outcomes.
Ryutaro Yoshiba’s presentation “Value Creation and Development Productivity” (in Japanese) explores the relationship between development productivity and value creation in detail. It is an excellent resource for thinking about why we want to improve productivity, so I encourage you to take a look.
What Changes When AI Makes Implementation Faster?
Using AI to generate code, write tests, and investigate existing code can shorten individual tasks. This is an important way to improve development capabilities. To translate AI’s capabilities into productivity gains, we need to clarify what information to give it and make the relevant design decisions and constraints available for reference. This is the idea commonly called context engineering.
Established practices remain just as important, including automated tests to check the effects of changes and CI/CD that lets us release in small increments.
For example, StrongDM’s “The StrongDM Software Factory: Building Software with AI” describes a software factory where humans define specifications and constraints, and AI agents handle code generation, verification, and improvement.
But even with all of that in place, we will not test business hypotheses any faster if decisions about what to build, or evaluations of the results, are stalled.
Faster Development Makes Communication an Even Greater Bottleneck
Suppose a feature takes only a few days to implement, but coordination and approvals across departments take several weeks, and customer reactions never reach the team after release. That does not make hypothesis testing any faster. As development accelerates, these communication delays become a bottleneck.
Organizational silos create another problem. If the business team’s knowledge of customer problems and the development team’s technical knowledge are not shared, it becomes harder to find ways to test hypotheses with smaller changes. Simply handing over specifications may lead us to build a large feature when a small adjustment to an existing one would have addressed the problem.
Communication therefore affects both waiting times and decisions about what to test and how large a change it requires. It can become a bottleneck for the entire development cycle.
Creating a Structure for Testing Hypotheses Together
When addressing these problems, I think perspectives such as Team Topologies and DevOps, which examine relationships and collaboration between teams, are important. We need to identify where information and decisions get stuck in our own organizations, then reconsider team responsibilities and approval processes.
From there, business and development teams should share customer problems and business goals, then test hypotheses with the smallest changes needed. We want to collaborate all the way through reviewing results together and using them to make the next decision.
We should retain necessary checks while reducing waiting times that exist simply out of habit. I believe what matters is creating an organization that can test hypotheses quickly as a whole, alongside improving the productivity of individual development teams.
Closing Thoughts
Improving development productivity lets us deliver changes sooner. That, in turn, can shorten the time it takes to learn from the market and our customers and make the next decision. This connection is extremely important.
That is why I want to keep investing in automated testing, CI/CD, architectural improvements, and AI, while making sure the business can put the resulting development capabilities to use. Doing so requires us to look at bottlenecks within development, coordination across departments, decision-making, and the process of learning from customers.
When thinking about improving development productivity, I believe we need to consider that whole chain.