6 hours ago
- Technical debt proposals get approved when framed as a price (e.g., cost in days or incidents), not as an adjective (e.g., 'the module is a mess'), because prices are comparable to roadmap priorities.
- Use a four-field template to describe debt: Construct (specific location), Interest (repeatable cost in tracked metrics), Principal (effort to fix), and Trigger (upcoming work increasing interest).
- Example: payment logic duplicated across three services costs 12 days per quarter in extra work and incidents, costs 3 weeks to fix, and a Q4 checkout redesign will increase interest.
- The template reveals that debt with no planned changes and zero interest can be intentionally accepted, ending pointless arguments.
- Three key habits: price interest in organizational metrics (e.g., lead time), attach principal to existing feature work instead of separate cleanup sprints, and let some debt stay based on interest vs. ugliness.
- Signs pricing is missing: unscheduled refactoring tickets, unexplained estimate growth, and all items marked critical in a debt register.
- AI-generated code increases debt because ununderstood code is debt even if clean, making visibility through pricing more critical.