A 30-Minute Audit for Finding Your Costliest Technical Debt

Look at your last quarter of incidents and emergency fixes, and tag each one by the system or code path it touched. A pattern usually emerges fast: a small number of systems account for a disproportionate share of incidents, and those are your highest-cost debt, whether or not anyone has been vocal about them. This is a better signal than opinion because it's grounded in things that actually happened, not things people worry might happen. If you don't already tag incidents by system, this first pass will be rougher, but even a quick manual read through the last twenty incident summaries usually surfaces the same handful of names.

Pull recent pull request review times and comment counts, filtered by which part of the codebase they touch. A system that reliably generates long review threads and multiple rounds of back-and-forth is one where the code's structure is fighting the reviewer, which is a direct, measurable cost even when nothing has broken in production yet. This surfaces debt that hasn't caused an incident but is still slowing every change down, quietly, in a way that rarely gets raised on its own because no single slow review feels worth complaining about.

Talk to, or pull notes from, whoever onboarded most recently. New engineers hit undocumented, confusing, or fragile parts of the system faster than anyone else, because they don't yet have the tribal knowledge that lets experienced engineers work around the rough edges without noticing them. Their confusion is a leading indicator the rest of the team has stopped seeing, precisely because everyone who could see it clearly has since learned to route around it out of habit.

Sort what you've found by how many other systems or teams depend on the affected code, not by how irritating it is to work in. A messy but isolated internal tool is a lower priority than a merely inconvenient system that sits in the path of every other team's work, even if the isolated tool generates more complaints. Blast radius, not volume of complaint, is what determines actual cost.

Run the audit in these four passes:

1. In the first ten minutes, pull the last quarter of incidents and hotfixes and tag each one by the system it touched.
2. Next, review pull request times and comment counts by area of the codebase to spot code that fights its reviewers.
3. Then ask the most recent hire where they got stuck, since new engineers hit fragile parts first.
4. In the final minutes, rank what you found by how many systems or teams depend on the affected code.

Take the top one or two items and turn them into a scoped remediation plan with a defined outcome, not an open-ended "clean this up" ticket that will lose priority against every feature request that follows it. Debt remediation that competes directly against feature work without a specific scope and owner tends to lose that fight indefinitely, no matter how real the cost is.

A remediation plan is scoped when someone outside the team could tell whether it is finished. For example, instead of a ticket that says clean up the billing service, write that the two modules generating most incidents will be split from the shared code, with the owner, a target date, and the incident count you expect to see fall. Attach the audit evidence so the reason is visible at planning time. A common mistake is bundling several systems into one plan, which makes it easy to defer. Take the top item only, finish it, and let the next audit decide what comes second.

The systems that show up on this list will shift as the product and the team change, and a debt audit done once a year ago is telling you about a codebase that no longer exists in quite the same shape. Keep the underlying data, incidents tagged by system, review times, onboarding notes, flowing continuously so the next audit takes minutes to run rather than requiring the same half hour of manual digging every time. Share the ranked list with the whole team after each run, including engineers who weren't part of producing it, since seeing the evidence tends to land better than being told the conclusion secondhand.