Technical debt. It’s one of those insidious things that creeps up on you—quietly, almost politely—until one day you realise you’re spending more time firefighting than actually delivering anything new. At that point, it’s not just slowing you down; it’s actively standing in your way, blocking progress, and sapping morale.
How does it get to this point? Well, legacy systems rarely start out as a problem. In fact, they’re often a source of pride at first—familiar, reliable, and built up over years of hard work. But over time, layer upon layer of quick fixes and workarounds accumulate. Each one makes sense in the moment, but together they form a tangled web. Eventually, making even the smallest change feels risky. Everything is interconnected, nothing is well documented, and nobody really wants to be the one to poke the bear.
Yet, the business still expects progress. Customers still want new features. And your team? They just want to do good work without feeling like every change is a potential minefield.
This is the reality that CTOs and engineering leads face every day. The temptation is to call a halt, to stop everything and refactor the whole system from scratch. But let’s be honest—the business won’t wait, and neither will your customers. The world keeps moving, and so must you.
So, what do we do? We don’t tell teams to stop delivering and fix their code. That’s a fantasy. Instead, we help them change the way they work so they can gradually refactor while still keeping the lights on. It’s about making better decisions at the system level:
- Understanding which changes will have the biggest impact
- Prioritising improvements that unlock value, not just tidy up code
- Embedding engineering practices that allow for continuous improvement without grinding development to a halt
Because here’s the uncomfortable truth: technical debt isn’t just a technical problem. It’s a system of work problem. If you don’t change how decisions are made, how teams collaborate, and how work flows through the organisation, then even the best refactoring efforts will just lead to more debt. You’ll be running in circles, never quite catching up.
From my experience, the teams that succeed are the ones that:
- Make technical debt visible and discuss it openly
- Build improvement into their regular workflow, not as a separate “someday” project
- Focus on small, high-impact changes rather than grand rewrites
- Foster a culture where it’s safe to challenge the status quo and suggest better ways of working
If you’re dealing with a system that feels like it’s holding you hostage, let’s talk. I don’t fix the system for you. Instead, I help you change the way you work so that fixing it becomes a natural part of how your teams deliver value. It’s about shifting the conversation from “how do we get rid of technical debt?” to “how do we work in a way that prevents it from piling up in the first place?”
Because in the end, managing technical debt isn’t about rewriting everything. It’s about changing the system of work so that improvement is continuous, sustainable, and—most importantly—part of how you deliver value every single day.
