The interpretation problem
Technical debt is almost always visible before it turns critical. The signs are there; the trouble is that they are almost always misread. Estimates that keep slipping become a planning problem. Recurring bugs become a code quality problem. Developers who leave become a compensation or management problem. Slow releases become a process problem.
These framings aren't entirely wrong, but they are incomplete. When these symptoms appear together and persist over time, the underlying cause is almost always structural: a system that is no longer aligned with the organisation producing it. Treating them as people or process problems leads to interventions that don't remove the problem; they just push it further down the road.
This guide organises the signs into three levels: in the team's day-to-day flow, in delivery, and in the numbers visible to the business. Recognising them is the prerequisite for knowing where and how to intervene.
In the team's day-to-day flow
The earliest signs of technical debt show up in developers' day-to-day work. They are also the hardest to spot from the outside, because they require understanding not just what the team produces but how it produces it.
The first sign is systematic variance in estimates. Not the occasional wrong estimate, which is normal, but variance that grows over time. A team that regularly underestimates by 50–100% doesn't have an estimating problem; it has a system predictability problem. Features take longer than expected because hidden dependencies multiply the side effects. Every change requires manually tracing the impact on parts of the code that shouldn't be involved but are. When estimates keep slipping even though the team is experienced and has a solid method, the variance isn't noise: it's a signal. (On its own this isn't enough: unstable requirements or a fast-growing team produce the same variance. The distinguishing factor is that technical debt generates variance even on small features and in well-understood areas of the system.)
The second sign is knowledge silos. Every team has areas of the system that only one or two people genuinely understand. The question to ask is: what happens when that person is on holiday, off sick or leaves? If the answer is "that part grinds to a halt" or "we have to wait for them", that dependency is already an operational risk. Slow onboarding is often a related sign: the system is so dense with implicit assumptions that a new developer takes months to work out where they can safely make changes.
The third sign is high cognitive load in code review. A pull request that changes fifty lines but takes two hours to review, not because those fifty lines are complex in themselves but because it's hard to work out the impact on the rest of the system. When reviews turn into exercises in tracing dependencies rather than assessments of the logic being implemented, the system's coupling is already a problem. A related sign: areas of the code nobody wants to touch, where reviews are superficial by unspoken agreement.
The fourth sign is the growth of workarounds. Every system accumulates workarounds over time; the problem is when workarounds become the standard path. When the answer to "how do we do X?" is "we use this undocumented mechanism someone bolted on three years ago", the underlying abstraction no longer reflects the real use cases. Workarounds are local adaptations to structural constraints; their proliferation is proof that the structural constraints are widespread.
In delivery
The signs in delivery are more visible because they directly affect the ability to release value. They are also the easiest to measure, which makes them a good starting point for anyone wanting to quantify the impact of the debt.
The most direct sign is growing cycle time. Cycle time — the time from first commit to production deployment — is a reliable proxy for the system's operational complexity. Cycle time that grows quarter on quarter without a corresponding increase in feature complexity shows that the system is putting up growing resistance to change. This growth is often not linear: there's an apparent plateau, then a sudden jump once the debt crosses a critical threshold.
A closely related sign is release clustering. When a team tends to release only on certain days and at certain times, avoiding Friday afternoons or high-traffic periods, it isn't necessarily down to a lack of confidence in its own abilities: it's because the system is less predictable than it should be. Risky releases aren't a process problem; they're a sign that the cost of every deployment carries an element of uncertainty that shouldn't be there. For a practical guide to structuring your CI/CD pipeline so it doesn't accumulate process debt, see real-world CI/CD: from pipeline to delivery flow.
A rising bug rate is another specific sign. Not the absolute number of bugs — which depends on the volume of features developed — but the trend normalised per feature shipped. When each new feature introduces more bugs than the last, the cause is rarely the quality of individual developers. More often it's the system's coupling: hidden dependencies mean every change has unpredictable side effects. The bug rate is also the sign that's easiest for the business to read: when the team is fixing more than it's building, even a CEO with no technical background can tell something is wrong.
Adding developers doesn't increase velocity: this is the sign management finds hardest to accept, because it contradicts the intuition that more resources produce more output. In a system with high technical debt, adding people first and foremost increases the coordination required. More developers have to understand a more complex system, coordinate on interdependent areas, and avoid treading on each other's toes in coupled modules. A team that doesn't scale with headcount doesn't have a people problem; it has an architecture problem. (It's worth noting that this effect — known as Brooks's law — shows up in any software project of a certain complexity, not only where technical debt is present. The sign becomes specific when the slowdown is disproportionate to the size and complexity of the features being requested.)
In the numbers visible to the business
The signs at business level are the last to appear — they show up once the debt is already entrenched — but they are also the easiest to measure without access to the code. These are the numbers a CFO or a CEO can read directly.
The first is the rising cost of features. If a similar feature cost two weeks six months ago and costs five today, without a proportional increase in product complexity, the delta is almost always technical debt. It isn't an estimating problem: it's that every new feature sits on a more complex architecture, cuts across more coupled modules, and needs more coordination between teams. The cost of adding features isn't constant in a system that grows without being governed; it rises.
The second is a growing cloud bill with no correlation to business growth. Cloud costs that explode without a corresponding rise in traffic or transactions almost always point to architectural inefficiencies: unoptimised queries burning unnecessary CPU, microservices calling each other redundantly, batch jobs reprocessing data that's already been processed. This is the accounting-level sign of architectural debt. (Before attributing the growth to debt, it's worth ruling out governance and sprawl issues — unused resources, forgotten environments, redundant licences — which FinOps analyses put at a third of cloud waste on average. If those items are under control and costs keep rising with no justification in traffic, the remaining delta is often architectural.)
The third is selective turnover among senior developers. When your best developers leave citing technical frustration, the implicit message is that the system has become an uncomfortable place to work. Senior developers have a high tolerance for necessary complexity; they have a low tolerance for accidental complexity — the kind that slows things down for no reason, forces undocumented workarounds, and turns every change into an adventure. When this profile of developer chooses to go elsewhere, the sign should be taken seriously: it's the loss of the knowledge that was keeping the system manageable despite the debt. (Turnover among senior staff does, however, need investigating alongside other variables: compensation, growth opportunities and management quality consistently rank among the top causes in industry surveys. Technical frustration is rarely the only reason, but on top of conditions that are already less than competitive, it often becomes the deciding factor.)
The fourth, less obvious, sign is a roadmap that becomes unstable. When the business has stopped asking for dates because it knows the estimates won't hold, the debt has already reached the point where it affects strategic planning. An unstable roadmap isn't a product management problem; it's a system predictability problem.
Reading the signs together
None of these signs is conclusive on its own. Estimates that blow out can have various causes. A high bug rate might be down to one specific area, not the whole system. A developer leaving might have personal reasons. The cost of features might reflect genuine product complexity.
The signal that matters is not the single indicator but the cluster. When variable estimates, risky releases, a rising bug rate and onboarding difficulties appear together and persist over time despite local fixes, the cause is almost certainly not local. It's systemic.
The correct reading of these signs isn't "we have inadequate people or processes". It's: "the system we're using is no longer aligned with the organisation producing it. Where exactly is the misalignment, and what is it costing us for every day we don't act?"
What to do in practice
- Build a map of the signs present: for each of the signs described, answer with a number or a yes/no. Is cycle time rising? By how much, over what period? Is the bug rate climbing? In which area of the system? Is onboarding slow? How long before a new developer can contribute independently? The map doesn't need to be perfect: it needs to be concrete enough to identify where the pressure is highest.
- Look for clusters, not individual indicators: an isolated sign can have various causes. Three or four signs overlapping in the same area of the system almost certainly point to structural debt in that area. The area that lights up the most indicators is almost always the one worth tackling first.
- Translate the signs into concrete costs: "cycle time has doubled" is an observation. "Cycle time has doubled, which means this feature that should have taken two weeks took five: three extra weeks of senior developer time, multiplied by N similar features a year" is an argument. The Consistency Impact Calculator helps you make this translation in a structured way.
The QMates perspective
The first step we take when we join an organisation isn't reading the code. It's measuring the signs: cycle time by area of the system, bug rate by type of change, average onboarding time, release frequency and complexity. Read together, these numbers show where the debt has already started blocking the flow of value — often with surprising accuracy.
What we almost always find is that the signs were already there six to twelve months before the problem became obvious to management. They had been read as local, temporary problems and fixed with tactical adjustments that never touched the structural cause. Unresolved technical debt doesn't stabilise: it compounds. Every month of delay before you intervene raises the cost of the intervention that follows.
The next step, once you've recognised the signs, is knowing how to measure the debt so it can be managed as a business decision. The fourth article in this series covers how to measure it: from architecture to workflow.