Marginal Cost Trend — Is delivery getting cheaper or more expensive?
Marginal cost trend is the primary signal of whether the system is compounding or fragmenting.
Most technology organizations know what they spend on engineering. Very few know whether that spend is producing more or less capability over time. The difference is not how much they spend. It is whether each new capability becomes cheaper or more expensive to deliver.
Marginal cost trend is the signal that answers that question directly.
What this signal measures
Marginal cost trend measures the change over time in the engineering effort required to deliver an equivalent unit of new capability.
It is not a measure of total cost. It is a measure of cost direction — whether the organization is getting more or less efficient at building new things on top of what already exists.
In a healthy system, marginal cost declines over time. Shared platforms reduce the effort required to build new capabilities. Consistent data models eliminate the integration work that would otherwise be required every time a new system touches existing data. Reusable components mean that new capabilities extend what exists rather than rebuild it. The system gets easier to build in as it matures.
In a degrading system, marginal cost rises. Each new capability requires more integration work than the last. Technical debt consumes an increasing share of engineering capacity. Teams spend more time understanding existing systems before they can change them. The system becomes harder to build in as it grows — and the organization spends more to produce less.
Measuring it in practice: the most reliable approach is to establish a baseline set of reference capabilities — three to five representative initiatives from a known period — and compare subsequent initiatives against that baseline by complexity tier. Story point velocity normalized for team size, cycle time by feature complexity tier over rolling four-quarter windows, or direct effort tracking per delivered capability can all produce usable signals. The method matters less than the consistency. A rough measurement tracked over six quarters is more useful than a precise one taken once. The signal is in the direction of change, not the absolute number.
How to read it correctly
Marginal cost trend is easy to misread because it is rarely measured directly. Most organizations approximate it through proxy metrics — velocity, cycle time, deployment frequency — that capture activity without capturing cost direction.
The first misreading is confusing velocity with marginal cost. A team that is shipping at high velocity may still be experiencing rising marginal costs if each sprint is consuming more effort to produce the same output as six months ago. Velocity measures throughput. Marginal cost measures what that throughput actually costs to sustain.
The second misreading is attributing rising marginal costs to team performance. When delivery slows or costs rise, the instinctive response is to look at what the team is doing. The structural response is to look at what the system is making the team do. Rising marginal cost is almost never a team performance problem. It is a system design problem — and fixing it by adding engineers, improving processes, or increasing pressure will not address the cause.
The third misreading is treating short-term variance as a trend. A single quarter of rising marginal cost may reflect a genuinely complex initiative, a planned architectural investment, or a temporary capacity constraint. A trend of rising marginal cost across three or more consecutive quarters is a structural signal — and it requires a structural response, not a delivery intervention.
The correct way to read marginal cost trend is over a rolling four-to-six quarter window, normalized for initiative complexity. When that window shows a consistent direction — costs rising or falling, independent of what is being built — the signal is reliable. When it fluctuates quarter to quarter without a consistent direction, the data collection methodology needs to be examined before the signal can be trusted.
What it reveals when it moves
Rising marginal cost reveals that the system is consuming more of its own resources to maintain itself — leaving less capacity available for new capability, and making each new capability more expensive than the one before it.
The specific cause depends on where in the system the cost is accumulating. If integration effort is rising, the architectural foundation is fragmenting — new capabilities are not building on shared platforms but connecting to them through custom integrations that compound with each addition. If maintenance effort is rising, technical debt has crossed the threshold where it is no longer being serviced faster than it accumulates. If onboarding effort is rising — the time it takes for engineers to become productive on a new area of the system — the system has become too complex to navigate without significant ramp-up time.
Each of these causes points to a different structural response. That specificity matters. Marginal cost is a composite signal — it locates the problem at the system level without identifying where in the system it originates. The CTO who responds to rising marginal cost without diagnosing the cause will apply the wrong intervention.
Falling marginal cost reveals that the system is compounding. Platform investments are reducing integration effort. Shared components are being reused rather than rebuilt. Technical debt is being serviced faster than it accumulates. The system is becoming easier to build in — and each new capability is incrementally cheaper than the one before it.
Falling marginal cost is the signal that foundational investment is working. It is also the signal most likely to be overlooked — because the benefits of falling marginal cost are distributed across the organization and invisible in any individual initiative.
What to do when it moves in the wrong direction
When marginal cost is rising consistently, the response must be structural, not operational.
First, diagnose the cause before responding. Rising marginal cost is a composite signal. The response to rising integration effort is different from the response to rising maintenance effort. Before committing to a structural intervention, the CTO needs to identify where in the system the cost is accumulating — through the friction signals from the weekly cadence, the architectural stress assessments from the monthly review, and the technical debt schedule from the quarterly capital session.
Second, translate the signal into capital terms before the next quarterly session. Rising marginal cost is an economic argument for foundational investment — but it needs to be made specifically. The CTO should arrive at Session 2 of the quarterly cadence with a calculation: if the marginal cost trend continues at its current rate for four more quarters, what is the total additional cost to the organization in engineering capacity that could otherwise be applied to new capability? That number, presented alongside the investment required to reverse the trend, changes the conversation from a technical concern to a capital decision.
Third, protect the response from delivery pressure. The interventions that reverse rising marginal cost — platform consolidation, technical debt remediation, architectural refactoring — are exactly the investments most likely to be deferred when delivery pressure arrives. The CTO who has translated the signal into capital terms and documented the cost of deferral is better positioned to protect the intervention than one who is arguing from architectural principle alone.
When marginal cost trend is falling, the structural response is to make the cause visible and protect the investment that is producing it. Falling marginal cost is the result of specific investments — in platform coherence, in data model consistency, in shared component reuse. Those investments must be identified, named, and protected — or the gains will be absorbed and lost.
Five Circles reference: Circles II & IV — Architectural Foundation and Capital & Execution Engine