Tech-debt triage.
End the debt argument. A two-axis matrix that tells the team what to fix, what to defer, what to live with. A dollar figure on every line for the CFO.
Engineering concerns, business decisions.
Technical debt isn't just an engineering problem. Left unaddressed, it constrains revenue, slows velocity, and limits options at exactly the wrong time.
Not all debt is equal. Some slows you down today. Some will matter in six months. Some never matters at all. The framework gives you a vocabulary to tell the difference, and to defend the answer to the CFO.
Stakeholders can't see tech debt the way they see features. We translate it: "this slows every new feature by two days." "This creates a ten-percent failure rate on checkout." Make the cost concrete.
The question isn't "should we fix this?" It's "what happens to the business if we don't?"
Four quadrants. Four actions.
Every piece of debt falls into one of four quadrants. Each quadrant has one action.
Fix now
Blocking revenue, slowing critical features, or creating security risk, and quick to fix. Drop everything. Ship the fix this sprint.
Plan and schedule
Will hurt the business if ignored, but takes weeks to fix. On the roadmap. Dedicated time. Broken into phases where possible.
Opportunistic
Not urgent, but easy. Fix when you're already touching the code. In the backlog. Engineers clean it up alongside feature work.
Accept or defer
Messy code that doesn't slow you down and would take weeks to fix. Accept it. Document the trigger that would make you revisit.
Apply consistently, or not at all.
The framework only works if the rules are applied across the team, and across quarters.
Business impact first
Technical elegance isn't the goal. Business velocity is. Prioritise debt that blocks revenue, slows critical features, or creates security risk.
Not all debt is equal
Strategic debt, shortcuts you took knowingly, can wait. Accumulated mess compounds. Tell the difference, treat them differently.
Make it visible
Stakeholders can't see tech debt. Translate it: "two days per feature." "Ten-percent failure rate on checkout." Make the cost concrete.
Pay down incrementally
Big rewrites usually fail. Break into phases. Fix the highest-impact parts first. Ship improvements iteratively.
Accept some debt
Perfect code serves no users. Some debt will never matter. A messy script that runs once a month? Leave it. Focus on what slows you down.
Useful for, and not.
A framework earns its keep by being clear about what it doesn't do.
Use it when
- You have a backlog of debt and limited engineering time.
- Stakeholders ask why you're fixing old code instead of shipping features.
- Engineers disagree on what to prioritise.
- You need to justify debt work to non-technical leadership.
- Your team is mature enough to have accumulated debt worth triaging.
Don't use it when
- You're a pre-product startup, ship features, worry about debt later.
- Your codebase is so broken that nothing works reliably.
- You're using "tech debt" as an excuse to avoid hard prioritisation.
- You're using "tech debt" as an excuse to avoid shipping.
- You lack the data to assess business impact.
If the debt argument is stuck, we can end it.
Four weeks. A matrix the team agrees on. A line item the CFO can read.