Build vs improve tradeoff

Build vs improve tradeoff: how should organisations allocate effort between feature delivery and throughput-improvement work, and what do theoretical models imply for velocity, quality, and Pareto-shaped outcomes?

2026-05-09 · tools-infrastructure mlops-deployment workforce-skills cost-performance organisational-design software-engineering · medium · source → · wiki →

key claims

The strongest theoretical rule is to allocate scarce capacity to the current bottleneck rather than to preserve a fixed build-versus-improve ratio, because Theory of Constraints predicts that improving non-constraints yields little system-wide throughput gain while relieving the binding constraint changes total outputTheory (n.d.)Mitchell (2026)
Little's Law implies that when feature demand pushes more work into a delivery system than the system can complete, Work in Progress rises and lead time lengthens, so apparent short-term busyness can reduce throughput and predictability rather than increase themLittle (1961)DevOps (n.d.)
Technical debt converts some short-term feature speed into later drag, because shortcuts taken under time or resource pressure create harder maintenance, reduced velocity, and unexpected rework that consume future engineering capacityAvgeriou et al. (2024)Deloitte (2026)
The DORA delivery evidence used in this item does not support a permanent tradeoff between speed and quality, because the cited DORA sources say top-performing teams achieve both higher throughput and lower instability when they improve testing, deployment, and feedback systemsDevOps (n.d.)Google (2024)
Once repetitive operational work becomes a large enough share of team attention, improvement work should displace marginal feature work, because Site Reliability Engineering guidance treats toil reduction and automation as return-on-investment decisions required to protect engineering capacityGoogle (n.d.)
Pareto-style concentration means improvement investment should be targeted at hot spots rather than spread uniformly, because a minority of modules or workflows often drive most defect risk or delivery friction and therefore offer the highest leverage for capacity recoveryAmerican (n.d.)Ball (2005)
Platform engineering is a valid form of throughput-improvement investment when it builds high-quality self-service golden paths for common workflows, but the evidence also says it should be introduced incrementally because the payback can follow a J-curve rather than an immediate straight lineDevOps (n.d.)Science (2026)
The most practical allocation policy is trigger-based: keep feature delivery primary while lead time, failure, recovery, toil share, and hotspot concentration stay within agreed bands, then shift capacity toward improvement when those indicators worsen persistentlyDevOps (n.d.)Google (n.d.)Ball (2005)

Research Question

Given constrained engineering capacity, how should organisations allocate effort between (1) building features within an existing system and (2) improving the system itself (tooling, process, architecture, and quality controls) to maximise long-run throughput and delivery quality? Which theoretical models from software engineering, operations science, economics, and adjacent disciplines best explain this tradeoff, and how does a Pareto distribution framing (for defects, bottlenecks, or value concentration) change recommended allocation strategies?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

Organisations should allocate build-versus-improve effort by following the current bottleneck, not by holding a fixed percentage split, because Theory of Constraints and Little's Law both imply that overloaded systems convert extra feature intake into more queue length and longer lead time before they convert it into shipped value.

System-improvement work becomes throughput work once debt, toil, rework, or unstable deployment pipelines are the binding constraint, because those frictions tax every subsequent feature and reduce the amount of delivered value per unit of engineering effort.

DORA and platform-engineering evidence shift the question away from a simple speed-versus-quality framing and toward delivery-system design, because the cited sources say organisations improve long-run outcomes by making software delivery faster and more stable through targeted system improvements.

Pareto-style concentration changes the recommendation from generic improvement time to hotspot-focused intervention, because a minority of modules, workflows, or queues usually dominate defect risk, review load, or delivery delay.

Key Findings

The strongest theoretical rule is to allocate scarce capacity to the current bottleneck rather than to preserve a fixed build-versus-improve ratio, because Theory of Constraints predicts that improving non-constraints yields little system-wide throughput gain while relieving the binding constraint changes total output.
Little's Law implies that when feature demand pushes more work into a delivery system than the system can complete, Work in Progress rises and lead time lengthens, so apparent short-term busyness can reduce throughput and predictability rather than increase them.
Technical debt converts some short-term feature speed into later drag, because shortcuts taken under time or resource pressure create harder maintenance, reduced velocity, and unexpected rework that consume future engineering capacity.
The DORA delivery evidence used in this item does not support a permanent tradeoff between speed and quality, because the cited DORA sources say top-performing teams achieve both higher throughput and lower instability when they improve testing, deployment, and feedback systems.
Once repetitive operational work becomes a large enough share of team attention, improvement work should displace marginal feature work, because Site Reliability Engineering guidance treats toil reduction and automation as return-on-investment decisions required to protect engineering capacity.
Pareto-style concentration means improvement investment should be targeted at hot spots rather than spread uniformly, because a minority of modules or workflows often drive most defect risk or delivery friction and therefore offer the highest leverage for capacity recovery.
Platform engineering is a valid form of throughput-improvement investment when it builds high-quality self-service golden paths for common workflows, but the evidence also says it should be introduced incrementally because the payback can follow a J-curve rather than an immediate straight line.
The most practical allocation policy is trigger-based: keep feature delivery primary while lead time, failure, recovery, toil share, and hotspot concentration stay within agreed bands, then shift capacity toward improvement when those indicators worsen persistently.

Assumptions

The organisation can measure at least basic flow and instability indicators, because the synthesis depends on observable triggers rather than on a purely narrative notion of "the system feels slow."
Demand for additional feature work is real enough that pausing it has an opportunity cost, because otherwise the build-versus-improve choice collapses into a pure maintenance problem.

Analysis

This item relies more heavily on mechanism and indicator sources than on exact percentage studies, so the synthesis weights causal models and operating indicators above any fixed ratio heuristic.

The decisive combination is Little's Law plus Theory of Constraints: one explains why overloaded systems get slower as queues grow, and the other explains why only the bottleneck matters for throughput improvement.

Technical debt and toil matter because they turn invisible system frictions into recurring taxes on every later change, which means improvement work can have higher marginal value than the next feature once those taxes become the dominant constraint.

The strongest rival remedy is to preserve feature delivery and solve delay by adding people or by mandating more output, but the flow literature does not support that when the real constraint is queueing, defect hot spots, or unstable operating paths rather than headcount alone.

Risks, Gaps, and Uncertainties

Flow models explain direction and mechanism well, but they do not yield a universally valid percentage split between feature work and system improvement.
Platform-engineering evidence is useful and increasingly structured, but academic causal evidence on exact payback remains thinner than practitioner guidance.
Technical debt cost magnitudes are partly survey-based and model-based, so precise burden estimates are less robust than the general claim that debt creates rework and slower future delivery.
Organisations with poor measurement may still know they are overloaded, but the trigger-based policy becomes noisier when toil, lead time, and recovery data are not instrumented well.

Open Questions

Which numeric trigger bands, for example toil share or recovery-time thresholds, are most predictive of when improvement work should temporarily dominate feature work in different operating environments?
What is the strongest before-and-after evidence for platform engineering payback outside vendor or survey claims, especially in legacy-heavy enterprises?
Which hotspot indicators, churn, incidents, rework, or review delay, are most reliable for selecting the vital few improvement targets in different codebases?