Technical debt is the accumulated cost of shortcuts and compromises in a software system. Ward Cunningham, who coined the term, described it as borrowing against future productivity: the code works now, but it requires extra effort to extend, maintain, or change later.
Not all debt looks the same. There are four distinct types of technical debt: code, architecture, process, and organizational. Each has different causes, different symptoms, and a different remediation approach. When a team says "we have a lot of tech debt," they are usually carrying all four simultaneously without a clear picture of which type is driving the most pain. This post breaks down each type so you can turn a vague complaint into an actionable priority list.
For a complete overview of measuring, managing, and reducing technical debt, see our Technical Debt Guide for Engineering Leaders.
Intentional vs. Unintentional Debt: The First Split
Before categorizing debt by type, there are two root origins that determine how you address it.
Intentional debt is a deliberate trade-off. Your team knows a better solution exists, chooses a faster one to hit a deadline, and plans to circle back. Done consciously and logged properly, intentional debt is manageable. The debt contract is transparent: team knows it exists, knows where it lives, and has a plan for when to pay it back.
Unintentional debt builds without awareness. It comes from knowledge gaps, skill limitations, unclear ownership, or evolving requirements that outpace the original design. This debt is harder to address because it is often invisible until it causes a production incident or a delivery slowdown.
Martin Fowler's Technical Debt Quadrant maps these two origins against whether the debt was prudent or reckless, giving engineering teams a useful framework for triaging what they have inherited.
The Four Types of Technical Debt
1. Code Debt
Code debt is the most visible and the most commonly discussed. It lives at the implementation level: the individual decisions about how code is written, tested, and maintained.
What it looks like:
• Quick fixes and hacks that solve an immediate problem but create fragility elsewhere
• Poor or absent test coverage, meaning regressions go undetected
• Outdated or abandoned dependencies that accumulate known vulnerabilities
• Duplicated logic scattered across the codebase rather than centralized
• Inconsistent naming conventions and documentation that slow onboarding
Real-world sign: A developer cannot make a change to one module without breaking two others. PRs trigger unexpected failures in unrelated test suites. Every hotfix spawns new support tickets.
How to address it: Static analysis tools like SonarQube surface code debt automatically. Prioritize refactoring the modules with the highest churn rate and the most active bug reports first. Introduce test coverage requirements before adding new features to high-debt areas.
2. Architecture Debt
Architecture debt operates at a level above individual code quality. It is about how the system is structured, how components relate to each other, and how well that structure can absorb change.
What it looks like:
• Tightly coupled components that cannot be modified or replaced independently
• A monolithic system that has grown past the point where the original design still makes sense
• Outdated or unsuitable frameworks that limit what the team can build
• Missing abstractions: business logic embedded directly in database queries, API responses mixed with UI rendering
• Services that were designed for one scale now operating at a completely different one
Real-world sign: Deploying a change to Feature A requires coordinating with the teams responsible for Features B, C, and D. The system cannot be tested in isolation. A seemingly small change touches dozens of files across multiple services.
How to address it: Architecture debt requires deliberate investment, not just incremental cleanup. Start with a component dependency map to identify the tightest coupling. Break apart the highest-risk modules first, not the largest ones. Track architecture debt as a separate backlog from code debt, because the remediation timeline and stakeholder conversations are different.
3. Process Debt
Process debt is the gap between engineering best practices and the actual development workflow. Unlike code or architecture debt, process debt is often invisible in the codebase itself. It shows up in team behavior, review patterns, and delivery reliability.
What it looks like:
• Absent or inconsistent code review processes, with PRs merged without scrutiny
• Manual testing replacing automated test suites
• No CI/CD pipeline, or a pipeline so brittle that teams regularly bypass it
• Missing or inconsistent branching strategies that make releases unpredictable
• Deployment processes that require manual steps, tribal knowledge, or specific people to be online
Real-world sign: Releases happen on an unpredictable schedule. Bugs found in QA should have been caught earlier. Incidents are often caused by process failures rather than code: wrong branch deployed, migration not run, configuration not updated.
How to address it: Process debt is the most addressable type because it does not require code changes. Define and enforce a branching strategy. Add mandatory review gates to the CI/CD pipeline. Start with the highest-frequency pain point. DORA metrics (deployment frequency, change failure rate, MTTR) from dora.dev benchmark where your process actually stands against high-performing peers.
4. Organizational Debt
Organizational debt is the hardest to see and the most expensive to ignore. It is not in the codebase at all. It is in the people, team structures, knowledge distribution, and documentation.
What it looks like:
• Critical knowledge concentrated in one or two engineers (bus factor of 1)
• Documentation that is absent, incomplete, or so outdated it actively misleads
• No clear ownership of specific systems or code areas
• Teams structured in ways that create friction rather than enabling fast delivery
• Under-resourced areas of the codebase that are known problem zones but nobody's job to fix
Real-world sign: When a senior engineer leaves, velocity drops noticeably for the next quarter. New engineers take four to six months before they can contribute independently. Post-mortems keep identifying the same root causes without systemic resolution.
How to address it: Knowledge transfer is active work, not a side task. Pair programming, tech talks, and architectural decision records (ADRs) all reduce organizational debt. Team topology work, mapping Conway's Law against your architecture, can reveal whether your org structure is generating architecture debt as a byproduct.
How Different Debt Types Interact
Fixing one type of debt in isolation rarely sticks. The four types reinforce each other. Code debt accumulates fastest when process debt is high: no reviews, no tests. Architecture debt gets worse when organizational debt keeps the people who understand the system from documenting it. Process debt intensifies when the codebase is so fragile that teams stop trusting the CI/CD pipeline.
A refactoring sprint that produces cleaner code but does not also improve test coverage and review processes will accumulate the same debt again within a quarter.
How to Identify Your Debt Mix
With all four types understood, the practical question is: which ones are driving the most pain right now? Run a triage across all four:
• Code debt audit: Run static analysis (SonarQube, CodeClimate). Count open quality issues, complexity violations, and test coverage gaps.
• Architecture debt audit: Map your component dependencies. Count how many services need to be coordinated for a standard deployment.
• Process debt audit: Pull your DORA metrics. Review your last ten incidents for process-related root causes.
• Organizational debt audit: Identify which systems have one or zero documented owners. Map knowledge concentration by asking who would be needed to deploy each critical system from scratch.
The result is a debt profile, not just a debt pile. Each type has a different owner, a different remediation approach, and a different conversation to have with product and finance leadership.
For benchmarks and how to track each of these metrics in practice: Software Quality Metrics That Reduce Technical Debt
Managing the four types of technical debt requires visibility across your entire engineering system. Scrums.com is an engineering intelligence platform that connects to your existing tools (GitHub, Jira, CI/CD) and surfaces code churn rates, DORA metrics, test coverage trends, and sprint health in a single dashboard, giving engineering leaders a clear view across all four debt types without manual data pulls. See how it works.
Frequently Asked Questions
What are the four main types of technical debt?
The four main types are code debt (quick fixes, poor test coverage, outdated dependencies), architecture debt (tightly coupled systems, outdated frameworks), process debt (missing CI/CD, skipped reviews, manual testing), and organizational debt (poor documentation, tribal knowledge, unclear ownership). Each type has different root causes and requires different approaches to address.
What is the difference between intentional and unintentional technical debt?
Intentional debt is a deliberate trade-off where the team knowingly chooses a faster solution to meet a deadline, with a plan to address it later. Unintentional debt accumulates without awareness, typically from knowledge gaps or evolving requirements. Intentional debt is manageable if logged and tracked. Unintentional debt is harder to address because it is often invisible until it causes a delivery problem.
Which type of technical debt is hardest to fix?
Architecture debt and organizational debt are typically the hardest to fix. Architecture debt requires coordinated effort across teams and carries a high risk of cascading changes. Organizational debt cannot be fixed with a refactoring sprint: it requires sustained investment in knowledge transfer and team practices. Code debt, by contrast, is the most addressable because static analysis tools surface it directly and remediation is scoped to specific files or functions.
How does technical debt affect delivery speed?
Each type slows delivery differently. Code debt increases the risk of regressions with every change. Architecture debt increases coordination costs. Process debt makes releases unpredictable. Organizational debt slows onboarding and creates single points of failure. Teams carrying heavy debt across all four types typically see delivery times two to three times longer than high-performing peers, based on DORA research.
How do you prioritize technical debt across all four types?
Prioritize by impact on delivery, not by volume. Identify the debt that is currently blocking feature work or causing the most incidents, then address that first regardless of type. Maintain a debt backlog with estimates and business impact framing so leadership can make informed trade-off decisions. Most high-performing teams allocate 15 to 20% of sprint capacity to debt work across all four categories on a continuous basis rather than deferring to a dedicated debt sprint.
