The more useful definition of technical debt: the gap between the architecture you have and the architecture you would build knowing what you know now — specifically, the parts of that gap that are actively constraining your team's ability to deliver.
Cleanup (inconsistent naming, missing tests) can be addressed incrementally. Architectural debt — the decisions that create systemic constraints — cannot usually be addressed incrementally. Splitting a monolith, replacing a central database, migrating a synchronous API to async: these require planned effort and need to be managed as projects.
Time multiplier: how much longer does it take to add a feature because of constraint Y? Risk: probability and impact of failure if this constraint is not addressed in the next 12 months. Opportunity cost: what features cannot be built while this constraint exists?
Address now: debt blocking multiple workstreams or creating unacceptable risk. Plan for next quarter: debt with clear measurable impact. Accept: debt in code rarely changed with bounded cost. Monitor: debt that could become a problem at 3x current scale.
The framing that works: operational cost. "This architectural constraint adds three to five days to every feature we build in the checkout flow. That is one feature per quarter we are not shipping."
"We'll fix the debt in the rewrite" is one of the most expensive sentences in engineering leadership. The few rewrites that succeed: small scope, clear definition of done, parallel operation with the old system, explicit rollback capability.
Axented can help identify and prioritize the debt that is actually costing you velocity. → axented.com/it-consulting
%20(1)-2.svg)
