How Engineers Can Convince Executives That Technical Debt Is a Business Problem

“The extra effort that it takes to add new features is the interest paid on the debt.” — Martin Fowler, British software developer, author of Technical Debt, 2019, and international public speaker on software development

Engineers contend with technical debt daily. But what exactly is technical debt?

Technical debt is the future cost created when an organization chooses a quick or suboptimal technical solution today instead of a more sustainable one.

Like financial debt, the initial shortcut may provide an immediate benefit, but carrying it can create recurring “interest” through additional maintenance, rework, delays, and complexity.

Schedule pressure, changing requirements, outdated technology, architectural decisions, inadequate testing, and deliberate shortcuts can all create debt that becomes increasingly expensive as a system evolves.

Engineers must learn to convince executives that technical debt is a business problem. But how can engineers do this?

Consider the three ways below:

Translate Technical Debt Into Dollars

Executives rarely make investment decisions because engineers say the architecture is messy.

Explain technical debt in terms of labor hours, operating costs, rework, maintenance costs, and lost productivity.

Quantify how much engineering time the debt consumes. One empirical study found that developers reported wasting an average of 23% of their working time because of technical debt.

Then show executives how that time and engineering capacity could be used instead.

McKinsey reports that reducing technical debt can free engineers to spend substantially more time working on value-generating products and services.

Reducing technical debt is a business decision because it requires shifting resources from engineering effort to another.

One way to convince executives that technical debt is a business problem is to translate it into dollars.

Another way is to connect technical debt to business risk.

Connect Technical Debt to Business Risk

Don’t simply say, “We need to refactor this system.” Explain what happens to the business if nothing is done: slower releases, higher costs, reliability problems, security exposure, customer disruption, or difficulty responding to changing market requirements.

Translate the technical problem into a cause-and-effect statement: “If we continue with X, the probability of Y increases, which could cost us Z.”

This turns an engineering concern into a risk-management decision executives can evaluate.

Most importantly, distinguish between debt that can safely remain and debt that threatens strategic objectives.

The Software Engineering Institute recommends identifying specific technical-debt items and documenting their consequences so organizations can evaluate lifecycle costs and determine which debt warrants action.

Deciding whether to alleviate or accept technical debt is essentially a cost-benefit decision.

Resolving a technical debt risk doesn’t guarantee the company will save money. It only means the organization has decided the benefits of alleviating technical debt outweigh the costs of accepting it.

Two ways to convince executives that technical debt is a business problem are to translate it into dollars and connect technical debt to business risk.

A third way is to present technical debt as an investment decision.

Present Technical Debt as an Investment Decision

Don’t ask executives to “give engineering time to clean up the code.” Present alternatives such as investing now, reducing the debt incrementally, or accepting the debt and its ongoing business consequences.

Show the expected return from paying down the debt: faster development, fewer defects, greater reliability, lower maintenance costs, and quicker time to market.

McKinsey specifically recommends treating technical debt as a business issue and connecting remediation to strategic priorities such as simplification and risk reduction.

Give executives a recommendation, not just the problem. “I recommend investing $X now because we expect it to reduce Y and improve Z” is much more persuasive than “Our technical debt is getting bad.”

Presenting executives with a recommendation shows you have analyzed the situation. However, ensure you’ve done the analysis beforehand and are ready to brief its details if there are questions.

Three ways to convince executives that technical debt is a business problem are to (1) translate it into dollars, (2) connect technical debt to business risk, and (3) present technical debt as an investment decision.

Engineers contend with technical debt daily.

Schedule pressure, changing requirements, outdated technology, architectural decisions, inadequate testing, and deliberate shortcuts can all create debt that becomes increasingly expensive as a system evolves.

Your career promotion potential depends on your ability to convince executives that technical debt is a business problem.

“Grab the reins” and handle technical debt proactively.

Call to Action

• Explain technical debt in terms of labor hours, operating costs, rework, maintenance costs, and lost productivity.

• Distinguish between debt that can safely remain and debt that threatens strategic objectives.

• Give executives a recommendation, not just the problem. Present alternatives such as investing now, reducing the debt incrementally, or accepting the debt and its ongoing business consequences.

“As an evolving program is continually changed, its complexity… increases unless work is done to maintain or reduce it.” — Meir “Manny” Lehman, British software engineer and professor in the School of Computing Science at Middlesex University.

References

• Ozkaya, I., & Nord, R. — Carnegie Mellon University Software Engineering Institute. Managing the Consequences of Technical Debt: 5 Stories from the Field, May 13, 2019. Defines technical debt and explains how short-term design and implementation decisions can increase future costs and impede system evolution.

• Besker, T., Martini, A., & Bosch, J. “Software Developer Productivity Loss Due to Technical Debt—A Replication and Extension Study Examining Developers’ Development Work.” Journal of Systems and Software, 2019. The study reports developers losing an average of approximately 23% of their working time because of technical debt.

• McKinsey & Company. Breaking Technical Debt’s Vicious Cycle to Modernize Your Business, 2023. Examines technical debt as a business and financial issue, including its effects on engineering capacity, modernization, operating costs, and organizational performance.

• Carnegie Mellon University Software Engineering Institute. 5 Recommendations to Help Your Organization Manage Technical Debt, 2024. Discusses technical debt at the program level, including architecture, testing, documentation, technology refresh, sustainment, cybersecurity, and lifecycle consequences.

• McKinsey & Company. Tech Debt: Reclaiming Tech Equity, 2020. Recommends that organizations treat technical debt as a business issue rather than merely a technology problem and link technical-debt reduction to business value, strategic priorities, and risk reduction.

Being a confident, engaging, and effective STEM speaker is a vital personal and professional asset. With more than 40 years of engineering experience and more than 30 years of award-winning public speaking experience, I can help you reduce your presentation preparatory time by 50%, overcome your fear of public speaking and be completely at ease, deliver your presentations effectively, develop your personal presence with your audience; and apply an innovative way to handle audience questions deftly.

Working closely with you, I provide a customized protocol employing the critical skills and tools you need to create, practice, and deliver excellent STEM speeches and presentations. Let’s connect and explore how I can help you become the exceptional speaker you were meant to be. Please reach out to me at fr***@*****************ed.com or 703-509-4424 for a complimentary consultation. Schedule a meeting with me at calendly.com/frankdibartolomeospeaks

©2026 DiBartolomeo Consulting International (DCI), LLC. All Rights Reserved. May not be used without permission.