At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
Technical debt is the cost of deferred work that accumulates interest over time. When a development team chooses a quick or suboptimal solution to ship faster, they're borrowing against the future. That borrowing comes due when the temporary solution needs to be modified, debugged, or integrated with new features.
Like financial debt, technical debt has a cost - paid in development speed, system reliability, and engineer morale. And like financial debt, small amounts of strategic technical debt can be valuable. Accumulated without management, it becomes crippling.
The Cost of Technical Debt - What the Numbers Say
The abstract nature of technical debt makes it easy to dismiss. "It's just code." But the financial impact is concrete and measurable.
McKinsey's 2023 study of software development across Fortune 500 companies found that technical debt consumes 20-40% of engineering capacity. This isn't peripheral work. It's the bulk of engineering effort - paid not to move the business forward, but to fix problems created by past shortcuts.
A typical 100-person engineering organization spends 20-40 people's worth of capacity managing technical debt. If you're paying those engineers $150,000 per year plus benefits and overhead, that's $3-6 million annually spent not on new features, but on cleanup.
For a mid-market software company with 30-50 engineers, technical debt consumes $1-3 million annually.
These costs include:
- Time to make changes (harder changes take longer)
- Time to debug and fix bugs (tangled code is harder to troubleshoot)
- Time to deploy (brittle systems require longer testing)
- Time to onboard new engineers (complicated code takes longer to understand)
- Time responding to incidents (fragile systems break more often)
The paradox: teams create technical debt to ship faster. But six months later, they're shipping slower because all capacity is consumed managing the debt.
What Exactly Is Technical Debt?
Ward Cunningham coined "technical debt" in 1992 as a metaphor to communicate about the need for refactoring. Like financial debt:
- You borrow time now (ship faster) by taking a shortcut
- You pay interest later (higher maintenance costs) on the borrowed time
- The debt can be strategic (borrowing for growth) or destructive (borrowing out of desperation)
- Ignoring the debt doesn't make it go away - it compounds
Technical debt isn't just "bad code." Bad code is like a construction site with sloppy workmanship. Technical debt is choosing to use sloppy workmanship intentionally to meet a deadline, knowing you'll have to fix it later.
This distinction matters. Not all messy code is technical debt. Sometimes the tradeoff wasn't intentional - you built something the wrong way and didn't realize it until later. That's not technical debt; it's a learning expense. Technical debt specifically refers to deferred work that was conscious - a choice to ship faster at the cost of future maintenance.
The Four Types of Technical Debt
Not all technical debt is equal. Some is valuable leverage. Some is destructive. Understanding the types helps you manage them strategically.
1. Intentional Debt - Deliberate Strategic Shortcuts
This is good debt. You make a conscious choice to take a shortcut because the benefits of shipping faster outweigh the costs of maintenance.
Examples:
- Hardcoding a value instead of making it configurable, because the configuration system can be built later
- Implementing a feature with a SQL query instead of building a proper ORM layer
- Using a third-party library that isn't perfect, but saves three months of development
- Skipping some test coverage for rarely-used features to ship faster
The key characteristic: you have a plan to pay it down. You document the shortcut and commit to addressing it after you validate the market need.
Strategic debt is valuable. If you wait to build the perfect architecture before shipping, your startup dies. Intentional debt lets you move fast while validating assumptions.
2. Unintentional Debt - Accidental Shortcuts You'll Regret
This is debt you didn't realize you were taking. You built something one way, later realized a better approach exists, and now you're stuck with the legacy approach.
Examples:
- Building a feature with a database schema that doesn't scale
- Using a framework in a way that locks you into a specific approach
- Making architectural decisions without considering future needs
- Writing code that's hard to test because you didn't think about testability upfront
Unintentional debt is more dangerous than intentional debt because you didn't know you were taking it. You compound it unknowingly - building more features on top of a flawed foundation.
The solution is more rigorous architecture review early on. Not big upfront design, but deliberate thinking about likely future needs.
3. Reckless Debt - Shortcuts Without a Plan
This is bad debt. You take shortcuts without intending to fix them. "We'll clean it up later" is what you say, but later never comes.
Examples:
- Skipping automated tests because you're in a rush
- Using copy-paste instead of extracting shared code
- Leaving commented-out code and debugging print statements in production
- Ignoring deprecation warnings and using outdated APIs
- Building features without documentation or clear interfaces
Reckless debt accumulates fast because it's compounding. Each shortcut makes the next shortcut easier to justify. "The codebase is already messy, one more shortcut won't matter."
4. Environmental Debt - Debt You Inherited
This is technical debt created by past decisions, past teams, or technology choices made before your time. You didn't create it, but you're stuck maintaining it.
Examples:
- A legacy system built on an outdated framework
- Database schemas designed for a different use case
- Infrastructure built without considering modern practices
- Code written before your team developed coding standards
Environmental debt is dangerous because it's easy to blame. "That's legacy code, I'm not touching it." But it still consumes capacity and creates friction.
What Creates Technical Debt?
Understanding how technical debt forms helps you prevent it.
Time Pressure
The primary driver of technical debt is shipping-deadline pressure. When a feature is due in two weeks and building it properly would take four weeks, teams take shortcuts.
This is sometimes necessary. But chronic time pressure creates chronic technical debt. The debt accumulates, capacity is consumed in maintenance, deadlines slip further, and time pressure increases to compensate.
Unclear Requirements
When you don't know what you're building, you guess. You build flexibility you don't need and miss flexibility you do. When requirements change midway (they always do), your architecture no longer fits.
Building with unclear requirements creates architectural debt - the code works for what you ended up building, but the architecture is wrong for that use case.
Skill Gaps
When a team doesn't have expertise in an area, they sometimes create debt unknowingly. A junior team might build a system without considering scalability. An experienced team from a different domain might overlook security. The code works, but it's debt waiting to explode.
Poor Code Review
Code review should catch potential debt before it's committed. When code review is rubber-stamp approval or non-existent, debt accumulates faster.
Context Switching
A developer constantly interrupted or working on multiple features at once can't think deeply about architecture. They produce more code, faster, but the code quality is lower and debt accumulates.
Inadequate Monitoring
You don't see problems until they become crises. Bugs that should have been caught in testing make it to production. Architecture issues don't surface until performance degrades.
Monitoring debt is "invisible debt" - you don't know you have it until it's too late.
Technology Choices
Sometimes technical debt comes from technology choices. Picking a framework that doesn't fit the problem, building on a legacy database engine, or choosing a programming language that's a poor fit for the domain - these create debt that compounds over time.
How to Identify Technical Debt in Your Codebase
You can't manage technical debt you can't see. How do you identify it?
Signal 1: Slow Cycle Time
If a feature that should take two weeks takes five weeks, you have technical debt. The extra time is spent working around architectural issues, untangling dependencies, or debugging fragile systems.
Track cycle time by feature. If it's increasing, you have debt accumulating.
Signal 2: High Change Failure Rate
When a seemingly small change breaks something unrelated, that's a sign of tight coupling. Tight coupling is technical debt - changes have unpredictable consequences.
Signal 3: Long Onboarding
If a new engineer takes three months to be productive, that's either a training problem or a codebase problem. Usually both. Onboarding time is a proxy for code complexity and documentation quality.
Signal 4: Repeated Incidents in the Same Code
If you've had three incidents in the payment processing code in the past year, that code is problematic. It's either complex, undertested, or fragile.
Signal 5: Developers Avoiding Code
If engineers say "don't touch that module, it's complicated" or "that system is a nightmare," that's a clear debt signal.
Signal 6: Copy-Paste Code
Finding identical code in multiple places means duplicated logic - debt waiting to happen. When you find a bug in one copy, you have to hunt down all the others.
Signal 7: Slow Build or Deploy Pipeline
If your build takes 15 minutes or deployment takes an hour, you have infrastructure debt. This debt impacts everything - feedback loops are longer, risk is higher, and frustration increases.
Signal 8: Test Coverage Gaps
Not all code needs tests, but critical paths should be covered. If you're afraid to refactor code because tests don't exist, that's debt.
Signal 9: Deprecated Dependencies
If you're using a library two versions out of date, that's environmental debt. It accumulates faster than you realize.
Signal 10: Architecture Mismatch
If your actual architecture (how the system is actually used) doesn't match your conceptual architecture (how you thought it would be used), you have architectural debt.
Technical Debt vs. Bugs vs. Features - How to Prioritize
This is where most organizations fail. Teams conflate technical debt, bugs, and feature work, then struggle to prioritize.
Bugs are unintended behaviors. Customers discovered something doesn't work as designed. Bugs block customers from using features and should be fixed quickly.
Features are intentional new functionality. They create business value.
Technical debt is deferred work that creates friction in development. It doesn't block customers, but it slows down the team.
The priority order should be:
- Customer-impacting bugs (customers can't use a critical feature)
- Security and data integrity issues
- Features that create business value
- Technical debt that's blocking productivity
- Minor bugs that don't impact customers
- Nice-to-have improvements
The mistake teams make is treating all technical debt equally. Some technical debt is worth fixing immediately (if it's blocking feature work). Some is worth deferring indefinitely (if it's isolated and stable).
Fix debt that's blocking you. If architectural debt is causing every feature to take twice as long, fix it. If it's isolated code that rarely changes, leave it alone.
Fix debt that's fragile. If a system has high incident rates or change failure rates, pay down the debt. If a system is stable, don't touch it.
Fix debt that's blocking other teams. If your coupling is forcing team B to coordinate with team A on every change, that's organizational debt. Fix it.
Defer debt that's isolated. If you have weird code in an obscure module that's not touched, paying it down is a waste of time.
Technical Debt and Non-Technical Stakeholders
This is where many engineering leaders struggle - communicating technical debt to people without technical backgrounds.
"We need to spend two weeks refactoring the data layer" means nothing to a business stakeholder. It sounds like engineering asking to do nothing while other teams wait.
Here's how to frame it:
Connect to business outcomes. "We're refactoring the data layer because search queries are getting slower as we add features. This is why we missed our performance targets last quarter. Two weeks of refactoring will make search 3x faster and prevent performance regressions as we scale."
Use financial language. "Technical debt is costing us $500K per quarter in engineering time. We could allocate resources to pay it down strategically, which would free up capacity for new features."
Quantify the impact. "Every feature we ship takes 20% longer because of how tightly the payment system is coupled to the product code. Decoupling them would let the team ship 20% faster."
Create a tradeoff. "We can ship Feature X in three weeks with the current architecture, or two weeks if we allocate a week to fixing the debt that's slowing us down. Which would you prefer?"
Business stakeholders care about outcomes - shipping speed, reliability, cost. Technical debt matters because it impacts those outcomes, not because it's technically interesting.
Technical Debt in the Age of AI Code Generation
AI code generation tools like GitHub Copilot, Claude, and others have created a new form of technical debt.
AI tools can write code incredibly fast. They can also create debt faster than humans can pay it down.
AI-generated code is often:
- Correct but inelegant (it works, but doesn't follow your codebase patterns)
- Untested (the AI didn't write tests)
- Undocumented (the AI generated code, not documentation)
- Repetitive (the AI didn't know about existing utilities)
The risk: teams use AI to ship features faster, then incur massive maintenance debt because the code quality is lower.
The opportunity: use AI as a tool for boilerplate and known patterns, but keep human review focused on architecture, testing, and design.
Some best practices for AI-generated code:
- Always review AI-generated code. Don't blindly accept it.
- Require tests for AI-generated code. The AI doesn't know about edge cases.
- Apply your coding standards. AI code should follow your patterns.
- Watch for duplication. AI often doesn't know about existing code that solves similar problems.
- Use AI for boilerplate, not architecture. AI is great for writing CRUD operations, weak at designing systems.
The reality: AI tools will increase short-term productivity and long-term debt if not managed carefully. Use them as force multipliers, not as replacements for engineering judgment.
How to Manage and Pay Down Technical Debt
Technical debt isn't something you solve once. It's something you manage continuously.
Step 1 - Measure Your Debt
You can't manage what you can't measure. Quantify how much capacity is consumed by technical debt.
- Track cycle time for features. If it's increasing, you have debt.
- Count incidents caused by fragile systems. That's maintenance cost.
- Measure deployment time. If it's slow due to testing or infrastructure, that's debt.
- Survey your team. Ask what code they hate working in.
Most organizations spend 20-40% of capacity on technical debt (per McKinsey). Where does your organization fall?
Step 2 - Prioritize Strategically
Not all debt is equal. Prioritize debt that:
- Blocks the most features
- Causes the most incidents
- Has the highest maintenance cost
- Creates the most knowledge silos
Use a simple scoring: for each piece of debt, estimate the payoff (how much faster will development be?) and the cost (how long will it take to fix?). Rank by payoff/cost ratio.
Step 3 - Allocate Capacity Consistently
Set aside a percentage of engineering capacity (typically 15-25%) for technical debt paydown. Put it in the calendar like feature work. Don't treat it as "work when you have time."
The percentage depends on your debt level. If you're at 35% capacity consumed by debt, allocate 20% to fix it. If you're at 20% consumed, allocate 15% to prevent it from growing.
Step 4 - Improve Your Development Practices
Prevent new debt from accumulating:
- Enforce code review standards. Reviews should catch debt-creating shortcuts.
- Build quality standards into the process. If tests are optional, debt accumulates faster.
- Invest in build and deployment infrastructure. Fast feedback loops reduce debt.
- Do architecture reviews for major changes. Catch architectural debt before it compounds.
Prevention is cheaper than cure.
Step 5 - Refactor Strategically
When paying down debt, don't refactor everything. Focus on:
- Code paths that change frequently (changing code should be easy)
- Code with high incident rates (fragile code should be stable)
- Code that blocks other teams (coupling should be reduced)
- Code that's hard to test (testability matters)
Use refactoring as an opportunity to improve architecture, not just make the code prettier.
Step 6 - Communicate the Progress
Show stakeholders that technical debt investment is paying off:
- "We refactored the payment system. Deployment time for features dropped from 3 hours to 1 hour."
- "We reduced coupling between teams. Feature development is now 20% faster on average."
- "We paid down database debt. Query performance improved 3x and incidents in that system dropped to zero."
Quantify the payoff. Make it clear that the investment is working.
Creating a Technical Debt Culture
The most important lever is culture. If "shipping dirty" is normalized, debt accumulates faster than you can pay it down. If refactoring is valued, debt stays manageable.
Create a culture where:
- Taking shortcuts is discussed explicitly ("let's take this shortcut to ship faster, but plan to fix it in Q3")
- Refactoring is valued as much as feature work
- Code quality standards are clear and enforced
- Engineers speak up when debt is blocking them
- Paying down debt is celebrated, not seen as a distraction
This requires leadership modeling. If engineering leaders accept "ship it, we'll fix it later," teams will too. If leaders push back on shortcuts and allocate capacity to refactoring, teams will follow.
Technical Debt - Frequently Asked Questions
Q: Should we eliminate all technical debt?
No. Some technical debt is strategic leverage. The goal is to manage debt intentionally, not eliminate it. Most organizations should have 15-25% of capacity consumed by debt management. Much lower and you're over-engineering. Much higher and you're drowning.
Q: When should we pay down technical debt?
Pay down debt that's:
- Blocking new feature work
- Causing incidents or reliability issues
- Creating knowledge silos that limit team capacity
- Slowing down a critical path
Defer debt that's isolated, stable, and not blocking anything. You can leave weird code in an obscure module forever if it's not touching anything.
Q: How do we prevent developers from creating debt?
Code review is the primary mechanism. Reviews should catch shortcuts that create debt. But code review alone isn't enough - you need:
- Clear architectural standards
- Automated testing (so quality is objective)
- Time to do things properly (if you're always in a rush, shortcuts are inevitable)
- Leadership that values quality
Q: Is technical debt the same as legacy code?
Not exactly. Legacy code is code you inherited. Technical debt is code you created intentionally or unintentionally as shortcuts. Some legacy code is debt, some is just old. Some new code accumulates debt quickly.
Q: How do we fix technical debt in critical systems?
Carefully. For critical systems (payment processing, authentication, core platform), refactoring requires:
- Comprehensive test coverage before starting
- Feature flags to decouple deployment from release
- Gradual migration (don't try to replace everything at once)
- A clear rollback plan if things go wrong
- Full team understanding of the change
Refactoring critical systems is risky. De-risk it with testing and gradual approaches.
Q: Our team inherited a massive legacy codebase. Where do we start?
Start with the pain. What part of the system causes the most incidents? What code do developers avoid? What's blocking growth? Start there.
Don't try to rewrite everything. Focus on the critical path:
- Stabilize the system (fix high-incident areas)
- Improve the build and deployment pipeline (faster feedback)
- Add tests to critical paths
- Gradually refactor as you touch code
A rewrite usually creates new debt instead of fixing old debt. Gradual improvement is more effective.
Summary - Technical Debt Is Not Optional
Technical debt is fundamental to how software engineering works. The question isn't whether you'll have it - you will. The question is whether you'll manage it intentionally.
The organizations with the best engineering productivity don't have zero technical debt. They have strategic debt that's tracked, prioritized, and paid down systematically. They prevent the debt that's destructive while accepting the debt that enables fast iteration.
This requires:
- Visibility into your debt (measuring cycle time, incident rates, capacity consumed)
- Priority decisions about what to fix and what to defer
- Consistent allocation of capacity to paydown
- Prevention (better practices to reduce new debt)
- Communication to stakeholders about the business value of the investment
Technical debt is expensive - 20-40% of your engineering capacity. But it's a known cost. You can measure it, manage it, and reduce it.
The organizations that ignore technical debt pay an invisible tax in slow feature development, high incident rates, low morale, and eventually, platform rewrites. The organizations that manage it strategically stay fast, reliable, and sustainable.
Choose management.
Related Reading
- Technical Debt: The Complete Guide for Engineering Leaders
- Code Refactoring: The Complete Guide to Improving Your Codebase
- DORA Metrics: The Complete Guide for Engineering Leaders
- Software Productivity: What It Really Means and How to Measure It
- Code Quality Metrics: What Actually Matters
- Cycle Time: Definition, Formula, and Why It Matters
- Technical Debt Reduction Playbook
- What Is Technical Debt Assessment?
- What Is Technical Debt Tracking?
- Glue for Technical Debt Management
Frequently Asked Questions
What is technical debt?
Technical debt is the implied cost of rework caused by choosing quick or easy solutions now instead of better approaches that would take longer. Like financial debt, it accumulates interest over time as the suboptimal code becomes harder to maintain, extend, and debug.
How do you manage technical debt effectively?
Allocate 15-20% of each sprint to debt reduction. Prioritize debt that impacts delivery speed or causes incidents. Track debt metrics alongside feature metrics. Make debt visible to stakeholders by quantifying its business impact in terms of delayed features and increased incident costs.
What are the different types of technical debt?
Common types include architectural debt (poor system design), code debt (messy or duplicated code), test debt (insufficient test coverage), documentation debt (outdated or missing docs), dependency debt (outdated libraries), and infrastructure debt (manual processes that should be automated).