The liability is real, the measurement is possible, and the governance is yours to own.
Have a question about this? Bring it to Aurelius.
30% of CIOs report that more than one-fifth of their new-product technology budget is silently consumed by technical debt — and most of the executives above them have no idea it is happening.
That number comes from McKinsey's research across more than 50 CIOs, and it points to something worth sitting with before you move on: if your engineering organisation is spending $10 million on new capability this year, up to $2 million of that may already be gone — not to innovation, not to competitive advantage, but to the quiet maintenance of decisions made years ago under pressure. The cost does not appear as a line item. It appears as slowness, as attrition, as missed quarters, and as the persistent sense that your technology organisation is running hard to stay still.
You are not imagining it. The problem is real, and it is yours to govern — not your CTO's alone.
The standard response to this problem is to hand it back to the engineers. Let the technical people manage technical things. A steering committee is formed, a debt register is created, a percentage of each sprint is nominally reserved for remediation work, and the executive team declares the matter handled.
This is the governance equivalent of installing a smoke detector and considering fire prevention complete.
The deeper error in conventional advice is categorical: it treats technical debt as a technical problem when it is, at its root, a prioritisation problem — which means it is a leadership problem. Every significant piece of technical debt in your organisation was created by a decision to ship faster, to cut a corner, to defer a cost. Many of those decisions were correct at the time. But they were made under pressure that came from the top of the organisation. The executive team set the conditions; the engineers executed within them. Handing remediation back to the engineers without changing the conditions that created the debt is not governance. It is delegation of consequence without delegation of authority.
The second error is the assumption that invisibility means immeasurability. Because technical debt does not appear on the P&L, leaders conclude it cannot be quantified. It can. It simply requires asking different questions than the ones finance is currently asking.
Marcus Aurelius wrote in Meditations (Book IV): "If it is not right, do not do it; if it is not true, do not say it." The discipline he is pointing toward is not merely ethical — it is cognitive. It is the practice of refusing to accept comfortable fictions in place of difficult truths.
The comfortable fiction available to every non-technical executive facing this question is: I cannot see it, therefore I cannot govern it. This fiction is attractive because it relieves the leader of responsibility without requiring them to admit they are declining it. But Stoic philosophy — particularly as Epictetus frames it in the Discourses — is clear on the distinction between what is within our control and what we have simply chosen not to examine. Epictetus does not permit us to confuse the two.
This reveals something important about how technical debt accumulates at the executive level: it is not a failure of engineering — it is a failure of attention. The Stoics held that we are responsible for our judgements, our assents, our choices about where to direct rational inquiry. When a non-technical executive decides that technical health is outside their domain of governance, they are making an active choice — not a passive one — to leave a significant portion of organisational capital unexamined.
This means the question is not how do I understand code? The question is what indicators, translated into language I already govern, will reveal the health of the system beneath my strategy? That is a question any executive can answer, because it is the same question they ask about customer satisfaction, talent retention, and supply chain resilience. The translation work is not trivial, but it is the work. And it belongs to leadership.
McKinsey's research on 220 companies found that organisations in the 80th percentile for technical debt management achieve 20% higher revenue growth than bottom performers. That is not a software engineering statistic. That is a strategy statistic. When framed correctly, technical debt governance is not an IT concern — it is a growth lever that most executive teams have never consciously pulled.
Govern technical debt the way you govern any other invisible liability: through proxy indicators, structured dialogue, and accountability at the right level.
1. Establish a technical health index with a quarterly executive review cadence.
Work with your CTO to define three to five leading indicators translated into business language: deployment frequency (how often can the team safely release?), change failure rate (what percentage of releases cause incidents?), mean time to recovery (when something breaks, how long does the organisation bleed?), and the ratio of new feature work to remediation work in each sprint. These are not code metrics. They are organisational health metrics.
2. Put a cost estimate against the debt register.
Ask your engineering leadership to quantify the debt backlog in engineering hours, then convert those hours to fully-loaded cost. A debt register with no dollar figure attached is a list. A debt register with $4.2 million against it is a liability that belongs in a leadership conversation.
3. Protect remediation budget the way you protect depreciation.
McKinsey's data shows that paying down technical debt can free engineers to spend up to 50% more of their time on value-generating work. Model that as a return on investment. If 15% of your engineering budget allocated to remediation this year frees 50% more capacity next year, that is not a cost — it is a capital allocation decision with a calculable return.
4. Change the conditions, not just the metrics.
If your organisation rewards speed-to-ship above all else and punishes engineers for raising technical concerns, the debt register is decorative. Executive governance of technical debt requires that leaders visibly reward honesty about technical cost — including in performance conversations and roadmap negotiations.
The course Turn Your Engineering Budget Into a Headcount and Roadmap Decision Tool offers a structured framework for making exactly this kind of translation between engineering capacity and financial planning.
Before you close this tab, send one message to your CTO or VP of Engineering with a single, precise request: "I would like us to establish a monthly technical health briefing — no longer than 20 minutes — that translates our current technical debt position into business terms I can act on. I am asking you to own the format; I am committing to attend and to treat it as a first-class agenda item. Can we schedule the first one within the next three weeks?"
That message does four things simultaneously: it signals that executive attention has shifted, it gives your engineering leader authority and accountability in the same sentence, it sets a time constraint that prevents indefinite deferral, and it models the Stoic discipline of choosing to examine what you have been comfortable leaving unexamined. The governance does not begin when you understand the code. It begins when you decide to stop accepting the comfortable fiction that you cannot.
If the underlying issue is that your engineering team is building faster than the system can safely absorb, Ship Features Faster Without Burning Out Your Engineering Team addresses the organisational and process conditions that allow debt to accumulate unnoticed.
For leaders who want to understand how feasibility assessment can prevent new debt from forming before a project begins, the AI Feasibility Assessment for Engineering Projects concept piece offers a concrete starting point — including how to reduce failed projects by 60% through structured evaluation before commitment.
And if your current sprint cadence is obscuring the true cost of technical work from stakeholders who need to see it, Stop Running Sprint Reviews That Waste Every Engineer's Friday Afternoon reframes the review as a governance instrument, not a ceremony.
Go deeper with Aurelius
Apply this to your actual situation. Aurelius will meet you where you are.
Start a session