A feature request arrives. It sounds simple. Similar work took two days last year. The estimate comes back at two weeks, with caveats. The explanation is technically correct: that part of the system is fragile, there's a workaround from an earlier release that touches the same area, changing it without breaking something else isn't straightforward. This is all factually correct, but it doesn't tell you what you actually need to know: whether this is the natural complexity of a genuinely difficult problem, or the consequence of a series of shortcuts nobody ever went back to fix.
That gap between the explanation you receive and the answers you really need is where Technical Debt lives.
Technical Debt is the accumulated cost of shortcuts, workarounds, and deferred improvements in code and systems. Every shortcut was a decision: someone chose to ship quickly under real pressure and accepted that the next change in that part of the system would take longer and carry more risk. That isn't a failure of engineering judgement; it's a trade-off, usually the right one at the time, that was never tracked, never named as a decision, and never revisited. The debt continues to sit in the codebase, accruing interest.
Technical Debt is the concept Mantage's Organisational Debt framework takes its name from. It comes from software engineering, where it's been understood for decades. It hasn't been visible to the leaders who are ultimately paying for it.
Unlike Operational Debt, which becomes visible the moment a key person resigns, Technical Debt stays hidden while the system keeps working; features ship and the product continues to function. The debt doesn't become noticeable through a failure; it's through a slower pace and increased risk. Things take longer than they used to; changes that should be routine feel like they require careful management. The difference between that and a team that's under-resourced, or a project that was always going to be complex, isn't obvious from the outside.
That ambiguity is addressable. Technical Debt is a business decision, not a coding problem, and it can be managed by people who have never written a line of code, once it stops being treated as engineering's internal responsibility.
Recognising Technical Debt in Your Business
Technical Debt has recognisable markers, and none of them require reading code. They show up in delivery patterns, in the language engineers use, and in how estimates behave over time.
In delivery, the signal is drift. The same category of feature takes longer than it did twelve months ago, with explanations that are hard to pin to any single cause. Bugs recur in the same parts of the product rather than being resolved once and properly. Deploying changes, something that should be a routine operational step, gets treated with a caution that suggests the team can't be confident what else a deployment might touch.
In language, the signal is permanence. Phrases like "fragile," "a workaround we never went back to," or "it just sort of grew that way" describe parts of the system as a fixed state of affairs rather than a known, temporary condition. "We can't touch that without breaking something else" gets offered as a complete explanation, with nothing further available to interrogate. Estimates start carrying a buffer that goes unquestioned, because everyone has learned the buffer tends to be needed.
In decision-making, the signal is invisibility. Shortcuts happen under deadline pressure and nobody names them as decisions with a future cost. There's no register, however lightweight, of what's been deferred and why. "We'll fix it properly later" is said often and followed up rarely, because nothing creates the obligation to return.
Four questions highlight technical debt, and none of them require technical knowledge to ask:
"What would you most want to rebuild, if you had the time?" is the most direct, and the most revealing. Specific, confident answers naming particular systems or components are a good sign: they mean the debt is known and therefore trackable. Vague reassurance that everything is fine is the worse outcome, because debt that isn't being monitored is harder to resolve than debt that's large.
"Which parts of our system make the team nervous when we need to change them quickly?" names the risk dimension rather than the quality one, and tends to elicit different answers.
"How has our estimate accuracy changed over the last year, and are the same kinds of features taking longer than they used to?" externalises the cost in terms leadership can understand.
"When did we last knowingly ship a shortcut under pressure, and did we ever go back for it?" tests whether the decision-making around debt is conscious or invisible.
None of these require technical fluency. They require asking at all, and taking the answers seriously enough to act on.
The Cost Curve of Technical Debt
Technical Debt shows up as a slow tax on everything the business tries to do next: smaller than it looks in any individual week, larger than most leaders realise when they add it up.
The first-order costs are in delivery. Every new feature has to work around the accumulated shortcuts already in the system, so the same category of work takes longer than it did a year ago. Changes that should be routine carry a risk, because nobody can be fully confident what else a given change might affect. Estimates inflate because the system has become harder to reason about with precision.
The second-order costs are where Technical Debt starts to compound with other debt types. Strong engineers dislike working inside a codebase that fights them, and they have options. When they leave, they take with them the institutional knowledge of why a particular shortcut exists and how to work around it safely. This is exactly the mechanism Capability Debt4 describes: the people who understood the debt are exactly the people most likely to leave if the system never gets easier to work with, and their departure removes the knowledge that made the debt manageable at all. The two debts compound each other directly.
A codebase that can't be changed quickly also constrains what the business can commit to next. New integrations, new markets, new capability: all of them become slower to execute when the underlying systems can't be changed with confidence. A business that can't move quickly inside its own systems can't move quickly on new opportunities, whatever its strategy says it intends to do. Technical Debt becomes the distance between what the roadmap promises and what the systems can actually support.
There's a subtler second-order cost too. Every time "it'll take longer than expected" happens without a clear explanation attached, the non-technical side of the leadership team trusts the technical estimate a little less. That scepticism is rational, given what they've experienced. It also makes the eventual conversation about properly resourcing debt pay-down harder: the case for investing in invisible work now has to compete with accumulated doubt about whether the investment will produce what it's said it will.
At the third-order level, the cost becomes structural. Mantage has witnessed a "drop everything and re-platform" situation happen because so many "we'll do that when we have more time" discussions created a perfect storm of un-patchable libraries and end-of-life OS versions that had to be dealt with within a month. The pattern across businesses is consistent: a codebase carrying enough accumulated debt reaches a point where incremental fixes stop being sufficient, and the business faces a full rebuild or re-platform decision. That decision is expensive and risky under any conditions. It becomes considerably more expensive when it's forced by an external trigger (a new enterprise client whose scale the current architecture can't support, a security or compliance requirement the system can't meet) rather than chosen on the business's own timeline. The businesses that handle a re-platform well are the ones that saw it coming and started the conversation before the trigger arrived.
Technical Debt and Regulatory Debt can also arrive at the same crisis from different directions. A codebase carrying significant accumulated debt may not be able to meet a compliance or security requirement without substantial rework. The two debts don't need to have been accumulated together to become a combined problem under pressure.
The cost structure here is consistent with every other debt type in the framework: the cost is deferred, not avoided, and it gets more expensive the longer the deferral runs. What makes Technical Debt distinctive is how long a system can keep technically functioning while becoming a constraint on everything the business wants to do next.
Reducing Technical Debt: Where to Start
Addressing Technical Debt requires leaders to treat debt decisions as visible, resourced, owned choices rather than defaults that engineering absorbs without visibility from above.
Making the Trade-off Visible and Owned
When a deadline forces a shortcut, naming it in the moment as a decision with a cost attached changes the conversation. "We are choosing to ship this quickly and accepting that the next change in this area will take longer" is different from silence. It doesn't slow the decision down. It creates the memory of what was decided and why, which is what makes it possible to revisit later.
A lightweight, leadership-visible register of deferred work supports this. Not a technical backlog that only engineers read, but a short, current list that captures what's been deferred, why, and what it's expected to cost the business over time. The format matters less than the habit of maintaining it. A trade-off nobody named isn't a trade-off; it's an unmanaged future cost.
Asking About System Health on a Rhythm
"What would you most want to rebuild?" earns its place as a standing diagnostic question asked quarterly, not a one-off exercise conducted once and then filed. Tracking whether the answer changes over time matters as much as the answer itself. The same response, quarter after quarter, with no progress against it, is a signal worth escalating: the debt is being acknowledged but not addressed, which is barely different from it going unnoticed.
Budgeting for Pay-down as a Resourced Line
A protected proportion of engineering capacity for debt reduction, agreed at leadership level, is what turns debt reduction into a practice. Not "whenever there's spare time," which in practice means never, because spare capacity in an engineering team doesn't stay spare for long. That allocation needs to be defended when deadline pressure arrives, the same way any other committed resource would be defended. The moment it becomes the first thing cut when priorities shift, it stops functioning as a real commitment. "We'll get to it" without a protected allocation is how businesses end up carrying more debt than they intended to.
Escalating "We Can't Touch That" Before It Becomes a Constraint
"We can't change that without breaking something else" is where this section started. The question it should prompt is not whether the claim is accurate (it usually is) but what it will cost the business if that system needs to change on short notice in six months, or twelve, or when an external trigger removes the option of timing. Assessing that deliberately, on the business's own timeline, is how a re-platform decision gets made as a choice rather than discovered as a crisis. The businesses that handle forced rearchitecting badly are almost always the ones for whom "we can't touch that" was the end of the conversation for several years running.
The Realities of Addressing Technical Debt
Technical Debt is addressable, and addressing it is worthwhile. Being clear about what it involves before starting is more useful than discovering the trade-offs partway through.
Not all Technical Debt is a problem, and zero debt isn't the goal. Every business that's moved fast under real pressure has taken shortcuts, and some of those shortcuts were the right call. What matters is understanding the proportion of debt that's known, tracked, and chosen versus debt that's accumulated by default because nobody was watching.
Paying Technical Debt down produces nothing visible to show for it. A quarter spent on debt reduction looks, from outside engineering, like a quarter with no new features. That's a real cost, and it has to be defended deliberately against the constant pull toward funding whatever is visible. The asymmetry is the same one the series has flagged before: the cost of not doing the invisible work is real, it's just deferred and harder to attribute. Invisible work that doesn't get funded shows up later as the slow tax described in the previous section.
Leaders can't fully verify technical claims, and trying to become engineers in order to manage this isn't the answer. "It's too complicated to change" can be an accurate account of a fragile system, or it can function as a shield against scrutiny. Both happen. The fix isn't technical literacy; it's building enough of a working relationship between technical and non-technical leadership, and asking the right questions on a consistent enough rhythm, that claims can be tested through pattern and consistency rather than direct verification. A team that gives specific, confident answers and whose estimates track reasonably against outcomes over time earns a different level of trust than one that answers with vague reassurance. That trust develops through the habits in the previous section, not through a crash course in software architecture.
Technical Debt paid down without changing why it accumulated will just rebuild. A freshly improved codebase operating under the same pressures (unrealistic deadlines, chronic understaffing, a culture of treating every deadline as non-negotiable) is next year's legacy system. Addressing the debt once is a project; keeping it manageable is a discipline that lives in the decision-making habits of the leadership team, not in an engineering sprint.
None of these realities are a reason to leave Technical Debt as engineering's private problem. They're a reason to fund the work deliberately, ask about it on a schedule, and accept that some of it is the reasonable cost of having moved fast when moving fast mattered.
Technical Debt in the Wider Organisation
Technical Debt rarely sits in isolation. Understanding where it compounds with the other debt types is what makes it possible to manage at a business level rather than as an engineering concern.
The most direct relationship is with Capability Debt. The engineers who understand a fragile system's history, who know why a particular shortcut exists and how to work around it safely, are exactly the people most likely to leave if the codebase never gets easier to work in. Their departure removes the institutional knowledge that made the debt manageable. Managing Technical Debt and managing Capability Debt are, in this respect, the same problem approached from different directions.
Technical Debt also sits adjacent to Operational Debt3. Operational Debt covers business processes and tooling: workflows built around temporary tools that became permanent, siloed systems that don't communicate, governance gaps with no clear owner. Technical Debt is specifically about the engineering and product codebase. A business can carry a significant amount of one with very little of the other. The distinction matters because the interventions are different: fixing process debt and fixing code debt require different resources, different conversations, and different ownership.
Technical Debt also narrows what Strategy Debt5 is working against. A business can state a clear priority and find its options constrained by what its own systems can support at speed. Technical Debt is often the reason an ambitious strategic commitment takes longer to execute than the plan assumed, because the systems that would need to move quickly can't. That relationship tends to surface during delivery rather than during planning, which is precisely why Technical Debt needs to be a visible input to strategic conversations rather than a detail engineering handles internally.
Mantage's operations review maps technical risk in terms a non-technical leadership team can act on, rather than leaving it as an internal engineering assessment that nobody outside the team is equipped to interrogate. The strategy delivery practice treats technical constraints as a real input to what's achievable on a given timeline, not a variable to discover midway through executing a plan. The mentoring practice supports the harder dimension of all of this: building the working relationship between technical and non-technical leadership that makes it possible for both sides to raise concerns and receive straight answers, in both directions.
This is the sixth piece in the Organisational Debt series, following the primer1 and the articles on Cultural Debt2, Operational Debt, Capability Debt, and Strategy Debt. Data Debt, Innovation Debt, and Regulatory Debt are ahead, all three already scheduled for the near future.
Technical Debt is the debt the whole framework is named after, and the easiest for a non-technical leader to file away as someone else's specialism. Every shortcut a business is carrying right now was a decision, made under real pressure, by someone who didn't call it a decision at the time. Naming it as one is where managing it starts.
Referenced Articles