Every firm has a version of this meeting. The CTO gets fifteen minutes on the board agenda - usually near the end, after the financial review and the pipeline discussion, somewhere between AOB and lunch. They talk about platforms, upgrades, vulnerabilities, end-of-life dependencies. The board listens politely. Someone asks whether this is urgent or can wait until next quarter. The CTO hesitates, because the honest answer is "both," and that's a genuinely difficult thing to say in a way that sounds credible. The board thanks them for the update and moves on.
Nothing was decided. Nothing was rejected, either. It just... drifted.
Our IT team always says they need more budget for infrastructure. We've managed so far. I don't see the urgency.
I hear some version of that from managing partners at least once a month. And honestly? It's not an unreasonable position. If you're running a mid-market professional services firm and the systems are broadly working, clients aren't complaining loudly, and the team seems to cope, then deferring a £150k infrastructure investment in favour of something with a clearer return feels like sound judgement. It's what I'd probably do too, based on the information most boards actually receive.
But that's the problem. The information most boards receive about technical debt is terrible. Not wrong, exactly. Just untranslated. It arrives in a language the board didn't ask for and can't act on. The rational response - defer - is based on an incomplete picture. The IT team leaves frustrated. The board leaves assuming everything is basically fine. Both are acting reasonably within the frame they've been given.
The frame is what's broken.
I want to be upfront about something: I used to think this was primarily a communication problem - that if IT leaders just got better at presenting, the budget would follow. I was wrong about that. I've watched technically brilliant people deliver polished board presentations and still walk away with nothing. The issue isn't presentation skills. It's that nobody has built the translation layer between what the IT team sees every day and the commercial outcomes the board is responsible for. That's what I want to try to do here.
Technical debt is one of those terms that sounds like it should be intuitive but isn't. I've been in rooms where a CTO uses the phrase and the board nods along, and then afterwards the managing partner quietly asks me, "What did he actually mean by that?"
So let me have a go.
Technical debt is the accumulated cost of past decisions to do things the quick way rather than the right way. Every time a digital system was patched rather than properly fixed, a workaround bolted on rather than the underlying problem sorted, or a platform stretched beyond what it was designed to do rather than replaced - the firm added a little more to its technical debt balance.
Think of it like a house. You buy a house and the boiler is working but ageing. You could replace it now for a few thousand pounds, or you could leave it and hope for the best. Year one, nothing happens. Year two, it starts making a noise, so you get someone to patch it. Year three, it's leaking slightly, so you get a different patch. Year four, the heating engineer tells you the model is no longer supported and parts aren't available. Year five, it fails in January and you need an emergency replacement that costs three times what the planned one would have, plus the water damage to the kitchen ceiling.
That's technical debt. The house still stood. The boiler technically worked. Until it didn't - and the cost of fixing it had quietly tripled while you weren't looking.
In digital terms, these decisions accumulate across the entire platform estate. A CMS that's been patched rather than upgraded. An integration hacked together for a specific project and never rebuilt properly. A security framework running on software the vendor stopped supporting two years ago. Each one individually seems manageable. Together, they create a platform that's progressively harder to change and increasingly expensive to keep alive.
Here's where I want to say something that might surprise you. I don't think the communication failure around technical debt is primarily the board's fault. But I've come to think it's more the IT team's fault than most people want to admit - and I say that as someone who's spent years sitting on their side of the table.
Your IT team describes reality in platform versions, dependency graphs, and vulnerability scores. Your board describes reality in commercial outcomes, risk probabilities, and financial impact. Neither language is wrong. But here's the thing: the IT team is the one asking for budget. That means the burden of translation sits with them. And most technical leaders I've worked with have never been trained to do it, never been asked to do it, and - if I'm honest - sometimes hide behind the jargon because it's easier than having to quantify something uncertain.
When your CTO says "we're running an end-of-life CMS with an unsupported PHP version," they are describing a genuine, material risk with total accuracy. But to a managing partner, that sentence contains no information they can act on. What does "end of life" mean commercially? What's the probability something goes wrong? What's the financial exposure if it does?
The CTO knows the answers to all of those questions - or could work them out. They've just never been asked to frame it that way. They've been asked to "give the board an update on IT," which is an invitation to describe the technical landscape, not to quantify the commercial risk. And most of them take that invitation at face value, year after year, and then wonder why the budget never materialises.
I sat in on a board meeting about eighteen months ago - a mid-market accounting firm, around 250 people - where the head of IT presented a slide titled "Platform Risk Assessment." Traffic-light system: green, amber, red. Three items were red. The board asked what red meant. The IT lead said "critical - needs addressing within six months." The finance director asked how much. The IT lead said he'd need to scope it properly but estimated somewhere between £80k and £200k. The board - understandably - didn't know what to do with a range that wide, attached to a risk they couldn't quantify, so they asked for a more detailed proposal next quarter.
That proposal never came back to the board. Not because the IT lead forgot, but because he didn't know how to build a business case in the language the board expected. He could describe the technical risk in his sleep. He couldn't articulate the commercial consequence with the precision a finance director would accept. And nobody helped him bridge that gap.
But surely that's the IT lead's job to figure out?
Yes. And no. It's their job, but most of them were hired to run infrastructure, not to write investment cases. The firms that solve this problem tend to have a COO or CFO who takes it upon themselves to drag the technical reality into a commercial frame - someone who asks the IT team the right questions rather than waiting for them to volunteer the right answers. That's the structural fix. Someone needs to own the translation.
You don't need to understand a line of code to recognise technical debt. It has commercial symptoms that are visible from the boardroom, if you know what to look for.
The most obvious one: everything takes longer than it should. New features, integrations, improvements to client-facing tools - they all take significantly longer than expected. Your team isn't slow. Your infrastructure is. Every change requires navigating layers of accumulated complexity, like renovating a house where every wall turns out to be load-bearing. A competitor with a cleaner platform can ship the same improvement in weeks. You're looking at months.
I spoke with a COO at a consulting firm recently who told me they'd tried to add a simple client feedback form to their portal. Estimated at two days of development. It took eleven weeks. Not because anyone was incompetent - because the portal sat on a platform so tangled with legacy dependencies that touching one thing risked breaking three others. Eleven weeks for a feedback form. That's technical debt made visible.
Then there's the maintenance cost creep, which is the one that should really get a finance director's attention. When technical debt accumulates, an increasing proportion of the IT budget gets consumed by keeping existing systems running rather than building anything new. Gartner's research suggests organisations with significant technical debt spend 60-80% of their IT budgets on maintenance, leaving only 20-40% for improvement. And that ratio gets worse over time, not better. If you looked at your IT spend three years ago versus today and the maintenance percentage has climbed, that's the financial signature of compounding technical debt.
Security exposure is the one that keeps me up at night, if I'm honest. Unsupported platforms can't receive patches for newly discovered vulnerabilities. Each unpatched vulnerability is essentially a known route into your systems that you've defaulted into not closing. IBM's Cost of a Data Breach report puts the average breach cost at $4.45 million globally. For a mid-market professional services firm handling sensitive client data, the reputational damage alone could be existential. And the risk isn't theoretical - it's specific and identifiable. Your IT team almost certainly knows exactly which unpatched vulnerabilities exist in your estate right now. They just haven't been asked to put a number on what happens if one of them gets exploited.
The competitive angle tends to land hardest with managing partners. Want to integrate AI-powered tools into your client service? Your legacy platform probably can't support it. Want to connect your CMS to your CRM so marketing can track which content drives enquiries? That integration might require rebuilding the CMS first. Want to offer clients a self-service portal? The underlying architecture might not allow it without a ground-up rebuild. Technical debt doesn't just cost you money today. It limits your options at precisely the moment when optionality matters most - when the market is moving and your competitors are investing in capabilities you can't match.
And then there's the one that gets overlooked: your technical team is quietly looking for the exit. Technical professionals who spend their days maintaining legacy systems rather than building new capability know they're professionally stagnating. They can see what their peers at other firms are working on - modern platforms, AI projects, interesting problems. And they're stuck patching a CMS from 2016. The turnover cost of losing a senior developer isn't just the recruitment fee. It's the institutional knowledge that walks out the door, the three to six months it takes a replacement to understand your specific tangled estate, and the projects that stall in the meantime. I've seen firms lose two technical staff in quick succession and suddenly find themselves unable to make any changes to their platform for months. That's a business continuity risk, and it started with technical debt making the job unattractive.
Technical debt compounds. Not metaphorically - literally, in the same way financial debt compounds.
A decision to defer a platform upgrade this year doesn't just push the same cost into next year. It adds complexity. The platform gets another year older. More workarounds get bolted on. More patches accumulate. The vendor moves further ahead with their supported version, making the gap you need to bridge wider. The developers who understood the original architecture leave, and their replacements inherit a system with no documentation and a decade of accumulated shortcuts.
So a platform upgrade that might have cost around £60,000 two years ago could realistically cost £150,000 today. In another two years? Potentially £300,000 or more - not because the technology got more expensive, but because the accumulated complexity of deferred maintenance has made the work dramatically harder. These numbers are illustrative rather than universal, but they're consistent with the patterns we've seen across dozens of mid-market platform assessments. The trajectory is real even if the specific figures vary.
The board that defers infrastructure investment is not saving the upgrade cost. It's borrowing against a future cost that is growing. And unlike financial debt, there's no fixed interest rate. The "interest" on technical debt is unpredictable, because it's driven by external factors the firm doesn't control: vendor support timelines, emerging security threats, shifts in client expectations, regulatory changes that require platform capabilities the legacy system can't provide.
We've been meaning to sort the platform out for ages, but there's never a good time.
There isn't a good time. But there is a cheaper time, and it was probably two years ago. The second cheapest time is now.
Right. If you've read this far, you're probably thinking, Fine. I get it. But what do I actually do with this?
You ask better questions. Not more questions - better ones. Questions that force the technical reality into a commercial frame the whole board can engage with.
Ask what percentage of the IT budget is spent on maintenance versus improvement - and how that ratio has changed over the last three years. This is the clearest financial signal of compounding technical debt. A healthy ratio for a mid-market firm is roughly 60% improvement to 40% maintenance. If yours is the inverse, or heading that way, you have a compounding problem that's getting worse while you're having other conversations.
Ask what the three largest risks in the current platform estate are, and what it would cost to address each of them. Note the phrasing: "what would it cost to address" rather than "do we need to fix this." You're asking for a number, not a yes/no. That changes the conversation entirely, because it forces the IT team to do the commercial translation work rather than just describing the technical landscape.
Ask which platforms are running on unsupported software, and what the security exposure is. Not theoretical risk - actual, identifiable vulnerabilities in systems that are no longer receiving security patches. If the answer involves your CMS, your client portal, or anything connected to sensitive data, you need to know. And if the IT lead can't answer that question in the meeting, that's itself an answer worth sitting with.
Ask what client-facing capabilities the firm is unable to provide because of platform limitations. Your IT team knows exactly what they can't build for clients because of the platform's constraints. They've probably never been asked to list it in a board setting. The answers might surprise you.
And ask what it would cost to address the most significant technical debt over the next two years, compared with the cost of not addressing it. The comparison is what matters. Not "how much does the upgrade cost" - that's the question boards usually ask, and it always sounds expensive in isolation. When you frame it as a comparison, the investment case becomes visible. Often, uncomfortably so.
These questions aren't designed to put your IT team on the spot. They're designed to give them the framework to communicate what they already know in a language the board can act on. Most technical leaders I've worked with are desperate to have this conversation. They've just never been given the right format for it.
I want to come back to where I started - but with a harder edge than I've been giving it.
The board's job is to allocate capital to the opportunities and risks that offer the best return. When technical debt is presented as a technical problem, it doesn't compete effectively against commercial priorities that come with clear numbers attached. That's partly a failure of translation. But it's also, if I'm being direct, a failure of curiosity. Most boards have never asked their IT lead to quantify the commercial cost of inaction. They've accepted the technical briefing at face value and moved on. That's not negligence - but it's not good governance either.
The IT team's job is to maintain and improve the firm's technology estate. When they flag risks and don't get budget, the temptation is to blame the board for not listening. But in most cases I've seen, the IT team hasn't done the work of translating the risk into commercial terms. They've described the problem in their own language and hoped the board would meet them halfway. That's not a communication failure - it's an abdication of the commercial responsibility that comes with asking for significant budget.
Someone needs to build the bridge. Maybe it's the COO. Maybe it's an external adviser. Maybe it's the IT lead with a bit of coaching on how to frame the conversation differently. But someone needs to take the technical reality and render it in commercial terms - specific costs, specific risks, specific lost opportunities - so the board can make a genuinely informed decision.
Because here's what I've seen happen when that bridge gets built. When a managing partner understands that their platform's technical debt is accumulating a specific, estimable cost per year - in maintenance overhead, in the inability to adopt new client tools, in security exposure, in the staff frustration that accelerates turnover - they don't defer. They act. Not because they suddenly care more about technology. Because they finally have the information they needed to make a different decision.
The five questions above are a starting point. If you want to understand where your firm's platform estate sits on the technical debt curve - and what addressing it would actually require - there's a practical assessment framework in our platform section worth working through. And if the conversation turns to how you'd structure the investment case for the board, I've written about that too. The hard part isn't getting the budget. The hard part is having the conversation in the right language. Everything else follows from that.