Every engineering team has technical debt. The healthy ones manage it deliberately. The unhealthy ones pretend it doesn't exist — until velocity grinds to a halt, incidents spike, and the best engineers leave for companies where they can actually build things.
Technical debt is not a moral failing. It's a natural consequence of building software under real-world constraints. The problem is never the existence of debt — it's the absence of a strategy for managing it.
Types of Technical Debt
The Debt Quadrant
| Prudent | Reckless | |
|---|---|---|
| Deliberate | "We know this isn't ideal, but we need to ship for the deadline. We'll address it next sprint." | "We don't have time for design. Just ship it." |
| Accidental | "Now that we understand the domain better, we realise our original design is suboptimal." | "What's a design pattern?" |
Prudent deliberate debt is healthy. You make a conscious trade-off, document it, and plan to address it. This is engineering pragmatism.
Reckless deliberate debt is dangerous. It's a shortcut taken without understanding the consequences, usually driven by pressure without pushback.
Prudent accidental debt is inevitable. As you learn more about your domain, earlier decisions look suboptimal. This is the cost of building in an uncertain environment.
Reckless accidental debt is a skills problem. It happens when the team lacks the knowledge to make good design decisions.
Common Forms
| Debt Type | Symptoms | Impact |
|---|---|---|
| Architecture debt | Monolithic coupling, wrong service boundaries, missing abstractions | Feature velocity drops, cascading failures |
| Code debt | Duplicated code, unclear naming, missing tests, god objects | Bugs, slow development, knowledge silos |
| Infrastructure debt | Manual deployments, outdated dependencies, unpatched systems | Security vulnerabilities, reliability issues |
| Documentation debt | Missing or outdated docs, tribal knowledge | Slow onboarding, bus factor risk |
| Test debt | Low coverage, flaky tests, missing integration tests | Bugs escape to production, fear of change |
| Dependency debt | Outdated libraries, unsupported frameworks | Security vulnerabilities, compatibility issues |
Quantifying Debt
Objective Metrics
| Metric | Tool | What It Tells You |
|---|---|---|
| Code complexity (cyclomatic) | SonarQube, CodeClimate | Where code is hardest to change |
| Test coverage | Coverage tools | Where untested code lives |
| Dependency age | Dependabot, Renovate | How outdated your dependencies are |
| Build time | CI/CD metrics | Infrastructure debt signal |
| Deployment frequency | DORA metrics | Overall health indicator |
| Bug density | Issue tracker | Where quality is poorest |
| Code churn | Git analytics | Files changed most often (hotspots) |
Subjective Signals
| Signal | How to Collect | What It Means |
|---|---|---|
| Developer friction survey | Quarterly survey | Where developers waste time |
| "Areas of the codebase you dread touching" | Team discussion | Highest-risk technical debt |
| Onboarding time | Track for new hires | Documentation and code clarity debt |
| Incident post-mortems | Incident reviews | Debt that causes real outages |
The Technical Debt Ratio
Technical Debt Ratio = (Cost to fix all identified debt) / (Cost to rebuild from scratch)
This gives a single number that executives can understand. A TDR above 20% is concerning. Above 40% is critical.
Translating to business language: "Our technical debt represents approximately 6 months of engineering capacity. At our current burn rate, that's $X. Every month we don't address it, it grows by Y%, which means features take Z% longer to deliver."
The Debt Register
Maintain a living document of known technical debt:
| ID | Description | Type | Impact (1-5) | Effort (S/M/L) | Risk (1-5) | Priority Score | Status |
|---|---|---|---|---|---|---|---|
| TD-001 | Payment service tightly coupled to order service | Architecture | 4 | L | 4 | 16 | Planned |
| TD-002 | No integration tests for checkout flow | Test | 3 | M | 3 | 9 | Backlog |
| TD-003 | jQuery dependency in admin panel | Dependency | 2 | M | 2 | 4 | Backlog |
Priority Score = Impact × Risk. This formula naturally prioritises high-impact, high-risk debt.
The Allocation Strategy
The 20% Rule
Allocate 20% of engineering capacity to technical debt reduction. This is the most common approach and works well for steady-state debt management.
How to implement: In each sprint, 20% of story points (or capacity) is reserved for debt items from the debt register. The team selects the highest-priority items.
Debt Sprints
Dedicate full sprints to technical debt every 4-6 sprints. The entire team focuses on debt reduction for 1-2 weeks.
When it works: When debt has accumulated to the point where incremental 20% allocation isn't enough. Good for concentrated efforts like dependency upgrades, test coverage improvements, or architecture refactoring.
The Boy Scout Rule
"Leave the code better than you found it." Every PR that touches a file should make a small improvement — rename a confusing variable, add a missing test, remove dead code.
When it works: For code-level debt. Not sufficient for architecture or infrastructure debt that requires focused effort.
Debt-Driven Development
When building a new feature, first fix the debt in the area you're working in, then build the feature on a clean foundation.
When it works: When debt is concentrated in specific areas. Ties debt reduction to feature delivery, making it easier to justify.
Communicating to Stakeholders
Language That Works
Don't say: "We need to refactor the authentication module."
Do say: "The authentication system takes 3 weeks to add a new login method. After modernisation, it will take 2 days. This directly affects our ability to support enterprise SSO, which is blocking $2M in pipeline."
Framing
- Cost of delay: "Every month we delay, the debt compounds. Features that cost X today will cost 2X in 6 months."
- Risk: "The payment system has no automated tests. Our next change has a 30% chance of causing a billing incident."
- Competitive disadvantage: "We ship quarterly. Our competitors ship weekly. The difference is technical debt."
Preventing Future Debt
- Architecture Decision Records (ADRs): Document significant decisions, including trade-offs and accepted debt
- Code review standards: Enforce quality standards that prevent reckless debt
- Definition of Done: Include "no new technical debt without a backlog item" in your DoD
- Regular assessment: Quarterly review of the debt register and debt metrics
- Retrospectives: Include "what debt did we create this sprint?" as a standing agenda item
Technical debt management is a core CTO responsibility. If your technical debt is slowing you down and you need a strategy for paying it off, let's talk.