Technical Debt

Also known as: Tech DebtCode DebtDesign DebtArchitecture DebtEngineering Debt

Debt Interest Rate = Weekly Time Wasted ÷ Repayment Effort (hours)

💡The Concept

Technical debt is the accumulated cost of shortcuts, workarounds, and deferred maintenance in your codebase that make future changes slower and riskier. Like financial debt, tech debt accrues 'interest' — every feature takes longer to build because engineers must navigate around the accumulated mess. McKinsey estimates that tech debt consumes 20-40% of enterprise technology estate value. A team adding features to a clean codebase might ship in 2 days; the same feature in a high-debt codebase takes 2 weeks because of fragile dependencies, missing tests, and unclear abstractions. Tech debt isn't always bad — deliberate, strategic shortcuts can accelerate time-to-market if you plan to repay them.

⚠️The Trap

The trap is treating all technical debt as equal. There's a critical difference between DELIBERATE debt ('we're skipping tests to hit the launch deadline — we'll add them next sprint') and ACCIDENTAL debt ('nobody realized this architecture wouldn't scale past 10K users'). Deliberate debt with a repayment plan is a strategic tool. Accidental debt with no plan compounds silently until it causes a production crisis. Another trap: the 'complete rewrite' fallacy. Teams that try to rewrite from scratch almost always fail — Netscape famously lost 2 years to a rewrite that nearly killed the company. Pay down debt incrementally.

🎯The Action

Allocate 15-20% of every sprint to tech debt repayment (Google's standard is 20%). Track tech debt with a 'debt register' — a list of known debts, their estimated interest (how much they slow down current work), and their repayment cost. Prioritize by Interest Rate = (Weekly Time Wasted ÷ Repayment Effort). A debt item causing 4 hours of waste per week that takes 16 hours to fix has a 4-week payback period — fix it immediately. A debt item causing 30 minutes of waste per week that takes 80 hours to fix has a 160-week payback — it can wait.

⚡Pro Tips

The best teams quantify tech debt in COSTS, not abstractions. Instead of 'the auth system needs refactoring,' say 'the auth system adds 3 hours to every new integration and caused 2 production incidents ($45K in direct costs). Refactoring cost: 120 engineering hours ($24K). Payback: 8 integrations (4 months).' This gets exec buy-in.

Use the Strangler Fig Pattern for paying down debt. Instead of rewriting systems wholesale, build new functionality on clean architecture and gradually route traffic from old to new. Amazon migrated from monolith to microservices over 6 years using this pattern — never breaking the live site.

Track 'developer velocity' metrics (pull request cycle time, build time, deployment frequency). When these metrics slow down, it's usually tech debt accumulating. A 20% slowdown in PR cycle time over 6 months is a leading indicator of debt compounding.

🚫Common Myths

✗Myth: “Tech debt only affects engineers, not the business”

✓Reality: Tech debt directly impacts business metrics: slower feature delivery (time-to-market), more production incidents (customer satisfaction, churn), higher recruitment costs (engineers don't want to work in legacy codebases), and security vulnerabilities. Equifax's 2017 data breach ($1.4B cost) was caused by known, unpatched technical debt.

✗Myth: “Good engineers don't create technical debt”

✓Reality: Every fast-moving team creates tech debt — it's a natural byproduct of shipping quickly. The difference between good and bad teams isn't zero debt; it's whether debt is INTENTIONAL (we know we're taking this shortcut and we have a repayment plan) or UNINTENTIONAL (we didn't realize this would cause problems).

🎮Decision Scenario: The Debt Reckoning

You're the VP of Engineering at a 3-year-old startup. Your codebase has grown to 500K lines with limited tests, no documentation, and a monolithic architecture. Build times are 25 minutes. Deploys fail 30% of the time. Your best engineer just quit, citing 'technical frustration.'

Codebase Size

500K lines

Test Coverage

22%

Build Time

25 minutes

Deploy Failure Rate

30%

Feature Velocity

4 features/month (was 8 a year ago)

Decision 1

Your CEO is panicking about the velocity decline. They want 8 features/month again and suggest hiring 4 more engineers. Your tech lead argues that hiring will make things WORSE — more people pushing code into a fragile system means more broken deploys and more time spent on incidents.

Hire 4 engineers — more engineers means more features, period. We'll figure out the tech debt laterClick to reveal →

Brook's Law strikes: adding people to a late project makes it later. The 4 new engineers need 3 months to ramp up. During ramp, senior engineers spend 40% of their time mentoring instead of building. Deploy failure rate increases to 45% (more changes, same fragile pipeline). Feature velocity drops further to 3/month. Total cost: $480K in salary for net negative productivity.

Team Size: 8 → 12 engineersFeature Velocity: 4 → 3 features/monthDeploy Failure Rate: 30% → 45%

Declare a '6-week tech debt sprint': 80% of capacity goes to test coverage, CI/CD pipeline, and build optimization. 20% handles urgent customer issues onlyClick to reveal →

Feature velocity drops to 1/month for 6 weeks (the CEO is uncomfortable). But by week 6: test coverage jumps to 55%, build time drops to 8 minutes, deploy failure rate drops to 8%. In the NEXT quarter, feature velocity rebounds to 10/month — 25% higher than the original 8/month. The investment pays for itself in 2 months of recovered velocity.

Test Coverage: 22% → 55%Build Time: 25 min → 8 minFeature Velocity (Q2): 4 → 10/month

🧪