Good leaders create tech debt

Tech debt starts with you

I once took a significant pay cut to lead technology for a startup going from zero to one. The mission mattered, the founders were inspiring. The problem space, mental health and wellbeing felt genuinely important.

But there was a problem we didn’t yet have an answer to, we didn’t actually know what the product was.

My first real decision wasn’t a feature or a roadmap. It was architecture for something that didn’t yet exist. In that moment, before I’d hired a single engineer, I created our first piece of tech debt.

Tech debt is bad?

Tech debt is usually framed as failure, it costs money to fix, It competes with features on the roadmap and it forces uncomfortable trade-offs.

From a leadership perspective, it’s often assumed to be the result of:

• poor workmanship
• messy code
• shortcuts
• weak engineering discipline

I say that framing is wrong. Tech debt is not a failure if it is consciously created and actively managed. The real problem is reckless and unmanaged tech debt. Creating tech debt is not a mistake it’s an inevitable leadership decision, whether you acknowledge it or not.

Where tech debt actually begins

In that startup, I leaned on my experience and what I knew. My background was Microsoft and .NET together with React and ReactNative for mobile. I had people in my network who could move quickly in those ecosystems.

So invitably I chose:

• .NET Core
• React Native
• A shared, backend-first architecture

None of these choices were wrong, but from that moment the course was set.

• Every future hire needed to fit that stack
• Every architectural decision compounded previous ones
• Every optimisation narrowed future options

Tech debt didn’t start with messy code. It started with me, the alignment and the need for speed. I often ask myself if I’d make the same decision with hindsight, but I now know that is the wrong question to ask.

The shift in perspective leaders need

Tech debt is created deliberately long before it shows up operationally.

Examples leaders rarely label as tech debt:

• Choosing one stack over another
• Hiring for speed over skill diversity
• Optimising for today’s market, customer, or investor pressure

Each of these decisions is rational and each of them is debt.

I found it useful to think about whether the debt is acquired deliberately and whether it is prudent or reckless

— Martin Fowler, Technical Debt

The failure isn’t taking it on, this is often required to make good business decisions, the failure is forgetting you did.

Once you accept that tech debt is inevitable, the question changes from “How do we eliminate tech debt?”, to “What level of tech debt is acceptable right now and for how long?”

This reframes leadership responsibility. Great leaders understand three uncomfortable truths:

• Paying debt too early slows learning and market fit
• Paying debt too late compounds fragility and risk
• Timing matters more than purity

The job is not cleanliness and making perfect decisions, instead it’s about making conscious intentional trade-offs.

Conscious vs unconscious

Its useful to define what is conscious and unconscious tech debt as it has an impact of team performance.

Conscious tech debt:

• Has a clear reason
• Has an owner
• Is revisited deliberately

Unconscious tech debt:

• Hides behind “we’ll fix it later”
• Has no decision record
• Becomes invisible until it hurts

Trust from the business erodes not because debt exists, but because over time it appears accidental or because of ‘poor’ decisions that ultimately slows the business down. High performing teams aim to minimise unconscious tech debt and actively manage it, whilst also communicating this regularly to the business.

How AI changes the game

AI does not eliminate tech debt, but it does significantly change the unit economics of paying it down.

Recently, I’ve been involved in a full legacy API rewrite of a production platform using modern AI tools and agents. Previously this would have been an all-consuming, high-risk project:

• Tying up most of the team for 12+ months
• Creating delivery paralysis
• Carrying a real risk of organisational failure if it overran

In most environments, proposing that kind of rewrite would be career-limiting. Today, that same work becomes viable with the advance of AI.

That api rewrite is now a 3–4 month project with a small team:

• Supported by specialist vendors
• Accelerated by AI-assisted refactoring and testing
• With most of the team still focused on delivering customer value

This fundamentally changes the maths, and accelerates rapid pay down of debt.

What AI meaningfully improves:

• Faster refactoring and migration (often x10–20)
• Lower marginal cost of cleanup
• Reduced fear of touching legacy systems (with testing baked into the workflow)

What AI does not fix:

• Architectural trade-offs
• Incentive misalignment
• Leadership avoidance

My working mental model is simple:

AI lowers the interest rate on some tech debt, it does not erase the principal.

That’s powerful but multiplied if leaders are already making conscious decisions.

Closing reflection

The worst type of tech debt is reckless and unmanaged. If you’ve never created tech debt, you’ve never led a tech team or product.

Tech debt is here to stay but the unit economics (and hence interest rates) are falling, and will continue to fall further as AI models and tooling improves.

The difference between good and great tech leadership isn’t avoiding tech debt, it’s knowing when today’s speed is worth tomorrow’s cost. That decision never goes away.