Technical Debt Management¶
Status: 🟢 Active | Owner: Engineering Enablement | Last Reviewed: 2025-Q4
Introduction¶
Technical debt is not a failure — it is a natural consequence of building software under time and information constraints. Prudent technical debt — a deliberate shortcut taken to meet a deadline, with the intention and plan to address it later — is a legitimate engineering trade-off. Reckless debt — shortcuts taken without awareness, without documentation, or without any intention to address them — compounds silently until it becomes a reliability and security liability.
The goal of technical debt management is not to eliminate debt entirely. It is to keep debt visible, classified, tracked, and actively reduced so that it never becomes a blocker to delivering business value or operating safely.
The Debt Budget¶
Every squad allocates 20% of sprint capacity to technical debt resolution as a standing commitment. This is reviewed quarterly. Teams falling below 15% must justify the deviation in sprint planning; deviation must be approved by the Engineering Manager.
The debt budget is not optional. Deferring debt work indefinitely to maximise feature velocity is a short-term optimisation with long-term compounding costs. EMs who consistently deprioritise debt resolution will see the impact in reliability incidents, onboarding time, and feature delivery slowdown within 2–3 quarters.
Debt Categories¶
| Category | Description | Examples | Risk if Neglected |
|---|---|---|---|
| Code Debt | Poor code quality, duplication, excessive complexity | God classes, copy-pasted logic, cyclomatic complexity >15 | Slower delivery, higher defect rate |
| Design Debt | Architectural decisions that no longer fit | Wrong service boundaries, anemic domain models, missing abstraction layers | Change amplification, coupling failures |
| Infrastructure Debt | Outdated platforms, EOL runtimes, unpatched systems | Java 11, Python 3.8, unpatched AMIs | Security vulnerabilities, unsupported failure modes |
| Test Debt | Missing, inadequate, or unreliable tests | Coverage gaps in critical paths, flaky E2E suite | Reduced deployment confidence, production incidents |
| Documentation Debt | Missing or stale runbooks, READMEs, ADRs | Runbook not updated after architecture change | Longer incident resolution, slower onboarding |
| Dependency Debt | Outdated, vulnerable, or abandoned third-party libraries | Dependencies with known CVEs, unmaintained packages | Security exposure, compatibility failures |
Separation of Responsibilities¶
| Role | Responsibility |
|---|---|
| Engineer | Identify and log debt during feature work; address debt items in sprint |
| Tech Lead | Triage debt backlog weekly; escalate high-risk items; ensure debt is considered in design decisions |
| Engineering Manager | Protect the 20% debt budget in sprint planning; escalate systemic debt to leadership |
| Engineering Enablement | Maintain the taxonomy, tooling, and reporting infrastructure for debt tracking |
| EAB / Architecture Team | Review and prioritise design debt that has cross-team implications |
Debt is never owned by a single engineer. It is owned by the squad. When the engineer who created a debt item leaves the team, the squad inherits ownership of that item — debt does not become orphaned.
What You Will Find Here¶
| Page | Intent |
|---|---|
| Identifying & Classifying Debt | Debt taxonomy, classification criteria, identification sources |
| Debt Logging & Tracking | Jira ticket requirements, the 20% rule, review cadence |
| Refactoring Strategies | Safe refactoring techniques, Strangler Fig, Branch by Abstraction |
| Deprecation & Sunsetting Policy | Process and timelines for retiring technologies, APIs, and libraries |
Last reviewed: 2025-Q4 | Owner: Engineering Enablement