Technical Debt Ratio — Where is hidden cost building?
Technical debt ratio is the signal that makes the invisible cost of accumulated decisions visible in engineering capacity.
Every technology system carries technical debt. Code that was written under time pressure and never refactored. Architectural decisions that were correct at the time and have since been overtaken by scale. Integrations that were built as temporary workarounds and became permanent. Dependencies that were introduced without full understanding of their long-term implications.
None of these are failures of execution. They are the natural accumulation of a system that has been built iteratively, under real constraints, by teams making the best decisions available to them at the time. The question is never whether technical debt exists. It is whether it is being managed or accumulating — and whether the organization can tell the difference.
Technical debt ratio is the signal that answers that question.
What this signal measures
Technical debt ratio measures the proportion of engineering capacity consumed by maintaining, servicing, and working around existing systems — rather than building new capability.
In practical terms: of every ten engineers in the system, how many are building new capability — and how many are managing the consequences of previous decisions?
That ratio is the technical debt ratio. And its direction of travel — whether the maintenance proportion is growing or shrinking relative to the capability-building proportion — is one of the most reliable indicators of whether the system is healthy or degrading.
A stable or declining maintenance ratio means the organization is servicing its debt faster than it is accumulating it. New systems are being built with sufficient quality that they do not generate disproportionate maintenance overhead. Existing debt is being addressed as a discipline rather than deferred as a default.
A rising maintenance ratio means the organization is accumulating debt faster than it is servicing it. Engineering capacity is being progressively consumed by the cost of past decisions — leaving less capacity available for new capability, and making the system more expensive to operate with each passing quarter.
How to read it correctly
Technical debt ratio is one of the most politically sensitive signals in the technology organization — because it directly implicates past decisions, and because the teams responsible for those decisions are often still present.
The first misreading is treating all maintenance work as debt. Some proportion of engineering capacity will always be consumed by system operations, incident response, and ongoing reliability work. This is not debt — it is the normal cost of running a production system. Technical debt ratio measures the maintenance overhead that is a consequence of past architectural decisions, not the baseline operational effort that any system of comparable scale would require.
The distinction matters because conflating the two produces an inflated debt ratio that overstates the structural problem, and because addressing the wrong maintenance overhead with architectural investment will not produce the expected improvement. The CTO needs to understand what proportion of the maintenance effort is structural — driven by architectural decisions that could be addressed — and what proportion is operational — driven by the inherent complexity of running the system at its current scale.
The second misreading is treating a high absolute ratio as the primary concern. What matters is not the absolute level of the maintenance ratio but its direction. An organization with a 35% maintenance ratio that is declining has a different structural outlook than one with a 25% ratio that is rising. The first is paying down debt faster than it is accumulating. The second is accumulating it faster than it is paying it down — and the trend will continue until the ratio reaches a level where the system can no longer sustain the delivery performance the business depends on.
The third misreading is using technical debt ratio as a proxy for code quality. Technical debt is an architectural problem — the accumulation of structural decisions that made sense locally and were never resolved globally. Code quality improvements address symptoms. Architectural investment addresses causes.
What it reveals when it moves
A rising technical debt ratio reveals that the system is consuming itself. Engineering capacity that was once available for new capability is being progressively redirected to maintaining what already exists. The delivery performance that the business depends on is being sustained by drawing down a structural reserve — and that reserve has a limit.
The specific dynamics of a rising ratio depend on where the debt is concentrated. Debt concentrated in legacy systems produces a maintenance burden that is predictable and can be addressed through planned migration. Debt concentrated in recently built systems is more concerning — it suggests that the architectural discipline that should be governing new development is not operating effectively, and that the problem is not historical but ongoing.
A rising ratio that is concentrated in recently built systems is not a legacy problem. It is a governance problem — and it requires a governance response, not a migration plan.
A stable technical debt ratio is not evidence of health. It is evidence of equilibrium — and equilibrium is fragile. Any increase in delivery pressure, any reduction in the capacity allocated to debt servicing, or any significant architectural decision that introduces new debt will tip the ratio upward — and once it begins rising, the compounding dynamic is difficult to reverse without a significant structural intervention.
A declining technical debt ratio is the signal that the system is being actively improved. The architectural investment is producing returns that are visible in engineering capacity — more of it available for new capability, less consumed by maintaining what already exists. It is also the signal most likely to be deprioritized when delivery pressure arrives, because the benefits of declining debt ratio accrue gradually and the costs of interrupting the improvement program are invisible until the ratio begins rising again.
What to do when it moves in the wrong direction
When technical debt ratio is rising, the response must address both the accumulation and the cause of accumulation — not just the symptom.
The accumulation is addressed through the technical debt schedule — the explicit commitment, made in Session 2 of the quarterly cadence, to allocate a specific proportion of engineering capacity to debt remediation. That schedule is not a wish list. It is a capital commitment, with named owners and defined timelines, that is tracked through the monthly cadence and reported against in the quarterly review.
The cause of accumulation is addressed through architectural governance. If debt is rising because new systems are being built without sufficient architectural discipline — without platform reuse, without consistent data models, without documented interfaces — the solution is not to remediate the debt faster. It is to change the conditions under which new systems are being built. Debt remediation without architectural governance improvement is a treadmill. The system keeps running to stay in place.
When translating the signal into capital terms, the CTO needs to present two numbers. The first is the current maintenance ratio and its rate of change. The second is the projection of what the delivery capacity of the organization will look like in four quarters if the ratio continues to rise at its current rate. That projection — fewer engineers available for new capability, longer delivery timelines, higher cost per new feature — is the economic argument for protecting the debt remediation allocation in the quarterly capital session.
When technical debt ratio is declining, the structural response is the same as for other improving signals: make the cause visible, protect the investment that is producing it, and resist the pressure to redirect the debt remediation capacity toward delivery when the short-term pressure is highest. The temptation to redeploy engineers from debt remediation to feature delivery is strongest exactly when the delivery pressure is highest — and that is precisely the moment when protecting it matters most, and when it is most likely to be lost.
Five Circles reference: Circles II & IV — Architectural Foundation and Capital & Execution Engine