The same symptom has two very different causes — and misreading them is how companies lose years.
Have a question about this? Bring it to Aurelius.
More than 50% of technology companies are spending over a quarter of their entire IT budget servicing technical debt — and in the worst cases McKinsey documented, engineers were consuming 75% of their working hours on maintenance rather than creation. If you are sitting in a leadership meeting where every missed deadline is explained by technical debt, you are not alone. You are also not yet safe from being deceived — possibly by your team, possibly by yourself.
The standard guidance splits into two camps, and both are incomplete.
The first camp tells you to trust your engineers. If they say debt is the problem, believe them. Treat it as a technical question that non-technical leaders should not interrogate too hard. This counsel sounds respectful. It produces learned helplessness at the executive level and, occasionally, an engineering culture where slowness becomes permanent and unchallengeable.
The second camp tells you to push harder. Debt is an excuse. Ship faster. Break it into smaller tickets. This counsel sounds decisive. It produces systems that collapse under their own fragility, engineers who leave, and codebases that eventually cost more to rewrite than to have maintained.
Both camps miss the diagnostic question entirely. They assume you already know which problem you have. You do not. And the cost of misidentification is severe: the CIO documented by McKinsey who reduced engineering time on technical debt from 75% to 25% did not do so by pushing harder or by capitulating to every refactor request. He did it by first understanding precisely what was frozen and why. That distinction — knowing before acting — is the move that unlocked competitive capability his organization had not accessed in years.
Marcus Aurelius writes in Meditations Book 8: "If it is not right, do not do it; if it is not true, do not say it." The principle underneath this instruction is not merely ethical. It is epistemological. Before the question of action comes the question of reality. What is actually happening here?
Epictetus makes the same move from a different angle. In Discourses 1.1, he draws the foundational line between what is up to us and what is not. But notice what that exercise requires: you must first examine the situation clearly enough to categorize it correctly. Misidentification is not a neutral error. It is the error that cascades into every subsequent decision.
This reveals something important about the technical debt question specifically. The crisis version and the culture version look identical from the outside: slow delivery, missed commitments, engineers citing complexity. The difference is not visible in the symptoms. It is visible only in the structure of the system and the structure of the behavior around it.
This means a leader must resist the impulse to judge quickly — which is itself a Stoic discipline. The Stoic term is epoché: the suspension of judgment until examination is complete. A genuine technical debt crisis has objective characteristics. Deployments fail at measurable rates. Specific modules or services account for a disproportionate share of incidents. The codebase has identifiable hotspots where change consistently introduces regression. New engineers take months longer than expected to become productive in particular areas. These are observations, not interpretations.
A cultural performance of technical debt also has observable characteristics, but they are behavioral rather than structural. Refactoring efforts that never conclude. Debt retirement that consumes budget but produces no measurable improvement in deployment frequency or incident rates. Velocity that remains flat despite completed remediation work. Stories about technical debt that expand in scope each time they are discussed.
Marcus would recognize both patterns. The first is an obstacle in the path — real, material, addressable. The second is an assent to a narrative — an internal posture that has hardened into policy. And as he writes in Book 5: "The obstacle is the way." But only when the obstacle is real. When it is a story we have agreed to tell, the path is not through it. The path is through the agreement itself.
Begin with measurement, not sentiment. Ask your engineering leadership to produce three specific data sets.
First, a deployment frequency and failure rate map. You are looking for whether incidents are distributed across the system or concentrated. Genuine structural debt concentrates. Cultural performance does not produce this concentration — failures are distributed because the underlying issue is behavioral, not architectural.
Second, a hotspot analysis against time spent. Which modules consume the most engineering hours? Do those hours correlate with customer-facing incidents and delivery failures, or do they appear in areas that are theoretically important but practically dormant? If your engineers are spending time on debt remediation in systems that are rarely touched and rarely break, question whether the work is oriented toward real constraint relief.
Third, a remediation outcome log. For every significant investment in technical debt reduction over the last eighteen months, what changed measurably? Deployment frequency, incident rate, lead time for change, engineer onboarding time — McKinsey's research is clear that these are the metrics through which resolved technical debt expresses itself. If your organization cannot point to movement in these numbers following debt remediation work, you have a cultural explanation problem, not purely a technical one.
Once you have this picture, you can make decisions that are grounded rather than political. Genuine crises require dedicated remediation capacity — protected, sequenced, and owned. Cultural drift requires a different intervention: clearer ownership models, tighter coupling between debt claims and delivery commitments, and a budget conversation that links technical investment to delivery outcomes rather than technical purity.
Your budget process deserves its own rigor here. Turn Your Engineering Budget Into a Headcount and Roadmap Decision Tool exists precisely for this: making the budget a diagnostic instrument, not just an accounting record.
If your teams are struggling with the upstream confusion that generates debt in the first place — building systems that don't reflect the actual domain — Stop Your Engineering Team from Building the Wrong Thing Twice addresses the domain modeling discipline that prevents accumulation.
And if slowness is partly structural in your delivery process rather than purely architectural, Ship Faster by Killing Long-Lived Feature Branches for Good closes one of the most common sources of invisible debt accumulation.
Before you close this tab, request one specific document from your engineering leadership: a list of the five most frequently modified files or services in your codebase over the last six months, mapped against the incident reports and delivery delays attributed to technical debt in the same period. You are not asking for opinion. You are asking for a join between two objective data sets. If your engineering leadership cannot produce this within a week, that is itself diagnostic information — it suggests your observability into your own system is insufficient to distinguish crisis from culture. If they produce it and the correlation is strong, you have a real structural problem and a place to start. If the correlation is weak or absent, you have a harder conversation ahead about what your debt remediation budget is actually buying. Either answer is more useful than continuing to accept the label without examining what it covers.
If the diagnostic work above surfaces questions about how your team evaluates and sizes work before it enters development, AI Feasibility Assessment for Engineering Projects offers a structured approach to reducing the failed-project rate that seeds future debt.
For teams where backlog management has become its own form of organizational debt — endlessly refined, rarely resolved — AI Backlog Grooming for Engineering Teams reduces the refinement overhead that pulls engineers away from delivery.
And if your sprint reviews have become the ritual through which vague debt narratives are rehearsed rather than examined, Stop Running Sprint Reviews That Waste Every Engineer's Friday Afternoon restructures that ceremony into an actual accountability surface.
Go deeper with Aurelius
Apply this to your actual situation. Aurelius will meet you where you are.
Start a session