Technical debt is invisible by default because most organizations track it through qualitative labels ("the auth module is a mess") rather than quantitative signals. Making technical debt visible requires measuring three dimensions: complexity metrics per module (cyclomatic complexity, coupling), velocity impact (how much longer do changes take in high-debt areas vs. clean areas), and operational cost (incident frequency, change failure rate per module). The implementation timeline is approximately five months: month one maps modules to business impact, month two instruments velocity tracking, months three and four add operational metrics, and month five correlates debt with business outcomes to build the ROI case for remediation.
At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
I sat in a quarterly planning session last year where my lead engineer said "We need a tech debt quarter."
I said "What do we need to fix?"
He said "The auth module. It's a mess."
I said "What does that cost us?"
He said "I don't know. It's just... hard to work in."
And that's where the conversation died. Because I couldn't ask "Is this the most important thing to fix?" when I had no idea what "fixing it" meant or what it would actually give us.
He wasn't being evasive. There's just no language for it. "We have debt" is a feeling. "Here's what debt we have, what it costs, and what fixing it delivers" is a measurement.
The Problem: Debt Visibility is Zero by Default
Engineering teams live with technical debt every day. They feel it when they're making a change and it takes three times longer because some module is a nightmare. They feel it in code review when they have to implement a workaround because the core system isn't flexible. They feel it in production when a simple feature request leads to a week of refactoring work.
But from a product perspective? It's invisible.
I don't see the complexity cost. I don't see which parts of the system are bleeding into every new feature. I don't see how much slower we are because of deferred decisions made two years ago.
So when engineering asks for space to fix technical debt, it looks like "give us time to work on old code." And from a product perspective, that seems like the lowest priority thing we could do.
The engineer knows we're slower because of the debt. The PM doesn't. That's a visibility problem, not a prioritization problem.
What Good Debt Visibility Looks Like
I've talked to teams that have cracked this, and they measure three categories of debt:
1. Code Complexity and Structure Debt
This is the "the auth module is a mess" problem, except you measure it.
You can track:
- Cyclomatic complexity (how many decision paths does this code have?)
- File size and function size (are things organized into sensible units?)
- Dependency tangles (does this module depend on seventeen other modules?)
- Test coverage (can you change this code without fear?)
You don't need perfection. You need consistency. "Our average cyclomatic complexity is 8. The auth module is 34. That's a 4x complexity premium."
Now we can talk about it. Is that premium worth it? Sometimes yes (we built it for flexibility). Sometimes no (it evolved without intention). But we can decide.
2. Process Debt - How Long Does It Take to Understand Something?
This is my favorite metric because it directly affects product velocity.
Pick a module. Ask a junior engineer to understand how it works and time how long it takes. Do the same with a senior engineer. Now you have a baseline.
"It takes a junior engineer 6 hours to understand the payment retry logic. A senior engineer can do it in 45 minutes."
That gap is process debt. It means there's institutional knowledge locked in someone's head. It means onboarding is slower. It means bug fixes take longer than they should.
You can measure this for anything: "How long does it take to add a new payment method?" "How long to understand why this edge case exists?" "How long to trace a customer issue through the system?"
High time = high debt.
3. Change Failure Rate and Rework
This is the most predictive metric I've found: when you deploy a change, how often does it need to be reverted or hotfixed?
High change failure rates aren't usually about careless engineering. They're about code you can't modify safely. Code with no tests. Code with hidden dependencies. Code where changing one thing breaks something else.
It's direct technical debt measurement. "Changes to the checkout flow have a 15% failure rate. Changes to the new payment module have a 2% failure rate."
That 13% difference is debt. It's costing you deploys, hotfixes, and customer goodwill.
How To Use These Measurements
Once you have these numbers, the conversation changes.
Instead of "We need a tech debt quarter," it becomes:
"Our auth module is 4x more complex than the average module. That's why changes take longer there. We have two options:
Option A: Leave it as is. Cost is 20% of every auth - related sprint gets spent fighting complexity. Benefit is we don't spend time refactoring.
Option B: Spend 3 weeks simplifying the module. Benefit is future auth features probably run 30 - 40% faster. Cost is we pause other features for 3 weeks."
Now I can evaluate it. Maybe the auth module is stable and we don't touch it much - then the complexity doesn't hurt us. Maybe we're adding auth features every sprint - then simplifying has real ROI.
The point is: it's measurable. It's a trade - off, not a plea.
The Stakeholder Conversation
PMs hate saying "no" to feature requests. But we hate it less when we have numbers.
Right now, if engineering says "the checkout system is slow because of technical debt," I have to take their word for it or run a survey. With measurements, I can say:
"I see that the checkout module has a 22% change failure rate. That means for every 10 deploys, 2 get reverted or hotfixed. Last quarter that happened 8 times, costing us about 2 weeks of unplanned work. Here's what I propose we fix and when."
Now the stakeholders aren't arguing about philosophy. They're looking at the cost of NOT fixing it.
The Visibility Paradox
Here's the thing: once you make debt visible, it usually gets worse before it gets better.
You measure complexity and realize it's worse than you thought. You track change failure rates and see they're causing 10% loss of capacity. You time how long it takes to understand a system and the number is shocking.
That feels bad. But it's actually good. Because now you can decide.
Right now, technical debt is like unrecorded expenses. You know something's costing you, but you don't know what. The moment you record it, it looks bad. But it's not bad - it's real.
What Tools Help
You can build this in spreadsheets, but the tools matter. You need:
- Static analysis that measures complexity in your codebases
- Monitoring that tracks change failure rates (how many deployments got reverted?)
- Time tracking or survey data that shows how long it takes to make common changes
- A way to present these metrics to non - engineers so they mean something
Most teams I know start with metrics within their CI/CD system - code coverage reports, complexity analysis, deployment success rates. Then they add the human measurement - "how long did onboarding take this new engineer?"
The Timeline
This doesn't fix overnight. But the timeline is:
Month 1: Pick one area to measure. Establish baseline metrics. Month 2 - 3: Collect 2 - 3 cycles of data. Get consensus on where the debt hurts most. Month 4: Make the trade - off decision. Fix the high - impact debt or live with it deliberately. Month 5+: Measure again. Did fixing the debt actually make things faster?
The last part is important. Sometimes you fix debt and nothing changes (because that part of the codebase wasn't actually slowing you down). Sometimes you fix it and you're 30% faster on that type of change.
Either way, you know. And you can make better decisions next time.
Frequently Asked Questions
Q: Don't we already know which parts are messy?
A: Engineers do. PMs usually don't. And even engineers have blind spots - they might think the payment module is the worst when it's actually the user authentication system that's slower to change. Measurement removes opinion. Code quality metrics give you the data to settle debates about where debt actually lives.
Q: Won't measuring debt mean we have to fix all of it?
A: No. Measurement is the prerequisite to prioritization, not a commitment to fix everything. Some debt is low - cost (the checkout system is messy but changes rarely) and some is high - cost (the auth module is messy and we touch it every sprint). You can decide to live with low - cost debt.
Q: Where do I start if we have no metrics?
A: Pick the system where technical debt hurt you most last quarter. Maybe it's the module where you had to do an emergency refactoring. Maybe it's where the last 5 bugs came from. Make that one visible — measure its complexity, track how long changes take, measure change failure rate. Use engineering efficiency metrics to build the business case. Once you have real numbers, you can make a case for fixing it or living with it.
Related Reading
- Technical Debt: The Complete Guide for Engineering Leaders
- Code Refactoring: The Complete Guide to Improving Your Codebase
- DORA Metrics: The Complete Guide for Engineering Leaders
- Software Productivity: What It Really Means and How to Measure It
- Code Quality Metrics: What Actually Matters
- Cycle Time: Definition, Formula, and Why It Matters
- Technical Debt Metrics: How to Measure and Track Tech Debt
- Technical Debt Tracking - Full Lifecycle
- What Is Technical Debt Assessment?
- What Is Technical Debt Reporting?
- Technical Debt Lifecycle