Technical debt
lastmod 2026-04-26created 2023-03-226 edits
Technical debt (technical debt, design debt, code debt) is a concept in software development that reflects the cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Technical debt can be compared to monetary debt.
6 types of technical debt
What it takes to see technical debt as a strategic lever
- Recognize and address negative assumptions about technical debt
- Classify the 6 types of technical debt and handle each differently
- Gauge the size of technical debt
- How to prioritize technical debt
How to Not Manage Tech Debt
4 assumptions that lead to mismanaging technical debt
==== Assumption #1 : Technical debt = bad ====
- Not all technical debt should be classified as 'bad'
- It is much better to classify technical debts by naming each one and measuring how much pain it causes
- Some technical debt is good to have, and every team should have technical debt
- The case of Twitter, which 'had good technical debt': it used public storage, then developed its own distributed DB, Manhattan
- Questions to counter the assumption 'technical debt = bad'
- What can we gain if we take on this technical debt now and resolve it next month?
- Under what circumstances would leadership care about this technical debt? How should we deliver information that helps the CTO pitch to leadership?
- How can this initiative tie into the company's larger vision or strategic direction?
==== Assumption #2 : All technical debt = complex work ====
- As with any difficult work, not just technical debt, there are many ways to handle complex tasks
- For technical debt in particular, there is a way to approach Defined/Undefined work
- Defined = the work has a beginning and an end
- Undefined = the work has a beginning, but its end is unclear
- Clarify whether the technical debt at hand is Defined or Undefined
- If Defined, understand the expected time to complete the work and give it some buffer time
- If Undefined, list the unclear parts so others can understand why the work is complex and has no clear end date, share them with stakeholders, and ask for their input on the best way forward
- Make Undefined technical debt less complex by breaking it into digestible pieces of work
- Turning large, complex work into small tasks that are complex but actionable can motivate the team more to resolve part of the technical debt within a set period such as a sprint/quarter
- What are the wrong assumptions about the system?
- If we brought in someone experienced or familiar with this area, what questions must we ask?
- Does our team have the right people and knowledge to do this work? If not, how should we think about reallocating information, and when would be the ideal time to tackle this problem?
- What is the best way to explain the complexity of this technical debt to someone who doesn't understand it at all?
Assumption #3 : Technical debt ≠ product work
- Organizations are clear about how product work will improve company metrics
- Technical debt is usually missing from this
- Resolving technical debt in a timely manner can be important for driving company growth, even if it cannot be quantified immediately
- To counter the assumption technical debt ≠ product work
- Even if a particular area of technical debt doesn't connect directly to metrics, think broadly about which user/product experiences it could help
- Instead of emphasizing technical benefits, give equal emphasis to the benefits to users and the product, so others can easily understand why the team should care about this work
- Spend time making sure the business lead and tech lead understand the same thing (on the same page)
- What is the single most important reason to do this work now?
- Who needs to understand the impact of this work? Why should they care about it?
- What am I trying to say? Does it match what stakeholders want to hear? If not, how can I solve their problem?
- What do I or the team consider a reasonable vs. great outcome?
- Am I overpromising on the expected outcome? Can I level expectations by splitting outcomes into great and good?
==== Assumption #4 : Individual pain = organizational pain ====
- Engineers close to technical debt regularly and repeatedly say that dealing with it is personally painful
- The employee may feel it is the end of the world, but the rest of the organization doesn't feel the same pain
- This is common among people early in their careers and usually stems from a lack of broader strategic context
- To counter the assumption individual pain = organizational pain
- When you hit a high-priority area of technical debt, take a moment to check whether it is an individual or organization-level pain point
- Organization-level problems generally affect customers or the business directly in some way
- Think from the perspective of someone with more organizational context than you. You could also explain it to someone on another team
- How many teams will benefit from classifying and resolving this technical debt?
- When has the company recognized or rewarded someone who took on technical debt work? What type of technical debt was it, and why was it needed at the time? Can you talk about how that person positioned the work?
- Does my engineering manager understand the value of technical debt work? Will they advocate for my contribution to this work during performance reviews?
6 types of technical debt
Maintenance dept(maintenance debt)
- When the team can't keep up with updates to the technology
- Also includes not deleting dead code after starting an experiment / rolling out a feature / canceling a deployment, and not updating libraries, commenting context code, documenting implementation decisions, etc.
- e.g.) Experimenting with a 'log in with Spotify' feature, then not deleting the code when it was canceled
Developer efficiency debt(developer efficiency debt)
- When the company lacks proper testing, monitoring, and alerting systems for its product
- A common type of debt where the engineering workflow is very inefficient, deployments/builds take hours/days, and developers can't catch technical problems before they reach production
- e.g.) As the organization grew from 15 to 50 people in a year, too many experiments were running. 2-3 bug-fix releases for bugs found in production are backed up. New tests for the purchase experience fall behind them
Stability debt(stability debt)
- When various types of technical debt pile up in the organization and affect the stability of the infrastructure
- Instead of managing on-call proactively, scenarios arise where the relevant expert is called in after a problem occurs, or the whole team ends up on call
- This is a big headache for engineers and the on-call rotation team, but the rest of the company can't even identify or explain the problem
- Stability debt also affects product reliability and can cause problems that customers run into
- e.g.) The mobile team has more iOS developers, so iOS is prioritized over the Android app. As a result, the Android app lacks product guidelines for business-critical flows and also contains weak-spot (Kryptonite) code originally developed by a third party. This causes crashes when Android users access old features, and the Google Play rating suffers
Security debt(security debt)
- When using a tech stack with security vulnerabilities such as brute-force password attacks, data leaks, etc.
- Because it is hard for people to plan for and assess things that may (or may not) happen, many organizations accumulate security debt
- e.g.) Internal process problems prevent timely updates, so a known vulnerability goes unpatched and customers' personal data leaks (from small companies to companies like Equifax, where 140 million people were affected)
Technical product debt(technical product debt)
- When negative effects on the product become noticeable
- The easiest and best debt to resolve: it affects users, and every team in the organization can see its impact on sales/revenue
- e.g.) It takes users several seconds to do a particular task in the product. This can arise from various debts, but it affects users' core product experience
Decision debt(decision debt)
- Paying the cost of a previous technical decision because it was X% wrong or made trade-offs in terms of scope, time, and resources
- The most common form of technical debt
- e.g.) A website used a third party for certain experiments. After growing enormously over several years, it now has millions of visitors. As a result, the engineering, data, and product teams all struggle every time they run a complex experiment.
- This decision debt arose because the team made a trade-off decision between a third party and in-house development. It was probably right at the time, but now they are paying for it
Sizing technical debt : Acute vs Systemic
Once you understand the type of technical debt, you need to size its cost so it can be compared with what you will gain
When a team asks 'When will we get time to work on technical debt?', it is hard to tell whether it is small or large in terms of time, thought, and effort
- Acute technical debt
- Relatively small technical debt
- e.g.) To ship a new feature, work for a platform/browser with a small user base was skipped. If nothing else comes up, it can easily be added within 1 day
- Systemic technical debt
- Technical debt ranging from large to enormous in scale
- e.g.) The CTO/founder made a decision about the product (and indirectly the technology) 5 years ago, and effort was built on that foundation. Changing it would affect many things.
- This technical debt can't be resolved easily, and changing it can take months to years
Prioritizing technical debt strategically
A flexible way to consider and evaluate:
- Confidence : Is this likely to lead to a serious problem? Low/High
- Time : When will this become a problem? Not urgent/Urgent
- Impact to User : If we don't do this, will speed/quality problems arise that hurt the user experience? Low/High
- Sequence : Does this block reaching an important milestone? Small impact/Blocking
- Accumulated debt : How much debt have we already decided to accumulate? Little/A lot
Strategic technical debt portfolio by company growth stage
Traction
- Before Product-Market fit
- Engineering decisions must favor speed over accuracy, stability, and process. Large-scale developer efficiency debt
- Usually means choosing a full-stack framework such as Django, Rails, PHP, etc. to develop quickly
Inflection
- The point where there are signs of PMF and the product transitions into a scalable loop
- The team realizes it needs some process (developer efficiency debt starts to be resolved), and technical product debt grows because it is still balancing internal processes against the user experience
Scale
- The company's hyper-growth period (hyper-growth)
- As balance is found between internal practices and processes and the user experience, technical product debt and developer efficiency debt begin to decrease and stabilize
- As a result of very fast growth, security debt, maintenance debt, and decision debt increase
- Many changes and fixes happen in test automation, deployment systems, monitoring and alerting, logging and instrumentation, testing and staging, ETL, etc.
Expansion
- The start of Saturation. The business becomes more mature
- Maintenance debt and decision debt keep growing due to large amounts of old code and decisions
- As the team looks for new growth opportunities, developer efficiency debt starts to increase again
- Technical product debt, security debt, and stability debt are being balanced after the previous period
Tips for managing a technical debt portfolio
Processes to reduce the technical debt being created
- Accumulating technical debt can be strategic, but sometimes it is right to prevent technical debt from being created by implementing processes from the start
- This is especially true in the Inflection and Scale stages, where developer efficiency debt should decrease as more engineers join
- As developer efficiency debt decreases, it may be replaced by growing decision debt and maintenance debt
- Examples of such processes : code/PR reviews, monitoring standards, QA sign-off, and technical/design reviews
Tools that prevent certain types of debt from forming
- Investing in basic tooling can keep some types of debt from forming
- Especially important in the Scale stage for security issues (security debt), preventing bugs that affect the user experience (technical product debt), and code consistency (developer efficiency debt)
- Examples of such tools : Linters and CI/CD pipelines
Sprint work for Reactive & Acute technical debt
- Once an organization reaches a size that needs on-call, on-call sprints should be spent on fighting current fires or on reactive work related to technical debt
- Through this, the organization can handle urgent technical debt items and take real action on current/past problems via the on-call team
- Enabling on-call for reactive work is especially important in the Scale/Expansion stages of growth. Because handling urgent technical debt lets other teams build new features/products and deal with additional debt
Roadmap work for proactive and systemic technical debt
- Putting technical debt on the roadmap requires alignment across many teams
- Examples of putting technical debt on the roadmap : large rewrites, rebalancing data systems for features customers mainly use, defining and implementing alerts for critical paths, migrating payment systems, etc.
How to turn technical debt from a burden into a strategic lever
- Through accumulated technical debt, the team can make overall strategic decisions about which initiatives to pursue
- Think about the common technical debt assumptions the team will face. Are you pushing back on "technical debt = bad" or "technical debt ≠ product work"? Are you listening to a colleague who thinks "individual pain = organizational pain"?
- Don't use the catch-all term "technical debt". Name it maintenance debt, developer efficiency debt, stability debt, security debt, technical product debt, or decision debt
- Size the technical debt to make it less ambiguous. Is it Acute or Systemic?
- Prioritize technical debt strategically against other areas of the company. Prioritize based on vectors such as confidence, time, impact on users, etc.
- Evolve and keep balancing the technical debt portfolio according to the changes and needs as the company grows
Sizing technical debt : Acute vs Systemic
Once you understand the type of technical debt, you need to size its cost so it can be compared with what you will gain
When a team asks 'When will we get time to work on technical debt?', it is hard to tell whether it is small or large in terms of time, thought, and effort
- Acute technical debt
- Relatively small technical debt
- e.g.) To ship a new feature, work for a platform/browser with a small user base was skipped. If nothing else comes up, it can easily be added within 1 day
- Systemic technical debt
- Technical debt ranging from large to enormous in scale
- e.g.) The CTO/founder made a decision about the product (and indirectly the technology) 5 years ago, and effort was built on that foundation. Changing it would affect many things.
- This technical debt can't be resolved easily, and changing it can take months to years
Prioritizing technical debt strategically
A flexible way to consider and evaluate:
- Confidence : Is this likely to lead to a serious problem? Low/High
- Time : When will this become a problem? Not urgent/Urgent
- Impact to User : If we don't do this, will speed/quality problems arise that hurt the user experience? Low/High
- Sequence : Does this block reaching an important milestone? Small impact/Blocking
- Accumulated debt : How much debt have we already decided to accumulate? Little/A lot
Strategic technical debt portfolio by company growth stage
Traction
- Before Product-Market fit
- Engineering decisions must favor speed over accuracy, stability, and process. Large-scale developer efficiency debt
- Usually means choosing a full-stack framework such as Django, Rails, PHP, etc. to develop quickly
Inflection
- The point where there are signs of PMF and the product transitions into a scalable loop
- The team realizes it needs some process (developer efficiency debt starts to be resolved), and technical product debt grows because it is still balancing internal processes against the user experience
Scale
- The company's hyper-growth period (hyper-growth)
- As balance is found between internal practices and processes and the user experience, technical product debt and developer efficiency debt begin to decrease and stabilize
- As a result of very fast growth, security debt, maintenance debt, and decision debt increase
- Many changes and fixes happen in test automation, deployment systems, monitoring and alerting, logging and instrumentation, testing and staging, ETL, etc.
Expansion
- The start of Saturation. The business becomes more mature
- Maintenance debt and decision debt keep growing due to large amounts of old code and decisions
- As the team looks for new growth opportunities, developer efficiency debt starts to increase again
- Technical product debt, security debt, and stability debt are being balanced after the previous period
Tips for managing a technical debt portfolio
Processes to reduce the technical debt being created
- Accumulating technical debt can be strategic, but sometimes it is right to prevent technical debt from being created by implementing processes from the start
- This is especially true in the Inflection and Scale stages, where developer efficiency debt should decrease as more engineers join
- As developer efficiency debt decreases, it may be replaced by growing decision debt and maintenance debt
- Examples of such processes : code/PR reviews, monitoring standards, QA sign-off, and technical/design reviews
Tools that prevent certain types of debt from forming
- Investing in basic tooling can keep some types of debt from forming
- Especially important in the Scale stage for security issues (security debt), preventing bugs that affect the user experience (technical product debt), and code consistency (developer efficiency debt)
- Examples of such tools : Linters and CI/CD pipelines
Sprint work for Reactive & Acute technical debt
- Once an organization reaches a size that needs on-call, on-call sprints should be spent on fighting current fires or on reactive work related to technical debt
- Through this, the organization can handle urgent technical debt items and take real action on current/past problems via the on-call team
- Enabling on-call for reactive work is especially important in the Scale/Expansion stages of growth. Because handling urgent technical debt lets other teams build new features/products and deal with additional debt
Roadmap work for proactive and systemic technical debt
- Putting technical debt on the roadmap requires alignment across many teams
- Examples of putting technical debt on the roadmap : large rewrites, rebalancing data systems for features customers mainly use, defining and implementing alerts for critical paths, migrating payment systems, etc.
How to turn technical debt from a burden into a strategic lever
- Through accumulated technical debt, the team can make overall strategic decisions about which initiatives to pursue
- Think about the common technical debt assumptions the team will face. Are you pushing back on "technical debt = bad" or "technical debt ≠ product work"? Are you listening to a colleague who thinks "individual pain = organizational pain"?
- Don't use the catch-all term "technical debt". Name it maintenance debt, developer efficiency debt, stability debt, security debt, technical product debt, or decision debt
- Size the technical debt to make it less ambiguous. Is it Acute or Systemic?
- Prioritize technical debt strategically against other areas of the company. Prioritize based on vectors such as confidence, time, impact on users, etc.
- Evolve and keep balancing the technical debt portfolio according to the changes and needs as the company grows
See also
- Programming
- Technical debt (Korean: 기술 부채)
- Cognitive debt (Korean: 인지 부채)
- Intent debt (Korean: 의도 부채)
Favorite site
- Technical debt - Wikipedia
- Cho Dae-hyup's blog - Technical Debt
- Technical debt, cognitive debt, intent debt | GeekNews
- Fragments: April 2
- In an environment where LLMs mass-produce code, it is not just the code itself that weakens but also the team's shared understanding and the record of system goals, so there is a growing need to address this in three layers: technical debt, cognitive debt, and intent debt
- Technical debt limits the ability to make future changes, Cognitive debt weakens the team's ability to reason about system changes, and Intent debt blurs the record of goals and constraints, hindering the continued evolution of humans and AI agents
- The Tri-System theory, which places AI as System 3, distinguishes cognitive surrender, where one trusts external artificial reasoning uncritically and skips deliberation, and treats it as different from cognitive offloading, where cognition is delegated strategically
- As coding gets cheaper, what gets expensive is verification, and the criteria for correctness and success differ by context, such as traffic ETAs, driver dispatch, and operating hundreds of microservices, making human judgment and the design of verification systems more important
- The center of gravity in engineering shifts from implementation volume to verification, and humans will continue to hold on to the meaning of systems through roles like useful abstractions and naming, and designing acceptance criteria and test harnesses