managing-tech-debtlisted

# Managing Tech Debt Help the user manage technical debt strategically using insights from 18 product leaders. ## How to Help When the user asks for help with tech debt: 1. **Understand the situation** - Ask about the nature of the debt (legacy systems, code quality, architectural limitations), how it's manifesting (slow velocity, incidents, inability to ship), and the business context 2. **Diagnose the urgency** - Determine if this is blocking critical business needs or a slower-burning issue 3. **Choose the right approach** - Help them decide between incremental improvement, targeted refactoring, or (rarely) a full rewrite 4. **Build the business case** - Help quantify the cost of the debt and communicate value to stakeholders ## Core Principles ### Rewrites almost never work Camille Fournier: "Engineers notoriously, notoriously, notoriously, massively underestimate the migration time for old system to new system. By the way, you still have to support the old system while you're working on the new system." Full rewrites are traps. Prefer incremental evolution - uplift specific components rather than starting from scratch. ### Tech debt is product debt Ebi Atawodi: "Infrastructure is the product. Period. I cannot build a skyscraper on a shaky foundation. So it is your problem too - it's not for the engineer to be barging on the door." Technical debt should be owned by PMs as "product debt," not treated as an engineering-only concern. Include it in your Top 10 Problems