Managing Technical Debt: The Engineering Leader's Playbook

Technical debt is the difference between the software you have and the software you would build if you knew then what you know now. It is not inherently bad—strategic shortcuts to meet a deadline, taken consciously, can be the right business decision. Unacknowledged, untracked, and unmanaged technical debt is what destroys engineering velocity.

Classifying Technical Debt

Intentional debt: Known shortcuts taken for business reasons. These must be documented, estimated, and scheduled for repayment.

Unintentional debt: Design flaws discovered after the fact. Identified through code reviews, incident post-mortems, and refactoring friction.

Bit rot: Code that was correct when written but has become problematic due to external changes—upgraded dependencies, changed business requirements, accumulated code around it.

The Measurement Problem

You cannot manage what you cannot measure. Useful debt metrics:

• Change failure rate: If deployments frequently cause incidents, debt is likely the cause
• Lead time for changes: Increasing lead time despite stable team size signals growing debt
• Code complexity metrics: Cyclomatic complexity, coupling, test coverage trends
• Developer surveys: Engineers know where the swamps are—ask them regularly

The Prioritisation Framework

Not all debt is equal. Prioritise based on:

1. 1Impact on delivery velocity: Debt in the critical path of new feature development
2. 2Risk: Debt in security-sensitive or high-availability components
3. 3Blast radius: How much code depends on this? Fixing it fixes everything downstream.

The 20% Rule

High-performing engineering teams allocate 15–20% of every sprint to debt reduction. This is not a luxury—it is infrastructure maintenance that prevents the velocity decay that eventually makes teams non-functional.

Communicating Debt to Business Stakeholders

Frame debt in business terms: "This component takes 3x as long to change as it should. Over the next year, that costs approximately X engineer-weeks. Investing Y engineer-weeks now to refactor it pays back in Z months."