Technical Debt Strategy: Funding, Acceptance and Review Decisions

Decide which technical-debt work to fund, investigate or accept using explicit authority, portfolio constraints, review triggers and evidence of improvement.

Make the funding decision explicit

An engineering leader has three requests: replace an unsupported dependency, simplify a slow-changing reporting module and repair an unreliable recovery process. Treating them as one debt backlog hides the different reasons for acting.

The dependency has a support constraint. The reporting module has a possible efficiency benefit. Recovery has an operational risk that may be unacceptable regardless of payback. They need different evidence and, sometimes, different decision-makers.

This guide covers portfolio funding and acceptance. Use the inventory-to-verification guide to run an individual item and the quantification worksheet to test its cost assumptions. Keeping those decisions separate avoids turning every leadership conversation into another code-quality inventory.

Agree what qualifies for each decision path

Technical debt is a useful metaphor, not a precise balance-sheet liability. Cunningham's original account links immature implementation to later difficulty changing software. Fowler's quadrant adds useful distinctions about how design debt arises. Neither supplies a universal capacity allocation.

A long method, duplicated code or an old framework can prompt investigation. The funding request still needs an observed constraint, a plausible cause and a remedy. Line counts and generalized discomfort are not sufficient.

| Decision path | Evidence and authority needed | |---|---| | Contain an active exposure | Security or incident leadership determines containment and escalation. A routine backlog ranking must not delay it. | | Meet an obligation | Identify the verified support, contractual or policy deadline, the responsible owner and the acceptable transition. | | Remove a delivery constraint | Show affected work, causal evidence, options, cost uncertainty and a verification plan. | | Investigate | State the unknown, the bounded experiment and the decision its result will change. | | Accept or retire | Record who can accept the residual risk, when to revisit it and how retirement will protect users and data. |

An engineering team cannot unilaterally accept every business risk. A technical lead can recommend an option, but contractual, security or customer commitments may require approval elsewhere.

Use a portfolio decision record

A useful leadership review changes a commitment. It should not simply count how many debt tickets remain.

For each material proposal, keep a short record:

The service outcome at risk and the observed evidence.
The options, including containment, acceptance and retirement where credible.
The owner, decision authority and affected teams.
The scope boundary and work that would be displaced.
The acceptance evidence, migration risk and recovery limit.
The next review trigger and the conditions that stop further investment.

Michael Nygard's ADR format provides a useful basis for preserving context, a decision and its consequences. Add funding and authority fields when the decision crosses teams. Keep the superseded record so future readers can see why an earlier choice made sense.

“Approved” should mean a defined slice has funding. It should not authorize an open-ended modernization program.

Worked portfolio: allocate against constraints, not a quota

Consider a fictional planning period with 40 engineer-days available after leave and ordinary operational commitments. Product and engineering have agreed that 15 days support a committed delivery. The remaining 25 days are available for the following proposed decisions.

| Allocation | Decision and acceptance boundary | |---|---| | 15 days: committed delivery | Preserve the agreed feature scope. Any additional modernization requires a separate tradeoff. | | 8 days: dependency transition | Fund a compatible upgrade and verification before the verified support deadline. Exclude unrelated redesign. | | 7 days: recovery repair | Rehearse recovery against an agreed dataset and measure correctness as well as duration. Escalate if the slice cannot meet the required recovery behavior. | | 5 days: reporting investigation | Determine whether query shape, data access or application structure causes the observed delay. Return an option recommendation, not a replacement system. | | 5 days: uncommitted capacity | Retain room for discoveries and urgent work; release it deliberately if the review shows it is unnecessary. |

The allocations total 15 + 8 + 7 + 5 + 5 = 40 days. They are illustrative, not a recommended debt percentage. The estimates could be wrong, and different specialists may not be interchangeable across the work.

The reporting rewrite is not approved in this period. The investigation has value because its result can prevent funding the wrong remedy. If the dependency transition expands, the owners must revise the portfolio openly. They cannot consume the recovery allocation without revisiting the risk decision.

A fixed percentage can be a local budgeting convention, but it should not override a real deadline or conceal work that no longer has a useful outcome.

Accept debt with conditions

Acceptance is a decision to carry a known constraint under stated conditions. It is not a promise that the constraint is harmless.

An illustrative acceptance record for a reporting module could read:

| Record field | Example | |---|---| | Accepted constraint | The current export format makes adding another destination expensive. Existing supported exports remain functional. | | Authority and owner | Product owner accepts the delivery limitation; the reporting team maintains operational ownership. | | Evidence | No additional destination is committed in the current roadmap. Existing failures are tracked separately. | | Boundary | No weakening of access controls or data-retention obligations is included in the acceptance. | | Revisit trigger | A new destination enters planning, usage changes materially, or a supporting dependency loses support. | | Review outcome | Continue acceptance, fund discovery, schedule repair or approve retirement with a migration plan. |

Set a review date as a backstop, but prefer triggers tied to the reason for acceptance. Automatically carrying the same exception through every review is not a fresh decision.

Choose the delivery shape and its stopping rules

Some debt can be addressed inside a feature because the feature already changes the affected boundary. Other work needs an independent slice to keep scope and failure diagnosis clear.

Do not require refactoring in every review. A focused incident fix may need a narrow change with strong tests. Cleanup can follow with its own owner. Google's code-review guidance is useful for assessing design, complexity, tests and documentation without reducing review to arbitrary line-count limits.

Incremental replacement can limit exposure when traffic, data and interfaces can be separated. It also creates a period of dual ownership, routing rules and reconciliation. Plan and fund that overlap. A full replacement may be reasonable for a small, well-understood component or one that cannot support the required behavior. Neither choice has a universal success rate.

Before migration, identify the last point where rollback remains straightforward. New data formats, external actions and changed contracts may make reverting the code insufficient. Define forward recovery and reconciliation before reaching that point.

Pause or rescope when the proposed remedy fails its causal test, the retirement horizon changes, or the cost exceeds the approval boundary. Sunk effort does not establish that finishing is the best remaining option.

Review outcomes without rewarding hidden debt

Use a recurring review that fits the delivery cadence and deadlines. Discuss changed constraints, verification results and decisions requiring authority. Avoid a standing presentation of the entire backlog.

For completed work, compare the agreed outcome with observations: fewer manual reconciliation steps, a supported runtime, a successful recovery rehearsal or a removed dependency. “Merged” and “verified” are different states.

Do not promise a percentage increase in velocity without evidence. If the work was justified by risk reduction, report the specific risk and remaining limitations. If it was justified by capacity, check the recurring burden and added maintenance using comparable work.

Start the next review with one proposed investment and one accepted item whose assumptions may have changed. For a significant replacement decision, bring those records to a refactor-versus-rebuild assessment, together with the migration and recovery constraints.