Technical debt is often the root cause of unplanned work — and most organizations never measure either one.
At a fintech where I worked, we were working to reduce firefighting — unplanned work — on a daily basis. We understood it was hurting us and that it would always be a constant battle no matter how we organized our workload.
I wrote earlier about firefighting and the importance of managing unplanned work. At the time, I didn't fully grasp the root cause. I knew what to do when emergencies happened — but not where they were coming from. Reading industry research connected the dots: technical debt drives unplanned work, whether through performance failures, diverted feature work, or refactoring that falls outside original budgets.
At a glance
- Unplanned work will always happen — your ability to handle it properly is key to sustainable delivery.
- Technical debt is often the hidden source: system failures, diverted resources, and "just good enough" code without a payback plan.
- Poor requirements elicitation — not missing test automation — is frequently the root cause of defect volume.
- Manage debt in a single, prioritized backlog with consistent descriptions and visible business impact.
The link between debt and firefighting
Technical debt is often the root cause of unplanned work whether it's a system performance issue or failure that has demanded attention away from resources assigned to new features, or refactoring of code outside the project's original time and budget constraints.
The first step to understanding the impact is to measure the unplanned work — metrics being a fundamental DevOps concept. Many organizations don't do this today, but it's not difficult to start.
"Just good enough" is fine — if you manage the trade-off
It's arguable whether it's ever possible to fully eliminate technical debt, particularly when we're doing Agile. We often work toward models where the developed code is 'Just Good Enough'.
We might want code that is excellent, or perfect, but time and budget are constraints too — as is the need to get innovation to market fast enough to win or compete.
The problem isn't shipping pragmatic code. It's shipping pragmatic code without recording the debt and planning to pay it back.
Requirements before test automation
We speak with a lot of organisations concerned about defect volume who jump to automated testing. Often, upon closer inspection, issues around requirements elicitation are the root cause — poorly defined requirements produce defects that look like code problems.
Could salvation be in measuring unplanned work and improving how requirements are captured? In my experience, yes — often more than buying another tool.
Practical takeaways
- Unplanned work will always happen no matter how you organize your workload
- Your ability to handle unplanned work properly is key to success — see how to reduce firefighting
- The source of unplanned work is directly related to technical debt
- Technical debt grows when requirements are poorly defined
- Accept that code will sometimes be "Just Good Enough" — but manage that debt in the backlog
- Maintain technical debt in a single list
- Describe debt items consistently — clear impact on the product
- Continually evaluate priority and effort
- Spread awareness about the cost of technical debt
Related on this site
If unplanned work is consuming your team's capacity, let's talk about making the cost visible — and actionable.