How Much Tech Debt Is Too Much?

checked boxes deteriorate from tidy columns to a chaotic cluster in an illustration of the concept of tech debt

Managing Tech Debt: A Strategic Imperative for Innovation

We’ve noted that tech debt is inevitable in innovation. The question isn’t whether your organization has it but how much and how well it’s managed. Proactive leaders deliberately decide where and how much tech debt to incur during product development. Once product-market fit is achieved, they implement processes to document and address tech debt during each sprint.

Whether you tackle tech debt continuously or set aside targeted time for it, you need to keep it documented somewhere. Without these measures, tech debt becomes an uncontrolled burden, tracked only by tribal knowledge. This creates single points of failure, making organizations dependent on specific individuals to fix increasingly frequent and severe failures.

Unlike financial metrics, tech debt lacks clear quantifiable indicators. To assess it, we analyze engineering, product, and go-to-market operations for conditions correlated with tech debt - if you will, the Indicator of Tech Debt (IOTD). Here are some of them - your mileage may vary.

Critical Signs of Risk

A key symptom is system fragility, where once-reliable systems fail unpredictably. Early warning signs include low deployment frequency, high change-failure rates, struggles to deploy code, and outages — key conditions measured by DORA metrics.

Another critical sign of risk is a pivoting and changing product roadmap-to-nowhere. Sure, as Richard Hartmann said, high-performing teams can enjoy or even thrive on, “an ever-changing roadmap, or very short feedback cycles.” But just flippy-flopping and making roadmaps on which you fail to execute? That’s a clarion-trumpeted danger signal that your leadership is reactive, not decisive about your commitment to great products and engineering excellence.

Have a look at your product roadmaps for the past three years, and consider how often things changed, how often your teams failed to deliver on the goals, and how “stuck” your teams feel. “Stuckness occurs,“ said Andy Johns, “when decisions aren’t made.“ To this, we add, “Or when decisions are regularly changed.“ All these things — especially changing decisions, which lead to abandoned work, demoralized staff and managers, and a loss of trust in leaders — are all correlated with overwhelming quantities of tech (and process, and policy) debt.

Struggling to Deploy

Start by asking engineering managers about testing reliability. In debt-laden environments, engineers may tolerate unreliable tests or “flaky” tests that fail intermittently. While a single flaky test may seem minor, the cumulative effect can be costly. Diagnosing and resolving these issues can take hundreds of hours per sprint, diverting valuable resources.

Flaky tests are a precursor to deployment struggles. Framing the issue in business terms can highlight its impact for executives:

  1. Tech debt cultivates toil and apathy, which are correlated with unreliable (“flaky”) tests.
  2. Flaky tests lead to failed deploys.
  3. Failed deploys delay launches and prevent upgrades.
  4. Delayed launches and upgrades lead directly to customer churn.

Lack of Engineering Excellence

“Engineering excellence” — what Nicole Forsgren, Jez Humble, and Gene Kim describe as, “practices consistent with high-performing technology organizations” — helps organizations incur and manage tech debt effectively.

One simple, easy-to-surface, yet significant IOTD is “log discipline:” how well teams document their work. Bad commit logs (leaving vague notes like “update” or “changes”) are tightly correlated with high levels of tech debt.

The link is that people in debt-laden organizations don’t have time to do things properly. Not every place with bad commit messages has tech debt, but most places with tech debt have bad commit messages. Lack of clarity compounds inefficiencies, making it harder for architects and managers to trace development history and resolve issues quickly. Conversely, automated enforcement of commit log references to project management tickets is a key enabler of improved deployment.

Operational Disruptions

As debt — and dependence on “quick fixes” and “hacks” — accumulates, outages and incidents become more frequent, increasing downtime, consuming engineering hours, frustrating customers, and worsening relationships between engineering and business stakeholders. This erosion of operational stability often leads to churn and contraction, amplifying the organization’s challenges.

Subtle Indicators: Engineer Burnout and Intuition

Engineers often sense inefficiency when working with debt-heavy systems. Gavin de Becker’s The Gift of Fear emphasizes trusting instinctive reactions to danger. Similarly, engineers must heed their intuition. Gut feelings often arise in environments dominated by shortcuts, postponed fixes, or declining code quality.

When engineering operations are reduced to feature factories churning out new capabilities, engineers may hesitate to voice concerns, fearing retribution for interfering with organizational inertia. This silence undermines their role as the first line of defense against poor practices, further entrenching systemic inefficiencies.

Managing and Reducing Tech Debt

In 2006, Martin Fowler and Kent Beck introduced the concept of “code smell"—superficial issues indicating deeper problems. Like a bad odor, tech debt becomes normalized over time, making it harder for insiders to recognize.

Outsiders like consultants can often identify these issues more quickly, unencumbered by the organization’s ingrained habits — but you can do it yourself, too. Frameworks like those described in Team Topologies by Matthew Skelton and Manuel Pais offer solutions. They advocate structures that help teams identify and address tech debt patterns before they escalate.

At Evertas, we assess tech debt by posing targeted questions that uncover systemic challenges. This provides a high-level view of an organization’s current state, enabling leadership to identify areas for intervention. While blunt, this method effectively highlights opportunities for improvement.

Organizations capable of introspection can conduct their own assessments. Regularly evaluating tech debt across technical and organizational dimensions is invaluable. Structured processes help teams mitigate debt and foster resilience.


Tech debt is an unavoidable part of innovation, but its impact depends on how it’s managed. Organizations that proactively assess and address tech debt can avoid the pitfalls of fragility, inefficiency, and burnout. Companies can reduce tech debt while maintaining operational resilience by fostering transparency, empowering engineers to voice concerns, and implementing structured processes.

If your organization struggles with tech debt, seeking expert guidance might be the first step toward regaining control.