"How much technical debt do we have?"
It sounds like an important question. It is usually too vague to be useful.
Every mature system contains compromises, outdated choices, imperfect abstractions and code that could be improved. Not all of it deserves action.
Technical debt becomes strategically important when it changes the economics or feasibility of a business decision.
The useful question is therefore:
Which parts of the system constrain our ability to change, operate, secure or grow?
That turns technical debt from a moral judgment about code quality into a decision problem.
Debt Is a Metaphor for Consequence
The debt metaphor is useful because it separates two things:
- taking a shortcut;
- paying the ongoing consequence of the shortcut.
A shortcut can be rational.
A startup may choose a single database because it reduces delivery time. A team may accept manual deployment during an early prototype. A company may integrate a vendor directly instead of building an abstraction because market timing matters more than portability.
The decision becomes problematic when the organization forgets the consequence.
Debt is not "bad code."
Debt is a structural choice whose future carrying cost matters.
The Interest Appears as Cost of Change
Technical debt often becomes visible through friction.
A small feature requires changes across many modules. Releases require large regression cycles. Engineers are afraid to touch a subsystem. A dependency upgrade takes months. An integration cannot be changed without customer downtime.
The interest payment appears as increased cost of change.
Useful indicators include:
- lead time for changes;
- coordination required per release;
- defect rate in a subsystem;
- rollback difficulty;
- time to diagnose incidents;
- frequency of emergency work;
- onboarding time;
- dependency on rare specialists;
- test duration;
- manual release effort.
The code may still "work."
The business is paying through slower and riskier change.
Some Debt Affects Reliability
Debt can also create operational constraints.
Examples include:
- insufficient observability;
- shared failure domains;
- manual recovery steps;
- fragile scheduled jobs;
- weak retry behavior;
- inconsistent configuration;
- untested backups;
- hidden resource limits.
These do not necessarily slow feature development every day. They change the expected cost of failure.
A system with recurring out-of-memory events may still deliver features quickly until capacity pressure creates a production incident. At that point, previously invisible debt becomes business interruption.
Reliability debt matters when the organization is accepting operational risk without consciously pricing it.
Security Debt Has a Different Risk Curve
Some debt compounds gradually. Security debt can create discontinuous consequences.
An obsolete dependency may appear harmless for years and then become a critical vulnerability.
An overly broad permission model may be operationally convenient until a compromised account exposes data across tenants.
A missing audit trail may not matter until the organization needs to reconstruct a regulated action.
This makes prioritization harder.
Teams should not treat all security debt as urgent, but they should evaluate exposure, likelihood, impact and compensating controls rather than ranking it with ordinary refactoring work.
The decision model needs to reflect consequence, not developer annoyance.
Cognitive Load Is an Economic Cost
Some systems are difficult not because any individual component is broken, but because understanding the system requires too much context.
A developer making a small change may need to understand several services, deployment processes, undocumented data flows and team conventions.
That cognitive load increases:
- onboarding time;
- review effort;
- defect probability;
- dependence on experienced individuals;
- hesitation to change unfamiliar areas.
DORA's research on loosely coupled teams connects technical and organizational architecture to delivery performance. Teams are more capable of continuous delivery when they can make, test and deploy changes with less external coordination.
This is an important way to think about debt.
A technical structure that requires constant coordination is creating an organizational cost.
Debt Can Exist in Data, Infrastructure and Vendors
Code gets most of the attention because developers can see it.
Strategic debt often exists elsewhere.
Data debt may include unclear ownership, inconsistent identifiers, missing history, duplicated sources of truth and schemas that encode obsolete business assumptions.
Infrastructure debt may include unsupported runtimes, manual provisioning, environment drift, weak disaster recovery and expensive scaling models.
Integration debt may include undocumented contracts, direct coupling to vendor schemas, brittle polling, missing idempotency and weak failure semantics.
Vendor debt may include proprietary dependencies that are expensive to replace, pricing structures that no longer fit usage, or products that prevent required capabilities.
A useful technical debt inventory should therefore describe constraints, not repositories.
Prioritization Needs Impact and Option Value
A debt backlog sorted by developer preference will compete badly with product work.
The business needs to understand why action matters.
A stronger debt item looks like:
Constraint:
Shared deployment pipeline requires all services to release together.
Observed impact:
Median release lead time increases by 3 days due to coordinated regression.
Business effect:
High-priority customer fixes cannot be deployed independently.
Remediation:
Separate deployment ownership for two high-change domains.
Expected option created:
Teams can release these domains without portfolio-wide coordination.
The important field is the option created.
Debt remediation is valuable when it changes what the organization can do next.
Debt That Can Remain
Not every old component should be modernized.
A stable subsystem with low change frequency, low incident rate and acceptable security posture may be ugly and economically harmless.
Rewriting it can destroy value.
This is where engineering discipline requires restraint.
The fact that a team would design something differently today does not mean replacing it is justified.
A useful decision asks:
- How often does this area change?
- How costly is change?
- What failures does it create?
- What future capability does it block?
- Is there a credible reason those capabilities will be needed?
- What is the migration risk?
- What else could we do with the same engineering capacity?
Debt without meaningful consequence can remain debt.
Debt That Requires Action
Debt becomes a stronger candidate for action when several factors combine:
| Signal | Why it matters |
|---|---|
| High change frequency | carrying cost is paid repeatedly |
| High blast radius | failures affect many users or systems |
| Security exposure | downside can be discontinuous |
| Obsolete platform | support and hiring risk increase |
| Blocks strategic capability | opportunity cost becomes visible |
| Creates operational toil | engineering capacity is consumed |
| Requires rare knowledge | continuity risk increases |
| Prevents independent delivery | coordination tax compounds |
The priority is not "cleanest architecture first."
It is "largest avoidable constraint relative to remediation cost and business direction."
Technical Debt Can Be Rational
Teams sometimes speak about technical debt as evidence that someone failed.
That framing discourages honest trade-offs.
Some debt is intentionally incurred to learn faster, meet a deadline or avoid premature abstraction.
The important practices are:
- make the trade-off visible;
- understand the expected consequence;
- define what would make remediation worthwhile;
- revisit when the context changes.
That is ordinary engineering economics.
The mistake is not choosing speed over elegance.
The mistake is pretending the choice has no future cost.
Modernization Should Target Constraints
This perspective changes modernization strategy.
Instead of asking "Which old technology should we replace?" ask "Which constraints most limit future change?"
That is the core of Modernization Without a Big Bang.
Sometimes the answer is a runtime upgrade. Sometimes it is test coverage. Sometimes it is extracting one domain boundary. Sometimes it is replacing a vendor. Sometimes it is changing nothing.
The objective is not architectural purity.
It is improved capability.
Translate Debt Into Decision Language
Senior engineering leaders need to translate technical debt into terms other functions can reason about.
Instead of:
The codebase is messy.
Say:
Changes in this area require coordinated edits across five modules and a full regression cycle, which makes even low-risk customer changes take several days.
Instead of:
We need to refactor the database.
Say:
Three workflows write directly to the same tables without ownership boundaries. This makes audit history unreliable and prevents us from changing one workflow independently.
Instead of:
We need newer infrastructure.
Say:
The current runtime leaves us on an unsupported dependency path and blocks the security updates required for the next customer segment.
The translation is not salesmanship. It is precision.
Manage Consequences, Not Aesthetics
Technical debt is unavoidable because software is built under uncertainty and constraint.
The strategic question is whether the consequences are visible and managed.
A mature organization can intentionally carry debt when the cost is acceptable.
It can also invest heavily when debt blocks an important business option.
That requires moving beyond a binary distinction between "good code" and "bad code."
The better model is:
Technical condition
↓
Operational or delivery consequence
↓
Business constraint
↓
Option value of remediation
↓
Priority decision
Debt becomes actionable when the organization can see that chain.
The goal is not to eliminate imperfection.
It is to prevent hidden technical constraints from making business decisions on the organization's behalf.
References
- DORA. Loosely coupled teams. https://dora.dev/capabilities/loosely-coupled-teams/
- Microsoft. Cost Optimization design principles. Azure Well-Architected Framework. https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/principles
- Microsoft. Cost Optimization tradeoffs. Azure Well-Architected Framework. https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/tradeoffs