- Technical debt usually builds up when your organisation is faced with tight deadlines and resource constraints.
- Velocity loss is the symptom organisations notice first.
- The information needed to prevent this typically exists inside the organisation already. Request a ‘technical debt wish list’ from the development team, i.e. things they’d fix if given time.
- Change your organisation’s rules by tracking technical debt ratio, devoting some engineering time to technical health and making it safe for developers to speak up about errors.
In Jenga, you remove blocks from the base to build higher. Early moves are easy – the tower is stable, choices are plentiful. But each block pulled weakens the foundation while adding height. Eventually, every move becomes precarious. The tower wobbles. You’re no longer building; you’re desperately searching for that one block you can pull without the rest of them toppling.
This is exactly how technical debt accumulates. Every shortcut, every quick fix, every ‘we’ll refactor later’, is a block pulled from your foundation. Unlike Jenga, which is a zero-sum game where players are bound by the rules to pull blocks, many organisations opt to pull those blocks deliberately. Subsequently, technical debt creates a perpetual state of instability that is estimated to cost enterprises trillions globally each year.
How the game starts
It all begins innocently with quick fixes: ‘Let’s leave it for now and come back later when we have more time.’ That’s the biggest lie in software. And the usual suspects are behind it: deadlines, resource constraints, and a natural desire to chase the next big thing. It’s understandable, as no one wants to crack their heads on problems they’ve already solved – or sort of solved. At the beginning, it’s an easy way out because the early blocks are easy to pull, but as time passes, things start to get shaky.
The velocity trap
Those early shortcuts seem harmless until you measure what happens next. Consider a typical software company a couple of years into operations. Development velocity – the amount of work, number of commits, or code changes per individual that can happen in a function of time – starts dropping. And one of the biggest underestimated items is when some kind of work simply cannot be done because we’re so deep in technical debt that we just can’t move forward anymore.
Why? Because developers spend increasingly more time navigating around weak spots, like Jenga players circling the tower, testing each block.
Where the debt hides
Velocity loss is the symptom organisations notice first. But the underlying problem takes different forms, and some are far more expensive than slow shipping.
Architectural mismatch is the silent budget killer. If you build a real-time system in a language designed for stateless web, you’re going to have a hard time. The more you push it, the slower you get.
Picture this: a stateless framework handles maybe 20-24 concurrent users on a piece of hardware like a MacBook Pro for something like a Zoom video call. A proper stateful solution on the same hardware can serve tens of thousands of simultaneous connections. If you’re dead set on the stateless solution, you’ll pay hundreds of thousands of dollars in cloud costs versus a fraction with the stateful one. The same problem, same hardware, radically different economics because of an early architectural choice that might have seemed reasonable at the time. On the other hand, stateful implementation might be an overkill and overspend for just a web application based on customers using it occasionally and without a need to see data or information in real time.
Security exposure is a time bomb. Every piece of software has a countdown timer, and when it runs out, be it that vendor support ends or open-source software isn’t kept up to date any longer, vulnerabilities discovered afterward never get patched.
Cybersecurity is a constant arms race between bad and good actors. The former find ways to exploit vulnerabilities, and the latter figure out ways of fixing them. Remove the good actors from the equation altogether, and you’re a sitting duck. If anyone still runs Windows 2000, you can bet their computer is compromised. Because that version of Windows is so old, no one supports it anymore. In whatever state it was on the last day of support, that’s what it is today. And as it ages, malicious agents have more time to find effective attack vectors.
That was the case in 2017, when Equifax failed to patch a known vulnerability in Apache Struts. The result: 147 million Americans’ data exposed. Total cost exceeded $1.4 billion. One missing patch. One block too many. A similar mistake occurred when Marriott acquired Starwood Hotels, only to later discover that Starwood’s compromised infrastructure became a gateway for attackers to infiltrate Marriott’s broader network.
The competitive cost
The damage isn’t only internal. While you’re navigating your wobbling tower, someone else is building afresh. Here’s the question worth asking: could a 17-year-old with an AI model and a MacBook disrupt your organisation in a couple of years?
The answer increasingly depends on technical debt. Start-ups build on solid foundations using modern architectures. They deploy in minutes what legacy systems require weeks to ship. They scale automatically while incumbents provision servers manually. Amazon deploys new code every 11-12 seconds. Meanwhile, many enterprises still run critical operations on systems written before their newest employees were born.
Furthermore, because of all the accumulated complexity, we are reaching a point where it becomes almost impossible to comprehend the entirety of a system and all the implications the new changes may have on it. And because the prep work and experimentation do not go into value creation but to ensure the said system still works, it leads to uncertainty and slowdown. In effect, technical debt determines whether you can respond to market shifts on time.
The players who know
The information needed to prevent all of this typically exists inside the organisation already. Your developers know exactly which blocks are risk factors. In every codebase, there are sections marked ‘TO-DO’ or ‘Fix me later’. These are distress signals from developers’ past selves, warning future maintainers.
What I often do is I request a ‘technical debt wish list’ from the development team – things they’d fix if given time – the response is immediate and detailed. They know which services will fail under load, which integrations are held together with digital duct tape, and which databases haven’t been backed up properly in years.
Yet in most organisations, acknowledging technical debt hurts performance reviews. Developers who advocate for refactoring over features are seen as not delivering value. So they stay quiet, pull the safe blocks, and watch the tower wobble, knowing exactly which move will bring it down.
Change the rules
If the problem is structural, so is the solution. Organisations that successfully manage technical debt share three characteristics:
They measure it explicitly by tracking ‘technical debt ratio’, the percentage of engineering time spent on maintenance versus innovation. When it exceeds a certain level, they prioritise refactoring sprints. They budget for it by allocating some percentage of engineering time to technical health. They make it safe to speak up. When developers can flag problems without being blamed for not shipping new features, they are more likely to point out those vulnerabilities.
The most effective practice I’ve seen is simple: ask your team regularly, “If we were starting from scratch today, how would we build this?” Use that question as a forcing function. The gap between the answer and your current reality is your debt, made visible.
It’s all about choice
Technical debt trades the future for the present. And sometimes that’s necessary; sometimes the shortcut is the right call. The problem arises when organisations pretend the trade-off doesn’t exist, when they stop tracking the cost, when they silence the engineers who see it accumulate, or those who care about high quality.
Then, technical debt creates a slow-motion collapse. Value erodes gradually. Competitors gain ground. The tower doesn’t fall all at once; it just becomes impossible to build any higher. It’s your turn. Choose your next move wisely.
Lukasz Lazewski is CEO of LLInformatics.
Read more
How to match tech investment with real-world output – Your tech dashboards are saying that your systems are running, but your employees might be having a completely different experience
Are you really ready for AI? Exposing shadow tools in your organisation – Without clear AI governance, employees often misuse publicly accessible external tools, known as ‘shadow AI’
Five key signs of a bad MSP relationship – and what to do about them – Sometimes, the relationship with your managed service provider (MSP) may not work out long-term. Here are five signs of an underperforming partnership, and how to overcome them
