Technical debt is a metaphor for the gap between how a system was built and how it should have been built. Just as financial debt accrues interest over time, technical debt accrues in the form of slower development, more bugs, harder onboarding, and increasing fragility as the system grows. The term was coined by software engineer Ward Cunningham in the early 1990s.
Technical debt accumulates in many ways. Sometimes it is deliberate: a team ships a faster but less robust solution to hit a deadline, intending to return and improve it later. Often it is accidental: decisions that were correct at the time become liabilities as requirements change, technology evolves, or the team that made them departs. Outdated dependencies, duplicated logic, insufficient test coverage, and undocumented integrations are common forms.
The cost of technical debt is not always visible on a sprint board, but it is real. Teams with high technical debt move slower, make more mistakes when changing existing systems, and face higher risks when scaling. Engineers spend more time understanding existing code than writing new code. Bug rates increase. Onboarding new engineers takes longer.
Managing technical debt is not about achieving a perfect codebase. It is about keeping debt at a level that does not significantly slow the team down or create existential risk. Effective strategies include regular refactoring sprints, defining clear "done" standards that prevent new debt from accumulating, and making debt visible on the roadmap so it competes fairly with feature work for prioritization.