The technology update arrives near the end of the board agenda. Several systems are amber, one is red and an upgrade is overdue. The board asks whether it can wait. The technology lead says the risk is significant but struggles to describe when it will become an incident or what the financial exposure is.

No investment is approved. Nothing is formally rejected. The issue returns next quarter with the same colour and less credibility.

Both sides may be acting reasonably. The technology team can see constraints and failure modes that are difficult to quantify. The board has to compare an uncertain remediation cost with clearer commercial demands. The failure is the absence of a shared decision frame.

Technical debt is a trade-off with a continuing cost

Technical debt is often described as the result of doing something quickly instead of doing it properly. That captures one source and oversimplifies the idea.

Teams take on debt when a technical choice makes delivery easier now while creating additional work, constraint or risk later. The choice may be deliberate and sound. A firm may use a temporary integration to meet a regulatory deadline, accept limited automation while testing a service or postpone a platform change during an acquisition.

Debt also appears without an obvious shortcut. Software ages. Vendors end support. A once-suitable architecture meets new volume or security needs. Documentation loses value as teams and systems change. Acquisitions join technologies that were never designed to operate together.

The board should therefore avoid treating all debt as incompetence. The governing questions are whether the debt is visible, what interest the firm is paying, and whether there is a credible plan to manage or retire it.

That “interest” can include:

  • additional time and risk every time the system changes;
  • specialist support or expensive vendor dependence;
  • manual controls and reconciliations;
  • slower recovery from incidents;
  • security exposure from unsupported components;
  • inability to adopt a commercially valuable capability;
  • concentrated knowledge in a few people;
  • avoidable frustration for clients and employees.

A platform can remain available while this cost grows. Uptime alone is a poor measure of health.

Why red, amber and green are insufficient

A red status conveys urgency and hides the information a board needs to act. Red can mean an unsupported public-facing component, an expensive but stable maintenance burden, a capacity limit expected next year or a control weakness with a low likelihood and severe consequence.

A board paper should translate the issue into a decision. At minimum, it needs:

  • the affected business services and data;
  • the current technical condition;
  • the consequence if nothing changes;
  • evidence and uncertainty about likelihood and timing;
  • current operating and change costs;
  • available treatment options;
  • dependencies and decision deadlines;
  • an accountable owner.

The technical detail still matters. It supports security review, estimates and delivery planning. It belongs behind the commercial summary rather than being removed from the analysis.

Translation is a shared responsibility. Technology leaders asking for capital need to explain the business effect and uncertainty. Finance and operational leaders should help shape estimates and scenarios. The board must ask enough questions to govern a dependency on which the firm's services rely. Expecting one person to turn complex system risk into a certain financial forecast is another way to postpone the decision.

How debt appears outside the technology function

Change becomes slow and unpredictable

A seemingly small improvement requires analysis of undocumented dependencies, regression testing across connected systems and a release window controlled by a third party. Estimates widen because the team cannot know the full impact before opening the system.

The relevant board measure is not whether developers appear busy. Track lead time for comparable changes, failed or rolled-back releases, waiting on dependencies and the proportion of estimates dominated by uncertainty. A worsening pattern can show debt affecting commercial responsiveness.

Keeping the service running consumes capacity

Maintenance spend can rise while visible capability stays flat. Licence premiums, specialist contractors, manual monitoring and repeated fixes all use money and attention.

There is no universal healthy ratio between maintenance and improvement. A stable regulated service and a growing digital product have different economics; classifications also vary between firms. The useful analysis compares like with like over time and explains material changes.

Ask which costs would disappear, remain or increase under each option. A replacement rarely removes all operating cost, and an upgrade may introduce a temporary period of parallel running.

Risk becomes concentrated

Unsupported software can increase security and resilience risk, particularly where it is exposed to the internet or processes sensitive information. It does not follow that every old component creates the same immediate danger. Exposure, compensating controls, known vulnerabilities, data sensitivity and recovery capability all affect the judgement.

