managing-tech-debt

SKILL.md

Strategic technical debt management using insights from 18 product leaders.

Diagnose urgency by understanding the debt's nature, how it manifests (slow velocity, incidents, shipping blocks), and business context, then choose between incremental improvement, targeted refactoring, or full rewrite

Full rewrites almost never work as planned; they take 2-3x longer than estimated and require supporting both systems simultaneously. Prefer incremental evolution and component uplift

Tech debt is product debt owned by PMs alongside engineers, not an engineering-only concern. Quantify costs and include in Top 10 Problems to build stakeholder buy-in

Monitor the "interest" on debt; if maintenance consumes 80-90% of engineering time, you've run out of runway. Startups should strategically take on debt early to move faster than larger competitors

Fix bugs immediately rather than backlogging them; bug backlogs become graveyards. Create dedicated time to delete unused code, which improves velocity and clarity

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:

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

Diagnose the urgency - Determine if this is blocking critical business needs or a slower-burning issue

Choose the right approach - Help them decide between incremental improvement, targeted refactoring, or (rarely) a full rewrite

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.