Every engineering organization I've ever worked with has a "technical debt problem." They have backlogs full of debt items. They've estimated the cost. They've pleaded for refactoring sprints. They've built dashboards showing code quality metrics trending in the wrong direction.
And yet the debt keeps accumulating.
After two decades of leading engineering teams through turnaround situations, I've come to a controversial conclusion: most of what organizations call "technical debt" isn't actually technical at all. It's decision debt—the accumulated cost of decisions deferred, decisions avoided, decisions made by default rather than by design.
The fix for decision debt isn't more refactoring time. It's better organizational decision-making. And until you address that root cause, your technical debt will keep growing no matter how many "debt sprints" you run.
The Real Cost Everyone's Measuring Wrong
The statistics on technical debt are staggering. Engineers spend roughly 33% of their time dealing with it—13.4 hours per week on average. Organizations with high technical debt spend 40% more on maintenance and deliver new features 25-50% slower than competitors. CISQ estimates technical debt costs US companies $1.52 trillion annually.
But here's what those numbers miss: they measure the symptoms, not the disease.
When an engineering team spends hours working around inconsistent API patterns, that's not a code problem. It's the residue of three different teams making three different integration decisions without coordination.
When deployment takes four hours because the build system has seventeen special cases, that's not a build system problem. It's the accumulation of every team that needed an exception and no one empowered to say no.
When the data model has seven different ways to represent a customer, that's not a schema problem. It's the history of product decisions made without architectural oversight, each team solving their immediate need without regard for the whole.
The technical manifestation is real. The cost is real. But the root cause isn't technical. It's organizational indecision crystallized into code.
What Decision Debt Actually Looks Like
Decision debt accumulates through several patterns I see repeatedly:
The Deferred Decision. A team needs to choose between two architectural approaches. Both have merit. The decision is hard. Rather than make it, leadership says "let's revisit this next quarter." Next quarter comes. The decision is still hard. Meanwhile, both approaches get partially implemented because individual contributors need to make something work. Now you have two incomplete solutions, neither fully supported, and the cost of choosing has tripled.
The Non-Decision Decision. No one explicitly chooses a technology, pattern, or approach. But teams need to ship, so individuals make local choices. Those local choices compound. Two years later, you have five different logging frameworks, three different authentication mechanisms, and four different approaches to error handling. No one decided to have this chaos. It emerged from the absence of decision.
The Distributed Decision. A decision that should be made once, centrally, gets made dozens of times, locally. Every team chooses their own database. Every service defines its own API conventions. Every frontend picks its own state management approach. The decisions aren't wrong individually—they're wrong collectively. And the collective wrongness wasn't a decision anyone made.
The Contested Decision. Leadership makes a decision. Part of the organization disagrees. Rather than committing or escalating, the disagreeing faction implements workarounds. Now you have the official approach and the shadow approach, with translation layers between them. The decision was made, but it wasn't resolved.
The Expired Decision. A decision made years ago under different constraints continues to govern current behavior. No one has revisited it. No one owns it. But it shapes everything. When someone finally challenges it, no one can explain why it was made or whether the original constraints still apply. The decision has become institutional muscle memory divorced from any rationale.
Each of these patterns produces what looks like technical debt. But you can't refactor your way out of organizational dysfunction.
Why "Tech Debt" Is the Scapegoat
Here's the uncomfortable truth: technical debt is a convenient narrative because it places the problem safely inside engineering.
If the problem is "we have too much tech debt," the solution is more engineering time for cleanup. That's a resourcing conversation. It stays within familiar boundaries.
But if the problem is "we're organizationally incapable of making and sticking to architectural decisions," that's a different conversation entirely. It implicates product leadership, organizational structure, governance processes, and executive attention. It's harder to address. It's harder to even discuss.
So we call it "tech debt" and ask for refactoring sprints.
I've watched teams spend months refactoring systems only to see the same patterns re-emerge within a year. They fixed the code but not the decision-making process that created the mess. The debt came back because the factory producing it never stopped.
Research confirms this pattern. Studies of architectural design decisions that incur technical debt found that these decisions "have serious impact on the quality of a software system, and can cost significant time and effort to be changed." But the same research shows that many of these debt-incurring decisions were made inadvertently—not through deliberate technical choices, but through the absence of intentional decision-making.
The majority of teams use their own customized decision-making approaches rather than systematic ones. Architects often experience delays and omissions in the decision-making process due to lack of structured approaches. When decisions do get made, they're frequently lost—no record, no rationale, no ability to revisit them when circumstances change.
This is decision debt masquerading as technical debt.
The Architecture Contention Problem
Nowhere is decision debt more visible than in architectural contention—situations where multiple valid approaches compete without resolution.
Martin Fowler described an architectural decision as "a decision that you wish you could get right early." Grady Booch elaborated: "a design decision that is costly to change."
That costliness is the key. Architectural decisions have high change costs precisely because they're hard to reverse. They become load-bearing. Other decisions stack on top of them.
When an organization fails to make architectural decisions clearly, the cost compounds in three ways.
First, parallel implementations multiply work. Without a decision, different teams implement different approaches to the same problem. That's N times the development cost for what should have been solved once.
Second, integration surfaces explode. When every team can make architectural choices independently, the number of integration patterns grows combinatorially. Each service potentially speaks a different protocol, uses different conventions, expects different behaviors. The integration tax grows with every new component.
Third, knowledge fragments. When there's no standard approach, there's no standard expertise. Every system requires specialized knowledge. New team members can't transfer skills from one area to another. Institutional knowledge doesn't accumulate—it scatters.
Spotify engineering explicitly addresses this through Architecture Decision Records (ADRs): "When our organization changes, we sometimes have to move ownership of systems from one team to another. In the past, a lot of context/knowledge was lost when this took place, triggering a decrease in productivity. This problem has become less severe with the introduction of ADRs."
The tool isn't the point. The discipline is the point—forcing explicit decisions with recorded rationale so that future teams understand not just what was decided but why.
The Signals You're Dealing with Decision Debt
How do you distinguish decision debt from genuine technical debt? Look for these patterns:
The debt is social, not technical. Multiple valid approaches coexist because different people or teams advocated for different solutions, and no one resolved the conflict. The code reflects organizational politics rather than technical requirements.
The debt regenerates after cleanup. You refactor a system, and similar patterns emerge elsewhere within months. The problem isn't the old code—it's the ongoing absence of decision-making that creates new messes at the same rate you clean old ones.
No one can explain why. When you ask why the system is built a certain way, the answer is "that's how it's always been" or "different teams did different things" or "I don't know who decided that." Genuine technical debt has rationale—shortcuts taken for known reasons. Decision debt has amnesia.
The owners are unclear. Real technical debt has an owner: the team that took the shortcut, the system that needs the investment. Decision debt often has no owner because no one was empowered to decide. The debt belongs to everyone and therefore no one.
The problem is at the boundaries. Decision debt tends to manifest at integration points between teams, services, or systems—exactly where cross-cutting decisions should have been made but weren't. Genuine technical debt tends to concentrate within components.
Fixing it requires negotiation, not just coding. If addressing the "debt" requires getting three teams to agree on an approach going forward, you're dealing with a decision problem. Technical debt yields to engineering effort alone.
Clearing Decision Debt
The fix for decision debt isn't more engineering time. It's organizational change.
Establish decision rights. For every category of architectural decision, someone needs clear authority to make that decision. Not consensus authority. Not "we'll discuss until everyone agrees" authority. Actual authority to decide, even when people disagree, with the expectation that others will commit once the decision is made.
This is uncomfortable. Engineers often prefer consensus. But consensus-seeking without time bounds produces non-decisions. And non-decisions produce decision debt.
Document decisions with rationale. Not just what was decided, but why. What constraints were in play? What alternatives were considered? What would need to change for this decision to be revisited?
This isn't bureaucracy. It's institutional memory. When circumstances change, you need to know which decisions should be reconsidered versus which still make sense. When ownership transfers, new teams need to understand the "why" behind the "what."
Create forcing functions. Decisions deferred indefinitely are decisions never made. Put time bounds on open questions. If a decision isn't made by date X, a default kicks in. Make the cost of indecision explicit rather than invisible.
Treat architecture as a product. Someone should own the overall system architecture the way a product manager owns a product. They don't make every decision, but they're accountable for coherence. They can push back when local decisions undermine global goals. They maintain the vision that keeps local choices aligned.
Distinguish reversible from irreversible. Not every decision needs heavyweight process. Jeff Bezos distinguishes "one-way doors" (hard to reverse, need careful consideration) from "two-way doors" (easy to reverse, bias for action). Calibrate your decision process to the stakes.
Close the loop. When a decision is made, communicate it clearly. When a decision is revisited, explain why. When a decision is violated, address it. Decisions that are made but not enforced create the worst kind of debt—the illusion of resolution with the reality of chaos.
The Leadership Imperative
Here's what engineering leaders need to understand: decision debt is your responsibility in a way that technical debt isn't.
Technical debt can accumulate despite good leadership—teams make reasonable tradeoffs under pressure, shortcuts are sometimes the right call, and cleanup legitimately competes with new features for resources.
But decision debt accumulates because of leadership failure. It accumulates when leaders don't establish decision rights. When leaders don't create frameworks for choices. When leaders allow contested decisions to fester rather than forcing resolution. When leaders don't invest in the governance mechanisms that keep local decisions aligned with global goals.
Every team that's making independent architectural choices because no one defined standards—that's a leadership failure. Every integration nightmare that exists because three teams built three solutions to the same problem—leadership failure. Every refactoring effort that has to navigate political minefields because people still disagree about the "right" approach—leadership failure.
The fix for decision debt is executive attention to organizational decision-making. It's not glamorous. It doesn't ship features. But it determines whether your engineering organization compounds capability over time or compounds chaos.
The Reframe
Stop talking about technical debt as a technical problem requiring technical solutions.
Start talking about decision debt as an organizational problem requiring organizational solutions.
When someone points to a mess in the codebase, ask: "What decision wasn't made that created this?" When you see redundant implementations, ask: "Who was empowered to choose, and did they?" When cleanup efforts fail to stick, ask: "What's the decision-making process that will prevent this from recurring?"
Technical debt is real. The Stripe finding that developers spend 33% of their time on it represents real cost. But much of what we call technical debt is actually the fossilized residue of organizational dysfunction—decisions deferred, decisions fragmented, decisions contested, decisions forgotten.
You can't refactor your way out of decision debt. You have to decide your way out.
That means establishing clear decision rights. Documenting decisions with rationale. Creating forcing functions that prevent indefinite deferral. Treating architecture as a product with an owner. And accepting that sometimes, making a decision—any reasonable decision—beats endless analysis in search of the perfect choice.
The teams I've seen transform their "technical debt" problems didn't do it through massive refactoring efforts. They did it by changing how decisions got made. Once the decision factory was fixed, the debt stopped accumulating. And then, finally, the cleanup efforts started to stick.
The code is just a mirror. It reflects the decisions you made—and the decisions you didn't.
What's the decision debt in your organization? I'd be curious to hear what patterns you've seen and how you've addressed them.