Start with the constraint and its consequences
“The platform needs refactoring” offers little basis for a priority decision. Describe the specific constraint first. Perhaps changing a pricing rule requires edits in several places, an integration cannot be exercised independently or a release depends on a manual procedure understood by one person.
Explain what that constraint affects: change effort, regression risk, support load or the ability to deliver a planned capability. Use examples the team can demonstrate. Avoid attaching a cost or productivity percentage unless there is a defensible basis for it.
Be precise about the category of work. A defect, an active incident, a missing capability and a structural design limitation may need different owners and response times. Labelling all of them technical debt makes prioritisation harder.
Collect evidence proportionate to the decision
For a bounded improvement, a few documented examples of repeated work may support the discussion. A larger investment needs a clearer account of the affected systems, the proposed intervention and the uncertainty around its benefit.
Useful evidence can include changes that repeatedly touch the same components, recurring failure modes, manual release steps and gaps in automated verification. Interpret the evidence with the people doing the work. A slow change may have several causes, including unclear requirements or waiting for decisions.
Keep observed effort separate from a future estimate. If engineers spent time working around a limitation, that supports the existence of friction. It does not prove that removing the limitation will save the same amount on every subsequent change.
Present investment options with clear boundaries
Compare a few credible interventions. The team might isolate a fragile component, add verification around the existing behaviour or redesign the wider area. Each option should explain what it improves and what it leaves unresolved.
Several customer journeys depend on the same integration code. One option is to add automated checks around the current interface before the next release. Another is to introduce a dedicated integration boundary, which requires more implementation and migration work. The choice depends on the upcoming changes and the failure modes the team needs to control.
Include the cost of transition. A cleaner target design may still require compatibility work, data migration, documentation and changes to operational procedures. Those activities belong in the scope of the investment.
Connect remediation to delivery priorities
Identify where an upcoming initiative will encounter the constraint. This creates an opportunity to consider the improvement alongside the delivery work it enables. Sometimes a small preparatory change is enough; sometimes combining both pieces would make the release too difficult to reason about.
Use an explicit decision structure:
- Constraint: the limitation and the evidence behind it.
- Exposure: the delivery or operational consequence.
- Intervention: the bounded engineering change.
- Timing: why the investment matters now.
- Validation: how the team will assess its effect.
When work is deferred, record what is being accepted and when the choice should be revisited. Deferral can be a reasonable decision when the consequence is understood and owned.
Review whether the investment removed the constraint
Define a practical validation before implementation begins. If the objective is to isolate an integration, demonstrate that it can be tested without the entire application. If the objective is to reduce a manual release dependency, exercise the revised procedure with the responsible team.
Review the operational effect after the change has been used. The evidence may support further investment, reveal another limiting factor or show that the original problem was narrower than expected.
This creates a traceable engineering decision: a specific constraint, a considered intervention and an observable result. For help presenting the options, use the technical trade-offs guide.