Standard : Technical debt is actively reduced over time
Purpose and Strategic Importance
This standard ensures technical debt is actively identified, prioritised, and reduced over time, preventing drag on delivery, quality, and morale. It promotes sustainable engineering practices and long-term team health.
Aligned to our "Balance Sustainability with Speed" and "Eliminate Waste" policies, this standard safeguards system maintainability and developer productivity. Without it, teams struggle with friction, compounding rework, and delivery risk.
Strategic Impact
- Improved delivery speed, predictability, and team satisfaction
- Reduced rework, bugs, and release failures
- Increased trust in codebases and platform stability
- Accelerated onboarding and easier scaling of teams
Risks of Not Having This Standard
- Invisible accumulation of code complexity and architectural erosion
- Rising maintenance costs and frequent firefighting
- Reduced development speed and innovation capacity
- Frustration, low morale, and staff attrition
- Difficulty in responding to business change or scaling solutions
CMMI Maturity Model
Level 1 – Initial
| Category |
Description |
| People & Culture |
Technical debt is tolerated or ignored. |
| Process & Governance |
There are no mechanisms to track or prioritise debt. |
| Technology & Tools |
No tooling is used to detect or manage debt. |
| Measurement & Metrics |
No visibility into debt or its impact on delivery. |
Level 2 – Managed
| Category |
Description |
| People & Culture |
Some engineers log known debt, but follow-through is ad hoc. |
| Process & Governance |
Debt is occasionally included in backlogs, usually during fire-fighting. |
| Technology & Tools |
Basic static analysis tools may be used. |
| Measurement & Metrics |
Anecdotal tracking of time spent on cleanup or workaround fixes. |
Level 3 – Defined
| Category |
Description |
| People & Culture |
Debt is openly discussed and addressed in planning. |
| Process & Governance |
Clear prioritisation criteria and time allocation for remediation exist. |
| Technology & Tools |
Tooling highlights key debt indicators and supports regular review. |
| Measurement & Metrics |
Debt backlog is tracked and tied to product outcomes. |
Level 4 – Quantitatively Managed
| Category |
Description |
| People & Culture |
Teams proactively refactor and maintain technical hygiene. |
| Process & Governance |
Time is budgeted for remediation in sprint or release cycles. |
| Technology & Tools |
Debt trends and hotspots are monitored automatically. |
| Measurement & Metrics |
Debt reduction rate and impact on cycle time, quality, and throughput are measured. |
Level 5 – Optimising
| Category |
Description |
| People & Culture |
Debt prevention is a shared mindset; teams invest in code health. |
| Process & Governance |
Practices and incentives reinforce continuous debt reduction. |
| Technology & Tools |
Tools support debt forecasting, decision-making, and mitigation at scale. |
| Measurement & Metrics |
Technical debt is part of engineering KPIs and used in strategic planning. |
Key Measures
- % of sprint effort dedicated to technical debt reduction
- Change failure rate and rework due to unmanaged debt
- Mean time to remediate critical debt
- Debt backlog trend (e.g. story points, complexity, risk level)
- Improvement in system health, code quality, or deployment metrics over time