Technical debt timing
Choose whether to repair a constraint now, contain it, or defer with an explicit trigger.
The decision
What will this debt block before the next planned change?
Assumptions and limits
This is a prioritization discussion, not an automatic monetary valuation of technical debt.
Describe your situation
Decision context
Is this debt already causing incidents or blocking a committed outcome?
- Yes
- No
- Not measured
Decision context
Can the repair be contained to a narrow boundary?
- Yes
- No
- Unclear
Urgency and evidence
Is the consequence of waiting tied to a concrete date or trigger?
Use supported security findings, end-of-support dates or committed changes. Age and discomfort alone are not deadlines.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Urgency and evidence
Can the debt be contained safely until the next review?
Check mitigations, detection, expiry and accountable risk ownership. A workaround is not a permanent repair.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Repair sequencing
Is the repair sequenced against other planned changes?
Map consumers, schema changes, upgrades and rollout windows. Fixing immediately can still create avoidable migration work.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Repair sequencing
Has the smallest proposed repair been tested against the cause?
Use a reproducible failure or change bottleneck. A broad cleanup can be valuable without fixing this particular problem.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Capacity and review
Is the repair’s opportunity cost explicit?
Compare the next committed outcome, support burden and capacity. Do not invent a monetary debt-interest rate.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
Capacity and review
Will a named owner review the repair or deferral outcome?
Keep the decision, accepted residual risk, review date and success evidence together. Closing a ticket is not proof of reduced risk.
- Yes, supported by evidence
- Partly, with known gaps
- No, the check is not met
- Unknown, not verified
How this tool works
Each selected answer maps to a stated observation and a check to perform. Answers are not weighted, added together, or converted into a score, diagnosis, or automatic recommendation.
An unknown answer identifies evidence to collect. Review each observation against your system and constraints; one favorable answer does not establish overall readiness or fit.
Model assumptions
- This is a prioritization discussion, not an automatic monetary valuation of technical debt.
- Responses are self-reported and have not been independently verified.
Is this debt already causing incidents or blocking a committed outcome?
Yes: Repair may be part of delivering the next outcome.
Check: Tie the fix to a measurable acceptance criterion.
No: Deferral may be reasonable if the risk is monitored.
Check: Record an owner and a trigger for revisiting it.
Not measured: Priority cannot be inferred from age alone.
Check: Measure the incidents, rework, or change delay it causes.
Can the repair be contained to a narrow boundary?
Yes: A focused repair can reduce risk without a broad rewrite.
Check: Prototype the smallest reversible change.
No: The fix may require a staged transition.
Check: Map dependencies and identify a safe first slice.
Unclear: Scope uncertainty is part of the decision.
Check: Time-box an investigation and define a stop condition.
Is the consequence of waiting tied to a concrete date or trigger?
Yes, supported by evidence: The timing decision is connected to a specific consequence.
Check: Review the trigger when the affected commitment or support date changes.
Partly, with known gaps: A risk is plausible, but its date, exposure or trigger still needs evidence.
Check: Record the event, affected capability, evidence source and owner who must act before it.
No, the check is not met: The proposed urgency is not yet supported by a concrete event.
Check: Record the event, affected capability, evidence source and owner who must act before it.
Unknown, not verified: Missing evidence prevents a conclusion. Use supported security findings, end-of-support dates or committed changes. Age and discomfort alone are not deadlines.
Check: Record the event, affected capability, evidence source and owner who must act before it.
Can the debt be contained safely until the next review?
Yes, supported by evidence: Deferral has a bounded control and a revisiting point.
Check: Retain a dated mitigation check and its expiry condition.
Partly, with known gaps: A mitigation helps, but detection or expiry remains unverified. Resolve the prerequisite's remaining gaps before making the stated commitment.
Check: Test the containment and define who responds when its trigger fires.
No, the check is not met: Deferral would leave a known exposure without an owned containment plan.
Check: Test the containment and define who responds when its trigger fires.
Unknown, not verified: This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check mitigations, detection, expiry and accountable risk ownership. A workaround is not a permanent repair.
Check: Test the containment and define who responds when its trigger fires.
Is the repair sequenced against other planned changes?
Yes, supported by evidence: The repair can be placed where it unlocks rather than conflicts with planned work.
Check: Recheck dependencies when release or migration plans change.
Partly, with known gaps: Some dependencies are known, but competing changes can invalidate the proposed sequence.
Check: Map the next two changes touching the boundary and choose a safe sequence with their owners.
No, the check is not met: The repair schedule ignores other work on the same boundary.
Check: Map the next two changes touching the boundary and choose a safe sequence with their owners.
Unknown, not verified: Missing evidence prevents a conclusion. Map consumers, schema changes, upgrades and rollout windows. Fixing immediately can still create avoidable migration work.
Check: Map the next two changes touching the boundary and choose a safe sequence with their owners.
Has the smallest proposed repair been tested against the cause?
Yes, supported by evidence: The repair has evidence of addressing the observed cause.
Check: Retain the reproduction and before-and-after acceptance result.
Partly, with known gaps: A prototype helps, but regression or production-shape assumptions remain open.
Check: Test one reversible repair against the original symptom and a nearby regression case.
No, the check is not met: The proposed work is not yet connected to resolution of the stated constraint.
Check: Test one reversible repair against the original symptom and a nearby regression case.
Unknown, not verified: Missing evidence prevents a conclusion. Use a reproducible failure or change bottleneck. A broad cleanup can be valuable without fixing this particular problem.
Check: Test one reversible repair against the original symptom and a nearby regression case.
Is the repair’s opportunity cost explicit?
Yes, supported by evidence: The prioritization includes the work displaced as well as the repair benefit.
Check: Revisit the trade when capacity or the committed outcome changes.
Partly, with known gaps: Engineering effort is estimated, but delayed product or support work remains unclear.
Check: Compare repair now, containment and deferral using the same time window and evidence.
No, the check is not met: The team cannot yet explain what it gives up by repairing now.
Check: Compare repair now, containment and deferral using the same time window and evidence.
Unknown, not verified: Missing evidence prevents a conclusion. Compare the next committed outcome, support burden and capacity. Do not invent a monetary debt-interest rate.
Check: Compare repair now, containment and deferral using the same time window and evidence.
Will a named owner review the repair or deferral outcome?
Yes, supported by evidence: The decision can be revisited using an accountable record.
Check: Check the stated outcome after repair or at the deferral trigger.
Partly, with known gaps: An owner exists, but the review evidence or accepted residual risk is incomplete.
Check: Assign a review owner and record the specific measure or event that reopens the decision.
No, the check is not met: The debt can return to an unowned backlog regardless of the choice made today.
Check: Assign a review owner and record the specific measure or event that reopens the decision.
Unknown, not verified: Missing evidence prevents a conclusion. Keep the decision, accepted residual risk, review date and success evidence together. Closing a ticket is not proof of reduced risk.
Check: Assign a review owner and record the specific measure or event that reopens the decision.
Hypothetical worked example
These illustrative inputs are not your result, a customer case, or a benchmark. Change the inputs above to review your own situation.
- Is this debt already causing incidents or blocking a committed outcome?
- Not measured
- Can the repair be contained to a narrow boundary?
- Unclear
- Is the consequence of waiting tied to a concrete date or trigger?
- Unknown, not verified
- Can the debt be contained safely until the next review?
- Unknown, not verified
- Is the repair sequenced against other planned changes?
- Unknown, not verified
- Has the smallest proposed repair been tested against the cause?
- Unknown, not verified
- Is the repair’s opportunity cost explicit?
- Unknown, not verified
- Will a named owner review the repair or deferral outcome?
- Unknown, not verified
Resolve the flagged prerequisites before committing to this decision
8 applicable prompts reviewed. 1 flagged prerequisite needs owner review before the affected use or commitment. These are self-reported observations, not proof of readiness, a maturity grade or a recommendation to buy a service. Even an all-positive review needs supporting evidence.
- Is this debt already causing incidents or blocking a committed outcome? Priority cannot be inferred from age alone.
- Can the repair be contained to a narrow boundary? Scope uncertainty is part of the decision.
- Is the consequence of waiting tied to a concrete date or trigger? Missing evidence prevents a conclusion. Use supported security findings, end-of-support dates or committed changes. Age and discomfort alone are not deadlines.
- Can the debt be contained safely until the next review? This prerequisite is unverified, not proven absent. Resolve its evidence before making the stated commitment. Missing evidence prevents a conclusion. Check mitigations, detection, expiry and accountable risk ownership. A workaround is not a permanent repair.
- Is the repair sequenced against other planned changes? Missing evidence prevents a conclusion. Map consumers, schema changes, upgrades and rollout windows. Fixing immediately can still create avoidable migration work.
- Has the smallest proposed repair been tested against the cause? Missing evidence prevents a conclusion. Use a reproducible failure or change bottleneck. A broad cleanup can be valuable without fixing this particular problem.
- Is the repair’s opportunity cost explicit? Missing evidence prevents a conclusion. Compare the next committed outcome, support burden and capacity. Do not invent a monetary debt-interest rate.
- Will a named owner review the repair or deferral outcome? Missing evidence prevents a conclusion. Keep the decision, accepted residual risk, review date and success evidence together. Closing a ticket is not proof of reduced risk.
Checks for this example
- Measure the incidents, rework, or change delay it causes.
- Time-box an investigation and define a stop condition.
- Record the event, affected capability, evidence source and owner who must act before it.
- Test the containment and define who responds when its trigger fires.
- Map the next two changes touching the boundary and choose a safe sequence with their owners.
- Test one reversible repair against the original symptom and a nearby regression case.
- Compare repair now, containment and deferral using the same time window and evidence.
- Assign a review owner and record the specific measure or event that reopens the decision.