Every codebase has skeletons in the closet. You know exactly where they are. That module nobody wants to touch. The database migration that “worked” but left three orphaned tables. The authentication flow that was built as a temporary solution eighteen months ago and is now load-bearing infrastructure. You know where all the bodies are buried because you helped bury some of them.
The engineers know too. They bring it up in retros. They mention it in 1:1s. They write tickets that sit in the backlog with labels like “tech-debt” and “cleanup” and “please-for-the-love-of-god.” And nothing happens, because there’s always another feature, another deadline, another client request that takes priority.
Here’s my strong opinion: that’s not an engineering failure. That’s a leadership failure. And specifically, it’s a failure of the person in charge of planning.
Technical debt doesn’t accumulate because engineers are lazy. It accumulates because leadership won’t make the hard call to stop building and start cleaning.
Why the conversation keeps failing
Engineers are terrible at selling refactoring. I say this as an engineer. We walk into a board meeting or a planning session and say something like “we need to refactor the payment module” and then wonder why nobody’s excited.
The board hears: “We want to spend three weeks rewriting something that already works, and at the end of it, nothing will look different to users.”
Product hears: “Engineering wants to delay the roadmap so they can do something I can’t put in a release note.”
And honestly, they’re not entirely wrong to push back. “We need to refactor” is not a business case. It’s a statement of engineering preference, and it sounds like engineers wanting to rewrite things because they don’t like how the code looks. Which, let’s be honest, is sometimes exactly what it is.
The problem isn’t that the board and product don’t understand technical debt. The problem is that we haven’t learned to explain it in terms they care about.
How to actually talk about technical debt
Stop saying “refactor.” Start saying “risk.”
The board doesn’t care about code quality in the abstract. They care about velocity, reliability, and cost. So talk about those:
“If we don’t address this, feature development will slow down by roughly X% over the next two quarters.” That’s a velocity conversation. Product cares about velocity. The board cares about velocity. Give them a number, even if it’s approximate. An approximate number beats a vague feeling every time.
“This component has caused three production incidents in the last six months. Each one cost us Y hours of engineering time and Z in customer impact.” That’s a reliability conversation. Frame debt as operational risk, not aesthetic preference.
“We’re currently spending 30% of sprint capacity working around this system instead of building new things. Fixing it would free up that capacity permanently.” That’s a cost conversation. You’re not asking for time off from features. You’re arguing that fixing the debt IS a feature investment, because it unlocks future speed.
The CTO’s job, the head of engineering’s job, is to translate between the engineering team who feels the pain daily and the board who needs to understand why spending money on invisible work is a good investment. If you can’t make that translation, the debt will keep growing.
The nuclear option (and why it works)
I’ve done the thing that most management advice tells you not to do. I’ve walked into a board meeting and said, effectively, “engineering is taking four weeks off from features to clean up technical debt, and you’re going to have to deal with it.”
I won’t pretend I was diplomatic about it. Sometimes being a strong voice in the room is the only way to get it done. The constant push for features is relentless, and if you don’t draw a line, nobody else will. Your engineers can’t do it, they don’t have the authority. Product won’t do it, their incentives point the other way. It has to be you.
Here’s the tactical bit that makes it work: timing.
I stagger it with summer holidays. Engineering gets their deep cleanup sprint while the exec team and product are rotating through their summer breaks. Product uses that time for planning, research, user interviews, all the things they never have time for when they’re busy writing tickets for engineering. When everyone comes back, engineering has a cleaner codebase, product has a sharper roadmap, and nobody lost any real collaboration time because they weren’t all in the office anyway.
It’s not subtle. But it works. And the second time you do it, there’s less resistance because everyone remembers that the first time didn’t actually cause the sky to fall.
The compound interest problem
The thing about technical debt that non-engineers consistently underestimate is the compounding. A small shortcut in month one becomes a constraint in month six, becomes a blocker in month twelve, becomes a rewrite in month eighteen. The cost of fixing it doubles every few months, while the cost of living with it increases steadily.
I think about it like a house. If you don’t fix the small crack in the wall when you first notice it, water gets in. Then you’ve got damp. Then you’ve got mould. Then you’ve got a structural problem. The person who says “we’ll fix it later” is the person who ends up paying ten times more for the repair.
Every startup CTO has been in the room where someone says “we’ll clean that up after launch.” You won’t. You know you won’t. And in six months, you’ll be in a different room explaining why the thing that was a one-week fix is now a one-month project.
The engineer’s side
I want to be fair to the other perspective, because it’s not all leadership’s fault either.
Engineers sometimes want to refactor things that don’t need refactoring. Code that’s ugly but working and stable isn’t necessarily debt. It’s just ugly. There’s a difference between code that’s accumulating operational risk and code that offends your sense of aesthetics. Learning to tell the difference is part of growing up as an engineer.
The engineers who are best at getting refactoring work approved are the ones who can articulate the business impact. “This module is ugly” gets nowhere. “This module has caused three incidents and will cause more” gets budget.
If you’re an engineer reading this, help your CTO make the case. Bring data, not feelings. Track the incidents, the workarounds, the time spent navigating around the problem. Make it easy for your leadership to fight for the investment, because they’re fighting on your behalf and they need ammunition.
The “we don’t have time” trap
The most common pushback is “we don’t have time.” And it’s almost always wrong.
You don’t have time NOT to address technical debt. Every week you delay, you’re paying interest on the shortcuts you took. Your engineers are spending time working around problems instead of building new things. Your incident rate is creeping up. Your onboarding time for new hires is getting longer because the codebase is harder to understand.
“We don’t have time to refactor” usually means “we haven’t prioritised it.” And that’s a planning decision, not a time constraint. You have exactly the same number of hours as everyone else. You’re choosing to spend them on features instead of foundations.
That choice might be the right one in a given sprint. There are genuine moments where shipping a feature by Friday matters more than cleaning up a module. Startups live on deadlines, and sometimes you take the shortcut knowingly and deliberately. That’s fine. That’s CONSCIOUS debt, and it’s a legitimate tool.
The problem is when every sprint is a deadline sprint. When the shortcuts are never deliberate, just habitual. When “we’ll fix it later” becomes the default rather than the exception. That’s when leadership has failed, because leadership’s job is to create the space for maintenance, and nobody else can.
Clean your house
I’ll keep this simple. If you’re a CTO or head of engineering and you haven’t scheduled dedicated technical debt reduction time in the last six months, you’re behind. Your engineers are telling you, in retros, in 1:1s, in resigned Slack messages. Listen to them.
Block out the time. Tell the board why. Use the summer holidays if you need political cover. But do it, because the alternative is a codebase that gets slower and more fragile every month until something breaks badly enough that you’re forced to fix it on someone else’s timeline.
Clean it early, or it will kill you later. That’s not engineering advice. That’s leadership advice.