Technical debt rarely arrives at the board as one large failure. It appears in longer estimates, rising support effort, delayed changes and an increasing number of requests that begin with “we need to fix the foundation first”. Each instance is manageable. Together, they consume the firm's capacity to change.
Calling this “debt” is useful only if the organisation makes the obligation visible. Some shortcuts are rational. They become dangerous when nobody records the trade-off, measures its carrying cost or decides when to repay it.
The board does not need to manage code. It does need to understand how technology constraints affect cost, risk and strategic options.
What technical debt includes
Technical debt is the future work created by a present design or delivery decision. It may arise from speed, uncertainty, limited budget, changing requirements or poor practice.
Examples include:
- unsupported software or dependencies
- duplicated integrations and brittle point-to-point connections
- custom code without current tests or documentation
- manual deployment and recovery steps
- inconsistent data models and duplicated records
- accessibility or security work deferred from delivery
- a backlog of upgrades needed before new capability can be added
- concentration of knowledge or access in one person or supplier
Age is an imperfect proxy. An older, supported system with simple architecture and tested recovery may carry less debt than a recent platform assembled through hurried customisation.
Likewise, maintenance is not inherently debt. Patching, monitoring and routine renewal are part of running a dependable service. The question is whether avoidable complexity or deferred work is causing the effort and exposure to grow.
Three ways the cost compounds
The cost of ordinary change rises
Each workaround adds another condition future work must preserve. A small change starts to require investigation across custom code, integrations and undocumented exceptions. Testing expands because teams cannot predict the consequences confidently.
The resulting estimates become larger and more uncertain. Business teams may stop requesting useful changes because the answer is consistently expensive. That suppressed demand rarely appears in the technology budget.
Track lead time, engineering effort, change failure and the proportion of work spent understanding or stabilising the existing service. The trend is more informative than a generic maintenance benchmark.
Capability options narrow
A platform can remain operational while becoming a poor base for the next strategy. It may lack supported interfaces, modern identity, structured content or the ability to meet current accessibility and security expectations.
The firm then faces a series of compromises: add an expensive adapter, operate another system beside it, reduce the ambition or postpone the service. Each compromise can create more debt and make a later migration harder.
Record capabilities delayed or rejected because of the foundation. Estimate the commercial or operational consequence with the requesting team. Avoid claiming revenue that cannot be evidenced; lost time, duplicated effort and missed deadlines may already make the issue material.
Remediation grows more complicated
Deferral does not freeze the starting point. Data accumulates, workflows change, more systems integrate and more exceptions become embedded. A later replacement must understand and migrate that expanded reality.
Costs may also become concentrated. Support can end, a key person can leave or a regulatory obligation can create a deadline. The firm loses the option to phase work calmly and pays for urgent remediation alongside normal operations.
This is why a deferred upgrade cannot be modelled simply as the same project next year. Estimate what is likely to change in the source estate and the conditions that could remove choice.
Make the carrying cost visible
A useful technical-debt register connects each item to a service and decision. Include:
- a plain-language description
- affected clients, colleagues or business capabilities
- current operating effort and incidents
- security, resilience, regulatory or accessibility exposure
- dependencies and key-person risk
- options to tolerate, contain, repay or retire it
- evidence, confidence and review date
- an accountable owner
Avoid a list of every imperfect component. Prioritise debt that materially changes risk or obstructs an important outcome.
Finance and delivery data can reveal the carrying cost. Separate routine operation, enhancement, incident response and debt repayment where practical. Examine vendor support, emergency contractor use, recurring manual work, repeated defects and change estimates. Include internal time, which is easily hidden when salaried teams absorb complexity.
Opportunity cost needs discipline. Name the specific change that cannot proceed and the evidence supporting its value. A vague assertion that the old platform “prevents innovation” will not help a board compare investments.
Model scenarios, not an invented curve
Universal claims that maintenance grows by a fixed percentage each year are attractive and usually indefensible for a particular estate. Build scenarios from the firm's own evidence.
Compare at least three options:
- Tolerate and monitor. Continue operating the service, fund essential support and define triggers for reconsideration.
- Contain and repay selectively. Remove the highest-risk dependencies, improve tests or documentation and create room for priority changes.
- Modernise or retire. Replace the foundation, simplify the service or move capability to supported managed products.
For each option, show costs over a relevant period, including operation, delivery, migration, dual running, data work, training and decommissioning. Show ranges and assumptions. Include the cost and risk of transition; a replacement does not eliminate debt automatically.
Model uncertainty explicitly. A best case, expected case and adverse case are more credible than one precise total. Identify the events that would move the estimate: vendor end-of-support, renewal, staff departure, acquisition or a new regulatory deadline.
Know when deferral is rational
Debt can be a sound decision when speed creates disproportionate value, a hypothesis still needs testing or capital belongs on a more important risk. The decision needs boundaries.
Record what was compromised, the consequence, the temporary controls and the review trigger. Fund the repayment where possible. A shortcut with no owner or expiry is an unpriced promise made to a future team.
Deferral may be appropriate if the affected service has low criticality, support remains available, recovery is tested, change demand is limited and the organisation retains options. It becomes harder to defend when several of the following are true:
- security updates or vendor support have ended
- recovery has failed or has never been demonstrated
- important changes repeatedly require workarounds
- one person or supplier controls essential knowledge or access
- incidents and emergency work are increasing
- the architecture blocks a committed strategic priority
- continued operation may breach a duty or contract
These are decision signals, rather than an automatic instruction to replace the platform.
Present the board with choices
Translate the issue without stripping away uncertainty. A useful board paper can fit on two pages.
Begin with the affected business service and consequence. Explain what clients or colleagues cannot do, which exposure exists and how the evidence has changed. Then compare the scenarios, costs and risks. State the requested decision and the next review point.
Use technical detail in an appendix. “Unsupported framework” becomes meaningful when connected to patch availability, likelihood of failure, affected data, recovery and the options for containment or replacement. Do not invent probabilities or insurance consequences to create urgency.
A phased proposal can preserve choice. Discovery may validate dependencies and cost before a large commitment. A first phase may remove a critical access risk or establish a migration path. Each gate needs explicit evidence and authority to stop.
The companion article on what legacy platforms hide from your profit and loss account explores the financial visibility problem. The article on what your IT team wishes the board understood addresses the translation between technical and commercial concerns.
Review debt as a portfolio
Technical debt crosses projects. A rushed integration in one programme becomes an operating cost for another team. Review material debt quarterly or alongside investment planning, with technology, service, risk and finance owners present.
Track whether high-priority items are being tolerated consciously, contained or repaid. Check whether new delivery is adding debt faster than the firm removes it. Retire entries only when evidence shows that the obligation has gone.
The purpose is not a pristine estate. It is to spend the firm's limited capacity deliberately. An imperfect system that supports the strategy, remains recoverable and has a managed plan can be acceptable. An apparently functional system that consumes change capacity and removes future options deserves board attention.
A structured template for estimating technical debt and presenting the decision is available below. Populate it with the firm's own budgets, change history, incidents and constraints. The result should make the trade-off visible without pretending the future can be forecast to the nearest pound.
