# Technical Debt Management: A Pragmatic Strategy for Development Teams > McKinsey found technical debt accounts for 40% of IT balance sheets and causes teams to be 30% slower. Here's a practical framework for identifying, prioritizing, and systematically reducing technical debt without stalling feature work. URL: https://www.matthewswong.com/en/blog/technical-debt-management/ - Author: Matthews Wong (https://www.matthewswong.com/en/about/) - Published: 2025-06-10 - Updated: 2026-10-17 - Category: Career McKinsey found that technical debt accounts for 40% of IT balance sheets, and companies with the highest debt ratios experienced 20% lower revenue growth than those with managed debt. Developers spend 33% of their time on technical debt — maintaining legacy code, debugging ancient systems, and refactoring shortcuts that made sense three years ago but now slow everything down. Yet most teams have no systematic approach to managing it. Debt accumulates invisibly until a major feature becomes a three-week ordeal because everything it touches is fragile. This guide is my practical approach — the same framework I use when inheriting a codebase or reviewing the architecture of a system that's grown beyond its original design. ## What Technical Debt Actually Is Ward Cunningham coined the technical debt metaphor in 1992: choosing a simpler implementation now creates debt that must be paid later (with interest). Like financial debt, some technical debt is strategic — you knowingly take a shortcut to ship faster, with a plan to refactor later. Reckless debt is the problem — shortcuts taken without awareness that create ongoing maintenance cost. Distinguish between the two: strategic debt is tracked, planned, and paid back. Reckless debt is discovered when it's already slowing you down or causing bugs. The goal of debt management is not to eliminate all debt but to maintain it at a level where it doesn't compound faster than you're paying it down. ### Types of Technical Debt to Track Debt comes in several forms: Code debt (spaghetti logic, missing tests, copy-pasted code), Architecture debt (a design that made sense for 1,000 users but breaks at 100,000), Dependency debt (outdated libraries with known vulnerabilities or breaking API changes), Documentation debt (code that works but nobody knows how or why), and Operational debt (manual processes that could be automated, lack of monitoring, missing alerts). Each type has a different remediation strategy and a different cost-of-delay. > For maintaining an ERP codebase: create a 'debt register' — a simple spreadsheet or Jira epic that lists known debt items, their estimated remediation effort, and their estimated impact on development velocity if unaddressed. Review it quarterly. This turns invisible debt into visible, prioritizable work. The discipline of writing it down forces you to articulate why something is debt and what the actual cost is — which often reveals that some 'debt' is just code you don't like, not code that's actually slowing you down. ## Measuring the Real Cost of Debt Debt is expensive in three ways: (1) slow down — features that touch debt-heavy code take 2-3x longer to implement and test; (2) defect amplification — buggy, fragile code produces more defects per feature, which require investigation and hotfix cycles; (3) developer attrition — engineers who spend their days fighting legacy code burn out and leave. Estimate the cost by measuring: average time to implement a feature in a debt-heavy area vs. a clean area; defect rate per feature in high-debt vs. low-debt code; and engineer sentiment in retros when debt-heavy areas come up. These numbers build the case for scheduled debt reduction. ### The 20% Rule and Budgeting for Debt Allocate 15-20% of every sprint to debt reduction — not as leftover time, but as explicit capacity budgeted upfront. This is the McKinsey-recommended allocation for systematic debt reduction. Without explicit allocation, debt work never happens because features always feel more urgent. Frame it to stakeholders: 'We're spending 15% of capacity on technical investment that keeps our delivery velocity high and prevents the kind of debt accumulation that causes outages and slows features.' Productivity gains from debt reduction (faster feature delivery, fewer bugs) typically pay back the investment within 2-3 months. > **Refactoring without tests is debt creation, not debt reduction** > The most dangerous technical debt pattern: a developer rewrites a module 'to clean it up' without any tests covering the existing behavior. The rewrite may look cleaner but introduces subtle behavioral regressions that only surface in production. Before refactoring any significant module, write characterization tests first — tests that document what the existing code does (not what it should do). Run them on the old code to confirm they pass. Then refactor until the same tests pass on the new code. This is the only safe path for legacy code without existing tests. ## Prioritizing Debt: The Two-Axis Framework Not all debt is equal. Prioritize by two dimensions: (1) Impact — how much is this debt slowing down current and planned work? High-traffic code paths (authentication, billing, the core domain model) accumulate more interest than rarely-touched utilities. (2) Remediation cost — how long will fixing this take? A two-hour refactor that removes a recurring stumbling block is obviously worth it. A three-month rewrite for a stable component nobody touches needs a stronger case. Use a 2x2 matrix: high impact + low cost → do next sprint; high impact + high cost → schedule as a project; low impact + low cost → fix opportunistically; low impact + high cost → accept and document. ## Making Debt Reduction Sustainable Debt reduction fails when it's treated as a special project that happens 'when we have time' — which is never. Make it sustainable: include it in sprint capacity (the 20% rule). Give engineers autonomy to fix small debt items opportunistically when they're in a file anyway (the Boy Scout Rule: leave the code cleaner than you found it). Celebrate debt reduction wins in retros — a refactor that cut a module's complexity by 40% is worth celebrating. Track debt metrics over time (average PR cycle time in debt-heavy areas, defect rate) so improvement is visible and motivating. ## When to Accept Debt and Move On Not all debt needs to be paid. A stable, rarely-touched module with comprehensive tests is fine to leave as-is even if the code style is old. A backend service that's scheduled for replacement in six months doesn't need a major refactor. Debt in code that's going to be deleted is best managed by deleting it faster, not cleaning it up first. Apply the economic lens: will the cost of remediation be recovered in saved time before this code is replaced or deprecated? If yes, fix it. If no, document it and move on. Technical debt management is resource allocation, not perfectionism. ## Sources & Further Reading - McKinsey — Breaking Technical Debt's Vicious Cycle - vFunction — How to Manage Technical Debt in 2025 - byteiota — Technical Debt Costs 40% of IT Budgets in 2025 ## Source links - https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business - https://vfunction.com/blog/how-to-manage-technical-debt/ - https://byteiota.com/technical-debt-costs-40-of-it-budgets-in-2025-the-3m-crisis/ ## FAQ ### What is a 'debt register' and why should teams maintain one? A debt register is a simple spreadsheet or Jira epic that lists known technical debt items along with their estimated remediation effort and projected impact on development velocity if left unaddressed. The post recommends reviewing it quarterly. Writing debt down forces teams to articulate the actual cost of each item, which often reveals that some perceived 'debt' is merely code people dislike rather than code that genuinely slows delivery. ### How much sprint capacity should be budgeted for technical debt reduction? The post recommends allocating 15–20% of every sprint explicitly to debt reduction — not as leftover time, but as capacity budgeted upfront. This follows McKinsey's recommended allocation for systematic debt reduction. Without this explicit budget, feature work always feels more urgent and debt reduction never happens. Productivity gains typically pay back the investment within 2–3 months through faster feature delivery and fewer defects. ### Why is refactoring without tests considered debt creation rather than debt reduction? When a developer rewrites a module without tests covering existing behavior, the rewrite may look cleaner but can introduce subtle behavioral regressions that only surface in production. The post prescribes writing characterization tests first — tests that document what the existing code actually does — running them against the old code, then refactoring until the same tests pass on the new code. This is described as the only safe path for legacy code that lacks existing test coverage. ### How should teams prioritize which technical debt to address first? The post recommends a two-axis framework based on impact (how much the debt slows current and planned work) and remediation cost (how long fixing it will take). This produces a 2x2 matrix: high-impact, low-cost items should be done next sprint; high-impact, high-cost items scheduled as projects; low-impact, low-cost items fixed opportunistically; and low-impact, high-cost items accepted and documented rather than remediated. ### When is it acceptable to leave technical debt unaddressed? The post applies an economic lens: if the cost of remediation will not be recovered in saved time before the code is replaced or deprecated, the debt should be documented and left alone. Stable, rarely-touched modules with comprehensive tests are fine to leave as-is even if their code style is dated, and backend services scheduled for replacement within six months do not warrant a major refactor. Debt in code that will be deleted is best managed by deleting it faster, not cleaning it up first. --- - HTML version: https://www.matthewswong.com/en/blog/technical-debt-management/ - Bahasa Indonesia: https://www.matthewswong.com/id/blog/technical-debt-management/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json