Managing Technical Debt at Scale
summary
Claims that organizations carry 20–40% of capacity as technical debt, that most debt items have a negative business case, and that only a small fraction are worth fixing. Recommends inventorying the whole landscape into units of improvement, using tooling to produce an automated ROI ranking but stopping for human selection, then executing prioritized refactors. Emphasizes maintainability as the measurable gateway metric, closing the source of leakage, and aiming for a pragmatic “four‑star” quality rather than perfection.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 3:09Original definition
- 4:50Why tech debt matters
- 6:53Scale and cost of tech debt
- 8:23Tech debt’s visibility problem
- 9:26Prioritizing tech debt by ROI
- 11:16Centralized vs autonomous teams
- 13:30Preventing new tech debt
- 16:38Myths on new tech vs legacy
- 18:46Tech debt slows innovation
- 20:59Two key questions
- 22:06Q&A: Job security
- 23:49Q&A: Legacy systems
- 24:51Q&A: When to stop refactoring
- 25:32Q&A: Building skills
- 26:13Q&A: Measuring tech debt
- 27:20Closing remarks
related talks
35mTechnical Debt. A guide for developers and IT managers
25mDemystifying Technical Debt
34mThe Technical Debt Trap
25mLiving With Technical Debt: Acknowledge It, Specify It, Reduce It
41mA Bluffer's Guide to Technical Debt for Other People
28mTechnical Debt: Why it'll ruin your software
11mRefactoring: Managing technical debt before it blows up in your face
45mTechnical Debt: Taking back control when it's already messed up