technical debt

Accumulated shortcuts, workarounds, and suboptimal design decisions in a codebase that make future development harder and slower. Like financial debt, technical debt has interest: the longer it's left unaddressed, the more expensive it becomes to work around. Categories include: code debt (messy, undocumented code), architecture debt (system design decisions that constrain future change), and test debt (insufficient automated tests).

When you'd see it: Engineering planning, roadmap prioritization, sprint retrospectives, engineering hiring discussions.

Why it matters: Technical debt slows velocity. Teams spending 30–40% of engineering capacity managing debt have less capacity for product features. Understanding debt as a business concept helps non-technical leaders make informed tradeoffs in product-vs-platform investment discussions.

Common mistakes: Treating all technical debt as equal. Debt in high-change areas is more expensive than debt in stable, rarely-touched code. The relevant question is not 'how much debt?' but 'how much debt in areas we're actively building on?'

Related refactoring, CI/CD, sprint, architecture