Hi Reader,

Has your software ever frozen for no clear reason?

Bugs showing up where you least expect them?

A tiny change somehow setting off a chain of other changes nobody planned for?

If any of that sounds familiar, my friend, you (well, your product) probably have technical debt.

And right now, I am living it.
​

Today in 10 minutes you will:

• See why it happens, even on great teams
• Understand why you should care as a PM (with the data to back it up)
• Know the main types of technical debt
• Get practical ways to spot, measure, and track it
• Complete quick self-check: how much debt is your product carrying?

Why I am writing about this

Honestly? Because I feel surrounded by it.

Working in enterprise, especially taking over products you did not build from scratch, can feel daunting. You keep finding gaps in different places.

And that is normal. A lot of these systems are old, which actually means they have been supporting the company for years.

But here is something every PM eventually learns: software has an expiry date.

It is a bit like your phone. You can use it for years, then one day it just gives up.

The good news is that software does not have to break. You can modernize it, update it, rebuild it, and fix the workarounds you put in place a long time ago.

How do I know I am surrounded by it? A few symptoms in my own product:

→ Very little documentation. When I onboarded, almost nothing explained how things actually work.

→ Every update needs a project. A simple version upgrade turns into a months-long effort.

→ Integrations are painful, and the data is hard to get out.

​
What is technical debt?

Technical debt is what builds up when a team chooses the fast or convenient option now instead of the cleaner, more durable one.

It works a lot like financial debt. You borrow time today to ship quicker, then pay it back later with interest: slower changes, more bugs, higher maintenance.

A few common ways it shows up:

→ Older software that was never modernized. Everything ages, everything needs updating eventually.

→ Speed over quality. Teams often have to choose, and a deadline usually wins.

→ Assumptions that expire. You design around something that is true today, the business changes, and the assumption no longer holds. Now you rebuild, or you patch around it.

→ Heavy customization for one client or one edge case that the rest of the product has to carry.

→ Skipped tests and missing documentation that slow down everyone who comes after.

I really like this graph from vFunction.​

It shows what happens when you keep shipping release after release without ever addressing the debt.

Cost, complexity, and risk climb. Velocity, scalability, and resiliency drop. At some point the two lines cross, and the app becomes harder and riskier to work with than it is worth.

The takeaway: left unaddressed, an application tends to need a real modernization roughly every five years.

​
Why would I care about this as a PM?

You do not write the code. So why does this land on your desk?

Because technical debt quietly shapes everything you are trying to deliver.

→ Slow innovation. When the architecture was never built for it, every new idea becomes a 6 to 12 month project. Cost goes up, speed goes down, and your roadmap stalls.

→ Rising run costs. More incidents, more manual upgrades, more time spent keeping the lights on instead of building.

→ Shaky reliability. Outages and slow performance chip away at the trust you have with stakeholders and users.

→ Locked-in data. Poor integrations turn even simple cross-team requests into a project.

→ Painful onboarding. New developers take longer to get productive, which slows the whole team.

And if you need numbers to make the case to leadership, McKinsey has them.​

In their research across 220 companies in seven sectors, the companies with the healthiest tech-debt scores (the top 20%) grew revenue about 20% faster than those with the worst (the bottom 20%), and about 10% faster than the average.

They also found that technical debt typically eats 20 to 40% of the value of a company's entire technology estate.

In plain terms: unmanaged debt is not just an engineering problem. It shows up in the numbers the business actually cares about.

That is the industry view. If you want to see what this looks like on a single product, I once put real numbers on it: around €35K of yearly cost on one app, and how I used that to make the case to leadership.

→ Making the case to kill €35K of tech debt​

​
Types of technical debt

Not all debt is the same. Knowing the type helps you talk about it clearly with your team.

→ Code debt. Messy, duplicated, or hard-to-read code. The classic "we will clean this up later" that never gets cleaned up.

→ Architecture and design debt. The structure of the system itself holds you back. Think a monolith that cannot scale, or services tangled so tightly that one change ripples everywhere.

→ Testing debt. Low or missing test coverage, or fragile tests. Every release becomes a gamble and a lot of manual checking.

→ Documentation debt. Little or no record of how things work and why. New people onboard slowly, and knowledge lives in just a few people's heads.

There are others, like infrastructure and dependency debt, but these four cover most of what you will run into.
​

Tools to help you measure

You probably will not run these tools yourself. But knowing they exist helps you ask sharper questions and understand what your engineers show you.

Grouped roughly by what they look at:

Code quality.

Tools like SonarQube scan the codebase for bugs, code smells, and maintainability issues, and can even express debt as an estimated "time to fix." CodeScene takes a different angle, using your version history to find hotspots: the code that is both complex and changed most often.

Security and dependencies.

Tools like Snyk flag known vulnerabilities in your own code and in the open-source libraries you rely on.

Architecture.

Tools like vFunction and CAST analyze the structure and dependencies of larger systems to show where architectural debt is concentrated.

Testing.

Test coverage reports show how much of your code is actually exercised by tests, which is a decent proxy for testing debt.

Production reality.

Monitoring and observability tools (Datadog, New Relic, Grafana) will not say "this is debt," but they show you where debt hurts: errors, slow endpoints, repeat incidents.

Two more low-tech approaches that work surprisingly well:

→ Ask your engineers. A simple session where the team marks the parts of the system that scare them most will surface debt no scanner can. They know where the bodies are buried.

→ Track it in your backlog. Make debt visible. Create tickets for it, label them clearly, and reserve a slice of each sprint to pay some down. Debt you cannot see is debt you will never prioritize.

Quick self-check: how much debt is your product carrying?

No tools needed. Read each statement and tick the ones that sound true for your product right now.

Small changes often set off unexpected changes somewhere else.

→ A routine upgrade or dependency bump turns into a full project.

→ Releases feel risky, and we lean on a lot of manual testing.

→ There are parts of the code the team quietly avoids touching.

→ We get repeat incidents or slow performance that never quite get fixed.

→ Getting data in or out, or integrating with other systems, is painful.

→ New developers take a long time to become productive.

→ If one key person left, a lot of "how it works" would leave with them.

Now count your ticks.

→ 0 to 2: Healthy. Keep an eye on it, but no alarm.

→ 3 to 5: Moderate. Worth putting a plan together before it grows.

→ 6 to 8: High. Time to make the case, and you have the numbers above to do it.

One last thing: look at which statements you ticked. They point to the kind of debt you carry most, whether that is code, architecture, testing, or documentation.

What do you think?

Did this make technical debt feel a little less scary?

Hit reply and let me know — do you love it, hate it, want more of something else?

See you next week,

Maria