The release plan is full, but engineers are spending another afternoon tracing an undocumented dependency before a small change can ship. The work may appear as a technical-debt ticket, yet the consequence is already visible in delivery capacity. A CTO can make a stronger case for addressing debt by explaining that consequence rather than asking leaders to fund cleanup in the abstract.
Describe the cost in context
“Old service” is a description, not a decision case. Explain what the service makes difficult: changes require extra coordination, deploys depend on a single specialist, or routine maintenance competes with planned product work. Keep the claim bounded to what the team has observed, and separate recurring friction from a one-time inconvenience.
Connect the problem to a business or operating need. If an upcoming product change depends on a service that is hard to modify, that dependency belongs in the plan alongside the feature. If the main concern is supportability, identify which operational responsibilities are exposed and what an acceptable improvement would look like.
Compare the real alternatives
A rewrite is not automatically the responsible answer. The choice may be to isolate a risky component, improve tests around a frequently changed path, replace a dependency, or continue with an explicit limit on what the system can support. Each option has a different cost, delivery interruption, and residual risk.
Ask the engineers who maintain the system to describe the failure modes and estimate the work, but make the trade-off legible to the wider leadership team. What planned work moves if this is funded now? What constraint remains if it is deferred? This keeps a technical recommendation connected to the opportunity cost it creates.
Fund a bounded improvement
Break broad debt initiatives into changes that produce visible improvements: a service can be deployed without a manual handoff, a critical path has automated tests, or ownership and recovery steps are documented. Agree on what will count as progress before the work begins. A bounded outcome makes it easier to review the result and choose the next investment.
Technical debt is not a moral failing or a separate engineering economy. It is a set of constraints competing for the same people and time as product work. Bring those constraints into planning with clear options, and the discussion can move from “clean it up” to a decision about which capacity the organization needs back.