Technical debt is often the root cause of unplanned work — and most organizations never measure either one.
At a fintech where I worked, we reduced firefighting daily without understanding where the permanent urgency came from. We knew what to do when an incident hit; we didn't know why it kept returning. The link between technical debt and unplanned work became obvious only when we started measuring both.
At a glance
- Unplanned work will always happen — the key is managing it and understanding its source
- Technical debt drives outages, diverted resources, and refactoring outside original budgets
- Measuring unplanned work is a DevOps prerequisite (aligning development and operations) many organizations still skip
- A single, well-described, prioritized debt backlog changes the conversation
The link between debt and firefighting
Technical debt is often the root cause of unplanned work — whether through a performance failure, an interruption that pulls resources off new features, or refactoring that exceeds the original budget.
The first step is to measure unplanned work. Many organizations don't today, but it's not hard to start:
| Signal to track | What it reveals |
|---|---|
| "Emergency" hours per week | Real volume of firefighting |
| Interruption type (outage, client, internal) | Where debt shows up |
| People pulled in | Real cost beyond hourly rate |
At a 40-person accounting firm, one month of tracking showed 60% of "emergencies" came from the same connector between two systems — a "good enough" compromise from two years earlier, never recorded in the backlog.
"Just good enough" is fine — if you manage the trade-off
In Agile, we often aim for code that's "just good enough" to ship on time. Time and budget are real constraints — as is the need to innovate fast enough to compete.
The issue isn't shipping pragmatic code. It's shipping pragmatic code without recording the debt and planning to pay it back. Every shortcut without a backlog entry becomes a future emergency.
Requirements before test automation
We talk with many organizations worried about defect volume who jump straight to automated testing. Often, closer inspection reveals requirements clarification issues — and improving that reduces defects more than another tool.
The root cause of defects is often poorly defined requirements, not missing test automation. Investing in test automation without clarifying expectations accelerates the production of wrong answers.
Managing technical debt properly
| Practice | Detail |
|---|---|
| Measure | Classify and schedule reduction in your ALM (application lifecycle management) tool |
| Centralize | Maintain debt in a single list |
| Standardize | Describe each item consistently with product impact |
| Prioritize | Continually evaluate priority and effort |
| Communicate | Spread awareness of debt cost to stakeholders |
The answer often lies in measuring unplanned work and improving requirements. In my experience with organizations I've supported, yes — provided you start by measuring rather than buying a tool.
What you can do this week
- Ask the team to log every "urgent" interruption for five business days
- Group by type and identify recurring items
- For each recurring item, ask: "Is this an unpaid past compromise?"
- Add answers to a single debt backlog with clear business impact
These four steps won't fix everything. They create the visibility leadership needs to understand why firefighting persists despite individual effort.
Where you are
Firefighting gave you daily reflexes; here we trace the root cause. Next: The hidden cost of technical debt, to speak about debt in language decision-makers act on.
If unplanned work is consuming your team's capacity, Let's map the cost together — and make it actionable.