The board should see the result of current security and continuity assessment, including where evidence is incomplete. Inventing a probability to make the paper look commercial is less useful than a range, scenarios and a clear statement of uncertainty.

People can be a concentration risk too. If only one employee or supplier understands a critical integration, departure or unavailability can stop change and slow recovery. Documentation, cross-training, support arrangements and a tested exit route are part of debt management.

Commercial options narrow

Technical debt can make a desirable move slower or disproportionately expensive. A firm may struggle to connect client and marketing data, introduce appropriate self-service, change a supplier or support an acquisition.

This “option cost” is easy to exaggerate. The technology team should connect the constraint to an actual strategic priority, state what capability is blocked and compare alternatives. Vague claims that the legacy estate prevents innovation will lose against specific revenue and client commitments.

Delay does not have a fixed interest rate

Debt can compound. That does not mean every deferred upgrade triples in cost. The original article used illustrative upgrade figures that could be mistaken for a forecast. A credible investment case uses the firm's own estate, contracts and evidence.

Delay may increase cost because more customisations accumulate, upgrade paths close, knowledgeable people leave or vendor support becomes scarce. It may also reduce uncertainty if a replacement product matures, a contract nears expiry or another programme removes the affected service.

The option to wait should be assessed like any other option. Define what will be monitored, which controls make the delay tolerable, what date forces reconsideration and what would trigger earlier action. “Do nothing” should mean a managed position, not an absent decision.

Five board questions that produce a better case

1. Which business services depend on the debt?

Connect components to client journeys, revenue processes, regulated activity, sensitive data and operational teams. This shows impact and prevents an infrastructure label from obscuring a business dependency.

2. What is the current cost of carrying it?

Include licences, support, specialist skills, repeated incidents, manual work, slow changes and controls. Show the source and confidence for each estimate. Avoid presenting staff time as cashable savings unless the firm could actually remove or redeploy it.

3. What credible scenarios could occur if we wait?

Describe a reasonable range: continued operation with higher cost, a security or resilience event, loss of vendor support, inability to meet a commercial deadline, or an emergency replacement. State likelihood qualitatively or quantitatively only where evidence supports it.

4. What are the treatment options?

Replacement is one option. Others include upgrade, isolation, simplification, removing customisations, buying extended support, improving recovery, reducing exposure or retiring the service. Compare cost, risk, time, benefit and reversibility.

5. What decision is needed now?

The immediate decision may be funding discovery, approving a risk treatment, protecting a delivery window or accepting a controlled delay. Make the owner, deadline and consequence of missing it explicit.

Build a portfolio, not a panic list

Create a technical-debt register linked to the firm's digital and risk portfolios. Each material item should include an owner, affected service, evidence, current carrying cost, treatment, decision date and review trigger.

Prioritise using more than technical severity. Consider security and regulatory consequence, client and commercial effect, operational fragility, cost of delay, dependencies and the feasibility of intervention. Keep scores open to challenge; a weighted matrix supports judgement and does not eliminate it.

The portfolio view also reveals useful sequences. Documentation and observability may reduce risk before a migration. Retiring an unused integration can simplify a later upgrade. A discovery phase may narrow an unusable estimate range. These are investable steps even when the board is not ready to approve a full replacement.

The board and technology team need one argument

Blame weakens the case. Technology leaders are responsible for presenting actionable choices. The board is responsible for understanding and governing material technology dependencies. Finance, operations, security and service owners contribute evidence neither side holds alone.

The desired outcome is not automatic approval of the technology team's preferred remedy. It is an informed decision that compares current cost, future risk and commercial opportunity with other uses of capital.

Start with the five questions above and ask for a small portfolio of the firm's most consequential debt, not an inventory of every imperfection. Distinction's digital maturity assessment can help frame the wider estate, and our guide to planning digital investment when budgets are tight explains how to compare options.

When the board can see what it is paying to carry the debt, what it might lose and what choices remain, deferral becomes a decision rather than drift.