By Arjun Mehta, Principal Engineer at Glue
Technical debt tracking has a dirty secret: most teams are only doing the first 20% of it. They detect debt — running code quality reports, tracking complexity metrics, measuring test coverage. Then they create tickets, do some work, and close those tickets — never confirming whether the underlying codebase condition actually changed.
This is not laziness. It is a tooling gap. The industry has built excellent detection tools and excellent work management tools, but the bridge between them — the verification step that connects resolved tickets back to codebase metrics — is largely missing.
Stage 1: Detection — What Goes Right and Wrong
Detection is the best-developed stage of technical debt management. Static analysis tools, code complexity analyzers, coverage trackers, and dependency auditors are mature and generally reliable. Teams that invest in detection get accurate pictures of where their codebase is unhealthy.
What often goes wrong at the detection stage is not the detection itself — it is the aggregation. A tool reports 847 issues across the codebase. An engineering manager looks at a wall of red and does not know where to start. Without a way to prioritize by business impact — which debt is on critical paths, which modules are single points of failure, which files are owned by people who might leave — detection data becomes noise rather than signal.
Effective technical debt detection is not just about finding problems. It is about finding the right problems to fix next, based on a combination of severity, business impact, and team context. Technical debt visibility at this level requires connecting code metrics to product context — something most pure analysis tools do not do.
Stage 2: Translation — Where Fidelity Gets Lost
Translation is where detected problems become work items. This is where most technical debt management workflows lose critical fidelity.
A static analysis tool detects: "payment-processor.js — cyclomatic complexity 47, 1 author (Jana), last major refactor 3 years ago, touched in 73% of payment-related incidents."
What ends up in Jira: "Refactor payment processor — tech debt."
The specific signals that made this file high priority — the complexity score, the single ownership, the incident correlation — are gone. The engineer who picks up this ticket in sprint planning has no way to know what "done" looks like in terms of the original signals. They will refactor what seems obvious, close the ticket, and the underlying risk might remain fully intact.
Good translation preserves the original signal alongside the work description. The ticket should include: what metric triggered detection, its current value, the target value, and which specific files are affected. Without this, verification in Stage 4 is impossible — you cannot confirm resolution if you do not know what you were measuring.
Stage 3: Work — The Stage That Actually Gets Done
Sprint work is the stage most teams have the clearest visibility into. Jira boards, velocity metrics, burndown charts — the coordination of work is well-supported by existing tooling. Engineers do the refactoring, write the tests, update the dependencies.
The problem in Stage 3 is not visibility into activity; it is the disconnect between activity and intent. Scope drift is endemic to technical debt work. An engineer sets out to improve test coverage in the auth module, discovers the authentication flow is more coupled than expected, spends half the sprint unraveling the coupling, and ends with coverage at 45% instead of the target 70%. The ticket closes because meaningful progress was made — but the original detection threshold has not been cleared.
Without a verification step, this partial resolution looks identical to full resolution in the project management system. Both close as Done. The next health report will catch the difference, but that is weeks away and the signal will be de-contextualized from the sprint work that partially addressed it.
Stage 4: Verification — The Missing Stage
Verification is the stage that closes the loop on technical debt tracking. After sprint work is done, the original detection metrics are re-measured against the same codebase signals that triggered the work. Did the complexity score drop? Did coverage hit the target? Did ownership change?
The reason verification is almost universally skipped is that it requires manually bridging two systems that do not communicate: the codebase analysis tool and the work management system. Nobody owns this bridge. The engineering manager owns the health reports; the sprint team owns the tickets; the connection between them falls into organizational whitespace.
Automating verification requires a platform that maintains the link between detected signals and work items, and re-analyzes the relevant codebase sections after work is marked complete. This is what closed-loop engineering intelligence does — and it is what converts technical debt tracking from a reporting exercise into an operational discipline.
What the Full Lifecycle Looks Like in Practice
A team running the full technical debt lifecycle looks like this: at the start of a quarter, they run a codebase analysis that produces prioritized findings with specific metrics. Each finding is translated into a ticket that preserves the metric, current value, and target. Sprint planning incorporates these tickets alongside feature work with explicit capacity allocation for debt. After each sprint, the system re-analyzes flagged areas and updates each ticket with the final metric value — resolved, partially resolved, or unchanged.
The quarterly review becomes: "Of the 31 issues we flagged, 22 are confirmed resolved (metric cleared threshold), 6 are partially resolved (improving but below threshold, continuing next sprint), and 3 are unchanged (need to understand why)." This is a fundamentally different conversation than reviewing a list of closed tickets.
Teams operating at this level stop running the same debt reports quarter after quarter and watching the numbers barely move. See the full use case in Track Technical Debt From Detection to Verified Resolution.
FAQ
What is the biggest gap in most technical debt tracking workflows?
The verification step. Most teams detect debt, create tickets, and do work — but never confirm that the work actually resolved the underlying codebase condition. Tickets close, but the original detection metric is never re-measured. Teams can spend quarters on debt work without codebase health metrics meaningfully improving.
How should a technical debt ticket be written to support verification?
Include four elements: the specific codebase signal that triggered the ticket, the current metric value at detection time, the target value that defines resolution, and the specific files or modules affected. This makes post-sprint verification straightforward — re-measure the metric in those files and compare to the target.
How often should teams run technical debt verification?
Verification should happen at the end of every sprint that included debt work — not quarterly. Quarterly verification creates a four-week delay between action and feedback, making it impossible to course-correct within the same sprint cycle. Sprint-level verification keeps the feedback loop tight and allows teams to catch partial resolutions before the problem drifts out of context.