The Invisible Mortgage: Technical Debt is Quietly Killing Your Ambition
Every business carries a debt that never appears on the balance sheet.
It is not in the accounts, no auditor signs it off, and no board pack has a line for it. It is, however, both real and significant and you are already paying for it. It's lurking in the shadows, showing up in a lack of pace and agility, the projects that cost more than they should, and in a growing list of things everyone quietly agrees are "too risky to touch."
It is technical debt, and for many organisations it is the single biggest liability nobody is managing. If that catches your attention, well it's about to get a hell of a lot worse... a new wave of that debt is about to be take hold in your organisation faster than at any point in history, and much of it will be signed off without anyone realising they are signing anything at all.
Where Technical Debt comes from
Technical debt is the accumulated cost of every shortcut, compromise and ageing system in your business:
The integration that was rushed to hit a deadline
The platform three versions out of date because upgrading is "too disruptive"
The spreadsheet that quietly became business critical
The system only one person understands, and they are retiring in the spring
The ERP platform customised to the hilt because your organisation is a 'special case'
It would be lazy to say these were foolish decisions, in fact most were sensible trade-offs made under real pressure. That is exactly why it is called debt rather than a mistake. You borrowed speed then, and you are paying interest now, which compounds each and every year. The problem is that, unlike a real loan, your teams didn't write down the terms and asked you to sign on the dotted line.
Why nobody sees it
The reason technical debt is so dangerous is that it's invisible in all the places leaders look. It doesn't appear in the management accounts or show up as a tangible number in a board pack. It stays comfortably out of sight, right up until it bites, and when it does, you might not even realise whats going on.
It's often the root cause for other issues that may be occurring, with different explanations because those doing the reporting haven't managed to get close enough to know whats actually occuring. It shows up as:
The transformation that somehow costs three times the estimate (and/or took three times as long!)
The outage nobody can fully explain, and they begin to reoccur at an increasing rate
The competitor who ships in hours or days what takes you twice as long
Disjointed and fragmented systems and processes, holding back important productivity gains
Leaders often see the symptom and treat it as a one-off, a bad project, an unlucky failure, a team that underdelivered. They rarely see the common cause sitting underneath, because the mortgage servicing itself never appears on any statement they are shown.
The scale of it, once someone actually measures it, tends to stop a room.
In a global survey of over a thousand technology leaders, Protiviti found organisations spending an average of 30% of their entire IT budget, and one fifth of their people's time, just managing technical debt.
McKinsey's research puts the underlying liability at 20-40% of the value of the whole technology estate, with 10-20% of the budget meant for new products quietly diverted to fixing old ones instead. The majority of CIOs surveyed said the debt had grown, not shrunk, over the previous three years.
DXC's survey of 750 IT executives found that 99% of them said technical debt now shows up directly or indirectly on their organisation's risk register.
This is not a niche problem carried by a few unlucky businesses. It is the default condition, and most boards are managing a third of their technology spend around a liability they have never formally sized or agreed to.
The glass ceiling on your ambition
Like any debt, this one compounds and every shortcut makes the next change a little harder. Every workaround becomes something the next workaround has to work around (yes, re-read that!).
If it's not dealt with, an ever larger share of your capacity goes on simply servicing what you already have, keeping the lights on, patching, maintaining, firefighting, rather than building anything new... this is even harder in a SaaS/Cloud based world, where regular updates are pushed out by the vendor, but regression testing takes longer than the release cycle due to the volume of modifications you've made, and so you end up taking one in every four upgrades and don't even get me started on the potential cyber risk by missing out on critical patches!
This is the part leaders consistently underestimate. A business paying down a heavy technical debt is not standing still, it is running hard just to stay in place. The team looks busy but struggle to say what with, the spend looks high, and yet very little new value appears. That gap between effort and output is the interest payment, and it grows quietly every year you ignore the ceiling on your ambition.
Technical debt sets the ceiling on every strategic pivot the business wants to make next. You want to launch a new product, enter the a market, roll out a new capability, and you discover you can't or at least not without a project far larger and slower than anyone expected, because the foundations will not take the weight. The ambition is sound and the business strategy is right. It's the invisible mortgage that makes it unaffordable. Every business has a limit on how much change it can absorb, and technical debt is what sets that limit dangerously low in a way that can prevent the organisation from keeping pace with competitors.
The situation is about to get worse
Now the timely part and the one most leadership teams have not yet clocked.
AI is about to become the fastest generator of technical debt the world has ever seen, and it will arrive wearing the costume of productivity.
AI coding assistants and agents can now produce enormous volumes of working code at extraordinary speed. That sounds like pure upside, and in the right hands it is a genuine advance.
So lets be clear about what is actually being delivered in many instances:
Every line an AI generates for you is bespoke, custom development.
It is not an off-the-shelf product someone else maintains, patches and supports.
It is your code, in your estate, that somebody (or something) has to understand, secure, test and maintain for as long as it runs.
It is custom tech in disguise, and it carries every one of the lifetime costs that phrase implies.
It's a support risk that might make recovery harder, longer and slower when it breaks, because the code hasn't been created to an agreed set of standards.
Agentic AI sharpens the risk further. Point an agent at a problem and it will happily wire together bespoke integrations and workflows across your systems, quickly and largely unsupervised. What you are left with is a new layer of custom plumbing that works today but that no human fully designed, fully understands, or can confidently change tomorrow. It is debt that is harder to see than the ordinary kind, precisely because a machine wrote it and it appeared almost for free.
The danger is not the AI itself, it's signing a very large mortgage at speed while calling it a productivity gain. Generate ten times the code in a tenth of the time, apply none of the discipline you would demand of any other bespoke build, and you have not saved money. You have quietly borrowed against every future year, and deferred the repayments to a version of the business that will wonder how the estate became so tangled, so fast.
Jim Collins studied exactly this pattern of behaviour in Great by Choice, though he was not writing about AI. His standout companies, the ones that thrived through genuine turbulence, shared a discipline he called firing bullets before cannonballs - small, low-cost, calibrated tests to see what actually works, before committing serious resource to a big, decisive bet. The companies that struggled did the opposite. They fired large, uncalibrated cannonballs, resourced with confidence, tested with nothing, and when the shot missed they had already spent the capacity of a small business on a single unproven idea. Letting an AI agent generate and wire together your systems at scale, with no review, no standard and no plan for who owns the result, is exactly that, an uncalibrated cannonball, fired at a speed no comparison company could previously afford. The organisations that get this right will use AI to fire far more bullets, cheaply and quickly, and reserve the cannonball, full production rollout, for the code that has actually earned it.
How boards should treat it
The organisations that stay ahead of this treat technical debt as what it is: a managed financial liability, not a technical inconvenience.
That means putting it on the risk register with an honest sense of its scale and its interest rate. It also means creating and protecting a standing budget to pay it down deliberately, rather than only ever adding to it. As a benchmark, analysis reported by McKinsey suggests a systematic reduction programme typically needs somewhere around 15 to 20 percent of the technology budget allocated every year, allocated on purpose rather than found by accident once something breaks.
It also means asking, before any major initiative, not just "what will this cost to build?" but "what will this cost to own?". Perhaps more crucially, in this new era, it means governing AI-generated code exactly as you would govern any other bespoke development: with clear ownership, engineering standards, review, documentation and a maintenance plan. The moment AI output is treated as free rather than as custom software, the mortgage starts compounding again, only faster.
Better still, rather than creating a new cottage industry around agentic AI development, my advice is to buy AI native products, that have been developed with clear standards, from the ground up using LLM's as the engine and can be delivered as a pure off the shelf solution, created to clear standards, properly maintained and fully supportable.
The real position
Its very rare for any business to run completely debt free. A little borrowed speed, taken knowingly and paid back on purpose, is good management. The danger has never been having technical debt, it's having a mortgage you cannot see, on terms you never agreed, growing at a rate nobody is tracking.
The winners over the next few years will not be the organisations with the cleanest code. They will be the ones who can see the liability clearly, price it honestly, keep it serviceable, and refuse to let a wave of AI-generated bespoke tech quietly double the balance while everyone celebrates how much faster they are moving. You are already paying this mortgage. The only question is whether you are the one who decided to take it on.
