Technical debt conversations fail when they are framed as engineers wanting something for aesthetic reasons. Framed as a budget line with a stated return, they usually succeed.
Name the interest payment
Every piece of debt costs something measurable: hours per feature, incidents per month, onboarding days per new engineer. Estimate the number. 'This adds about two days to every feature in the checkout flow' is a business argument. 'The code is messy' is not.
Fixed allocation, visible list
- Reserve a standing share of each sprint — we use 15–20%
- Keep the debt list in the same tracker as features, not a private document
- Attach an estimated interest cost to each item
- Review quarterly and delete anything nobody has paid interest on
Some debt should never be repaid
Code in a feature you plan to sunset, or in a product that has not found users yet, is debt on an asset you may sell. Leaving it alone is the correct engineering decision, and saying so out loud buys credibility for the times you do ask.
Want this applied to your product?
We do this work for clients every week. Bring us the specifics and we will tell you what we would change first.
Book a Call