By Arjun Mehta
Technical debt is invisible until you track it.
You know debt exists. You feel it. But you can't point to it. You can't measure it. You can't show the business impact.
Without tracking, debt is abstract. With tracking, it becomes real.
What To Track
1. Debt Categories
Not just "debt." Which type?
- Architecture debt
- Testing debt
- Knowledge debt
- Code quality debt
- Dependency debt
- Data model debt
- Process debt
Why? Because you need different strategies for each. Architecture debt needs long-term rework. Testing debt can be tackled incrementally.
2. Debt Location
Which systems have the most debt?
- Payment service: 10 debt items
- Auth service: 5 debt items
- Notification service: 3 debt items
Now you can prioritize. Focus on the payment service. It's your highest-debt system.
3. Debt Impact
How much time does this debt cost? For each debt item, estimate:
- Hours per month this consumes
- Or: % of velocity this impacts
Example: "Monolithic architecture costs 40 hours per month (10% of team time). Poor test coverage costs 30 hours per month (7.5% of team time)."
4. Debt Age
How long has this debt existed? New debt is often acceptable (you took it on to ship fast). Old debt is a problem.
Example: "This architectural constraint has existed for 2 years. It's now costing us significantly. Time to refactor."
5. Debt Ownership
Who's responsible for tracking and reducing this debt? Make it explicit. "Engineering lead owns architecture debt. QA lead owns testing debt."
Without ownership, debt tracking is just an exercise.
How To Track
Option 1: Debt Backlog
Create a "Technical Debt" ticket category. Each debt item is a ticket.
Pros: Visible. Part of your normal workflow. Easy to estimate and prioritize.
Cons: Creates noise in your regular backlog. Can be overwhelming.
Example:
- [DEBT-101] Refactor payment service monolith (Architecture, 200 hours, 2 years old, high impact)
- [DEBT-102] Add unit tests to auth layer (Testing, 40 hours, 1 year old, medium impact)
- [DEBT-103] Distribute knowledge on notification system (Knowledge, 20 hours, 6 months old, medium impact)
Option 2: Debt Dashboard
Create a separate view: total debt by category, debt by system, debt by age.
Pros: High-level visibility. Not mixed with feature work. Can be automated.
Cons: Requires extra tooling. Can be ignored if not integrated into planning.
Option 3: Debt Spreadsheet
Simple spreadsheet: category, system, description, hours/month, age, owner.
Pros: Easy to build. Everyone has Excel.
Cons: Gets stale. Not integrated into planning. Easy to ignore.
Metrics To Track
Debt Hours Per Month
How much time is your team spending on debt per month?
Track over time. Healthy: 5-10% of team hours. Unhealthy: 25%+.
If debt hours are increasing, something is wrong. Debt is accumulating faster than you're paying it down.
Debt Reduction Rate
How fast are you paying down debt?
"We spent 40 hours on debt reduction last month. At this rate, we'll clear all identified debt in 6 months."
That's good visibility.
Velocity vs. Debt Impact
Do your velocity metrics correlate with debt?
"Velocity was 40 points in Q1 (before monolith refactor). It's 50 points in Q3 (after refactor). Debt reduction freed up 25% capacity."
That's the payoff measurement.
Cycle Time Trend
Is your cycle time (time from start to deploy) improving or declining?
Increasing cycle time often indicates growing debt. Decreasing cycle time indicates successful debt reduction.
How To Use These Metrics
Monthly: Check debt hours. Are we staying on track? Is debt accumulating or declining?
Quarterly: Check debt reduction rate. Are we making progress? Adjust strategy if needed.
Semi-annually: Check velocity and cycle time. Are debt reduction efforts translating to higher productivity?
Annually: Quantify ROI. "We invested 200 hours in debt reduction. We freed up 300 hours of productivity. That's a $180K value."
Common Pitfalls
Pitfall 1: Tracking everything. You create 50 debt items. You can't prioritize. You feel overwhelmed.
Better: track top 10-15 debt items. Focus on high-impact debt.
Pitfall 2: Never updating. You create a debt backlog in Q1. By Q4, half the items are already fixed and others have changed.
Review and update quarterly.
Pitfall 3: No ownership. You track debt but nobody owns it. It sits in your backlog forever, ignored.
Assign ownership. Make someone accountable.
Pitfall 4: Tracking without action. You have beautiful debt metrics. You show them in status reports. You do nothing about them.
Tracking is only useful if you act on it. Track to prioritize. Prioritize to fix.
With Glue
With Glue, you can see debt across your codebase automatically. Complexity hotspots. Knowledge silos. Architectural constraints. Instead of manually building a debt tracking system, Glue extracts understanding from your codebase.
You track the data that matters: impact and ownership. Glue provides the visibility.
Frequently Asked Questions
Should debt tracking be in our issue tracking system or separate? Integrated. If it's separate, it gets ignored. Make debt part of your regular planning.
How detailed should debt tickets be? Detailed enough to understand the impact and solution. Not so detailed that maintenance is a burden. 3-5 sentences per ticket.
What if we have too much debt to track? Track the top 20% of debt that's causing 80% of the problems. Ignore the rest. You'll get 80% of the benefit with 20% of the effort.