Guides
Software Delivery
How Do You Improve Software Delivery Without Just Adding More Engineers?
CH2 Solutions
.
9
min read
More engineering capacity only improves delivery when capacity is actually the constraint.
LEADERSHIP CHALLENGE
If adding more engineers is not improving delivery, what is actually slowing your team down?
When software delivery slows down, adding engineers can feel like the most direct solution.
Sometimes it is.
But engineering teams do not deliver software based on headcount alone. Work moves through a system of product decisions, requirements, architecture, development, reviews, testing, deployment, and feedback. A constraint anywhere in that system can limit the output of the entire team.
If engineers are waiting for decisions, adding engineers creates more people waiting.
If senior developers are bottlenecks for every review, adding junior developers can increase the queue.
If requirements arrive unclear, more development capacity may simply produce more rework.
And if technical debt makes every change difficult, adding people does not remove the friction built into the system.
Before increasing headcount, technology leaders need to understand how work actually moves from idea to production—and where that flow is breaking down.
Executive Summary
Improving software delivery starts with identifying the constraint that is limiting the flow of valuable work.
That constraint may be engineering capacity, but it may also be slow product decisions, unclear requirements, overloaded senior engineers, dependencies between teams, excessive work in progress, technical debt, manual processes, quality issues, or delayed feedback.
Adding engineers works when there is valuable, ready-to-execute work and insufficient qualified capacity to complete it. When another part of the delivery system is limiting throughput, additional headcount can increase cost and coordination without materially improving delivery.
Instead of starting with team size, look at the path work takes from priority to production.
Where does work wait?
Where does it get sent back?
Where are decisions concentrated?
Where does rework occur?
Where does the team repeatedly lose momentum?
Improving those constraints often creates capacity that already exists but is currently trapped inside the delivery system.
Follow the Work
Trace important work from priority to production and identify where it spends time waiting as well as where active work occurs.
Find the Constraint
Identify what most consistently limits progress—capacity, decisions, reviews, testing, dependencies, architecture, or another bottleneck.
Reduce WIP
Limit simultaneous initiatives so the team can focus on completing valuable work instead of continually starting more.
Remove Waiting
Reduce unnecessary handoffs, clarify ownership, and bring the people needed to make decisions closer to the work.
Add Capacity
Add qualified engineering capacity when you can clearly identify the constraint it will remove and the work it will accelerate.
Improving software delivery starts with understanding how work actually moves through the organization. Find the constraint first, then address the specific source of delay. Sometimes that means adding engineers. Often it means creating more leverage from the capacity you already have.
Key Takeaways
• Software delivery is a system. The slowest constraint can limit the output of the entire team.
• Adding engineers helps when qualified engineering capacity is genuinely the limiting factor.
• Waiting, handoffs, unclear decisions, rework, and excessive work in progress can consume significant delivery capacity.
• Senior engineers frequently become hidden bottlenecks when too many decisions, reviews, or specialized tasks depend on them.
• Technical debt can reduce the effective capacity of an engineering team even when headcount remains unchanged.
• The fastest way to improve delivery is often to remove the constraint preventing existing capacity from becoming completed work.
Software Delivery
Software delivery is the system through which an organization turns business priorities into working software available to users.
It includes more than development. Product decisions, requirements, design, architecture, engineering, testing, reviews, deployment, infrastructure, and feedback all influence how quickly and reliably work reaches production.
Improving software delivery means increasing the organization's ability to move valuable work through that system without creating unnecessary waiting, rework, quality problems, or management overhead.
Engineering capacity is one component of that system—but it is not always the component limiting performance.
Find the Constraint Before Adding Capacity
Follow the work
Choose several important initiatives and trace how they moved from priority to production. Look at where work spent time waiting as well as where people were actively working on it.
Find the constraint
Identify the point that most consistently limits progress. It may be engineering capacity, product decisions, architecture, reviews, testing, infrastructure, dependencies, or another part of the delivery system.
Reduce work in progress
Too many simultaneous initiatives divide attention and increase context switching. Finishing fewer things faster can improve delivery more than starting additional work.
Remove unnecessary handoffs and waiting
Bring the people needed to make decisions closer to the work. Clarify ownership, improve product and engineering communication, and reduce dependencies that repeatedly stop progress.
Add capacity where it creates leverage
Once the constraint is understood, determine whether additional engineering capacity will remove it. Add people where they can directly increase the flow of valuable work—not simply because the organization has more work than it can ever complete.
Leadership Lens
When delivery slows, the visible symptom is often that engineering cannot keep up.
That does not always mean engineering is the problem.
We have seen teams with plenty of developers where work waits for product decisions. Teams where every meaningful technical decision depends on one senior engineer. Teams where developers spend significant time working around legacy architecture. And teams running so many initiatives simultaneously that everything moves slowly.
Adding engineers to those environments can make the organization larger without making it faster.
That is why we look at capacity, delivery, and execution risk together.
Sometimes the answer really is more engineers. There is valuable work ready to move, the delivery system is functioning well, and the team simply needs additional qualified capacity.
In that situation, adding the right engineers can create immediate leverage.
The important part is knowing the difference.
FAQ
What are the most common causes of slow software delivery?
Slow software delivery can result from insufficient engineering capacity, unclear priorities, slow product decisions, excessive work in progress, technical debt, dependencies between teams, overloaded senior engineers, manual processes, quality problems, or delayed feedback. The important step is identifying which constraint is actually limiting the flow of work.
Will adding more developers improve software delivery?
It can, but only when engineering capacity is the primary constraint. If developers are waiting for decisions, reviews, requirements, infrastructure, or other teams, adding more developers may increase coordination without improving throughput.
How can you identify bottlenecks in software delivery?
Follow work from priority to production and look for where it spends time waiting. Pay particular attention to recurring queues around decisions, code reviews, testing, approvals, deployments, specialized expertise, and dependencies between teams.
How does technical debt affect software delivery?
Technical debt can make changes slower and riskier by increasing complexity, creating fragile dependencies, and requiring engineers to spend more time understanding or working around existing systems. Over time, this reduces the effective capacity of the engineering team.
Why does too much work in progress slow engineering teams down?
When teams work on too many initiatives simultaneously, attention becomes fragmented and context switching increases. Work may be started quickly but completed slowly. Limiting work in progress can help teams focus on finishing valuable work before starting more.
How can product and engineering teams improve software delivery together
Sources and Further Reading
Google Cloud / DORA — Software Delivery Performance Research
DORA's research examines the technical, organizational, and cultural capabilities associated with software delivery and organizational performance, including delivery speed, stability, and continuous improvement.
The DevOps Research and Assessment Team — DORA Metrics
Research and guidance around deployment frequency, lead time for changes, change failure rate, and recovery performance provide useful ways to examine how effectively software moves through an organization's delivery system.
https://dora.dev/guides/dora-metrics/
Accelerate — Nicole Forsgren, Jez Humble, and Gene Kim
Research examining the technical and organizational capabilities associated with high-performing software delivery organizations.
https://itrevolution.com/product/accelerate/
The Principles of Product Development Flow — Donald G. Reinertsen
Explores queues, work in progress, batch size, feedback, and other principles that influence the flow of product development work.
