What is technical debt in plain English?

Technical debt is the gap between how your systems work today and how they'd need to work to properly support the business. It builds up the same way financial debt does - through reasonable decisions made under pressure. The quick fix instead of the proper one. The system kept years past its sell-by date because replacing it felt like too much hassle. The process bolted on in a hurry that nobody went back to tidy.

Each choice made sense at the time. That's worth sitting with, because technical debt isn't evidence that somebody did a bad job. Like borrowing, it's often the right call - take the shortcut, win the client, keep moving. If you've ever put a big purchase on finance to keep cash free for stock, you already understand the mechanics. Nobody would call that reckless. They'd call it a trade-off - and they'd expect to see the repayments on a statement somewhere.

Technical debt is the same trade-off with the statement missing. Every shortcut charges a small, recurring fee - in workaround time, in fragility, in options quietly closed off - and it keeps charging until you deal with the principal. Most businesses have been paying that interest for years without ever seeing it written down.

How do you spot technical debt without reading a line of code?

You don't need to read code to see technical debt. You can hear it.

"We can't change that, it'll break something else." "Only Dave knows how that works." "That report takes a day to pull together." "Don't touch the upgrade - last time we tried, everything stopped for two days." "We keep a spreadsheet on the side because the system can't do it." "We've always done it that way because the system won't let us do it differently."

Notice that none of those sentences are technical. That's the point. Technical debt announces itself in plain English, in your own meetings, long before anyone opens a laptop. Every one of those lines is an interest payment - paid in workarounds, in wasted hours, in risk piled onto one person, in opportunities you wave through because the systems can't keep up.

There's a simple test worth running this week: pick your most important monthly number - revenue, margin, cash - and trace how it gets produced. Count the hands it passes through and the spreadsheets it visits on the way. That count is a decent proxy for how much debt sits in your core systems.

What is technical debt actually costing you?

The cost shows up in three places.

Time. People spending hours on workarounds that a fit-for-purpose system would simply make disappear. Multiply one person's daily workaround across a team and a year, and you're often looking at the cost of a full salary - spent producing nothing.

Risk. The more fragile and undocumented your systems, the closer you sit to a bad week when something breaks or someone leaves. Dave's resignation letter shouldn't be a business continuity event.

Growth - and this is the expensive one. Technical debt hurts most exactly when you're trying to do something new: win a bigger client, add a site, launch a product line. The bigger client asks for a data feed your systems can't produce. The second site needs the stock system to do something it's never done. You either say no, or say yes and pay rush prices. The debt was invisible while things ticked along. It shows up the moment you push.

This isn't a small-print problem, either. McKinsey has estimated that technical debt amounts to 20-40% of the value of many organisations' entire technology estate. Your business is smaller than the ones they studied. The proportion usually isn't.

Where does technical debt come from?

Mostly from success. A business that's doubled in headcount is running systems specced for the old size. Growth creates pressure, pressure creates shortcuts, shortcuts compound.

It also arrives with change of any kind. The person who built the system leaves, and nobody dares touch it. A new site or an acquisition bolts two sets of systems together and calls it done. A vendor adds modules year after year, each one solving Tuesday's problem.

And it isn't just code you've written. Off-the-shelf tools accumulate debt too - half-configured settings, duplicate records, integrations held together by one person's Zapier account. If your business runs on subscription tools, your technical debt lives in the gaps between them.

None of these are failures. They're what running a real business looks like. Which is why the answer isn't guilt. It's housekeeping.

You don't pay it all off at once

Here's the relief: the goal is never to fix everything. Some technical debt isn't worth paying down - the system's a bit clunky, but it works, costs little, and replacing it would buy you nothing. The skill is telling the difference between debt that's quietly throttling the business and debt that's just mildly annoying. That's a judgement about commercial impact, not technical tidiness, and it's where a clear head matters more than a clever one.

How do you start paying it down?

Four moves, in order.

Write the list. Every system and process, what it does, who owns it, and how much pain it actually causes. Most businesses have never seen this on one page. The act of writing it down is worth more than any tool you could buy this quarter.

Sort by commercial impact. Rank the pain by what it's costing or risking - not by how old or ugly the technology is. Old and ugly but cheap and reliable can stay. New and shiny but fragile at month-end goes to the top of the list.

Pay down the few items doing real damage. Deliberately, one at a time, each with an owner and a finish line. Resist the temptation to fix everything at once - that's how half-finished migrations happen, and a half-finished migration is just new debt with better branding.

Document the rest, and stop borrowing silently. Leave the mildly annoying stuff alone, but write it down, so it's a known quantity rather than a landmine. And when you take a shortcut from now on - which you will, and sometimes should - record it as a decision, with a date to revisit. That's not a one-off project. It's just running a business that takes its systems seriously.

Most businesses have never seen their technical debt written down in one place, which is exactly why it keeps compounding - you can't prioritise what you can't see. A Discovery puts the whole picture on one page: what you've got, what it's costing, and what's worth fixing first - ranked by cost to the business, not by how interesting the technology is.