In my last article, I explored the value of taking a concept from one domain and applying it in another. This practice stretches our thinking and helps us see patterns across systems. Some of the most powerful insights don’t come from inventing something new - it’s from translating an existing idea into a fresh context.
Today’s concept comes from software architecture: technical debt. At first glance, it seems like an insider term that belongs only to software engineers. But when you unpack it, it becomes a powerful lens for understanding decisions in governance, leadership, and innovation.
Quick wins can feel smart in the moment. They create momentum, please stakeholders, and deliver visible results. But every shortcut has a cost. When we fail to account for that cost, we’re not just buying time — we’re borrowing from the future. And the future always comes knocking.
Part I. What Technical Debt Really Means
In software, technical debt describes the tradeoff between speed and sustainability. A development team might cut corners in design or testing to ship a feature faster. In the short term, the shortcut looks like progress. But the system becomes harder to maintain, bugs multiply, and adapting to new requirements gets slower.
(Image: TechTarget)
Like financial debt, technical debt carries interest. Each future change takes longer and costs more because of the shortcuts buried in the past.
But here’s the nuance:
Technical debt isn’t just about developers writing messy code.
It often originates from leadership decisions: executives pushing for unrealistic deadlines, or product managers prioritizing new features over system stability.
It can come from organizational shifts: mergers, changing strategies, or funding cuts that force compromises.
Sometimes it’s even deliberate: “ship now, clean up later” is a strategy teams use when speed matters most.
This nuance matters because it shows that debt isn’t a “tech problem.” It’s a system problem that reflects how leadership, strategy, and teams make choices under pressure.
Part II. Debt Beyond Software
The beauty of technical debt is that it travels well as a metaphor. Once you understand it, you begin to see it everywhere:
Policy Debt
Governments often push policies quickly to respond to crises or political pressure. The gaps show up later as amendments, enforcement costs, or unintended consequences. The quick win creates policy debt.
Example: The U.S. Affordable Care Act rollout in 2013. The policy was passed quickly with major gaps in implementation planning. The Healthcare.gov website collapsed under demand, and states struggled with uneven systems. Billions were later spent fixing the rollout.
Organizational Debt
Leaders sometimes delay investing in training, process, or culture. Things appear to move faster, but over time, turnover rises, productivity falls, and inefficiencies compound. That’s organizational debt.
Example: Wells Fargo’s sales scandal in the 2010s. Short-term incentives pushed employees to open millions of fake accounts. Leadership celebrated “wins” in account growth, but the debt came due in fines, reputational loss, and cultural collapse.
Strategic Debt
Organizations sometimes prioritize short-term wins over long-term positioning. Leadership may chase quick revenue, market share, or political gains, but in doing so they underinvest in resilience, adaptability, or strategic clarity. Over time, the organization loses direction, competitors outpace it, and opportunities vanish. That’s strategic debt.
Example: Blockbuster clung to its brick-and-mortar model and late-fee revenue, delaying investment in streaming. The short-term strategy kept cash flowing, but the debt came due when Netflix captured the digital market and Blockbuster collapsed.
Innovation Debt
The most famous story here is Kodak.
In 1975, Kodak invented the digital camera. Leadership shelved it to protect their profitable film business.
That shortcut preserved revenue in the short term but created innovation debt — a widening gap between Kodak’s choices and the digital future.
Competitors invested heavily, while Kodak fell behind. By 2012, the debt was unpayable, and the company filed for bankruptcy.
Contrast this with Netflix, which started as a DVD rental service. Instead of clinging to their profitable base, they deliberately “paid down debt” by investing in streaming — even when it hurt DVD revenues. That choice kept them ahead of the curve.
Part III. How Software Teams Deal with Technical Debt
If we’re going to borrow this concept across domains, we also need to borrow the practices for managing it. Here’s how software teams prevent technical debt from overwhelming them — and what leaders in other fields can learn.
Code Reviews and Refactoring (Discipline in the Details)
In Software: Teams regularly review each other’s code and clean up shortcuts before they pile up. They dedicate cycles to “refactoring” — restructuring code to make it more maintainable.
In Leadership/Organizations: This is the equivalent of process reviews and after-action reflections. Instead of letting inefficiencies build, leaders create time to examine what’s working and fix weak structures before they collapse.
That’s where disciplined frameworks come in:
Kanban: Visualizes work in progress, makes bottlenecks visible, and prevents teams from taking on more than they can handle. Just like a developer backlog for technical debt, Kanban keeps organizational debt from becoming invisible.
TQM (Total Quality Management): Builds quality into every step of a process rather than patching problems later. It’s the governance-level version of refactoring code early and often.
Continuous Improvement (Kaizen): Small, incremental fixes that prevent problems from compounding. In software, it’s cleaning up the codebase regularly; in organizations, it’s daily discipline around processes, meetings, and workflows.
Lean: Focuses on eliminating waste and maximizing value. Where software teams aim for clean, maintainable code, Lean organizations aim for streamlined systems that don’t pile up unnecessary “organizational debt.”
Together, these approaches institutionalize what software teams do intuitively: make debt visible, prevent it from compounding, and build resilience into the system itself.
Technical Debt Backlogs (Making Debt Visible)
In Software: Teams don’t just ignore debt; they track it. Many agile teams keep a “technical debt backlog” where known shortcuts are logged. This keeps debt from becoming invisible.
In Leadership/Organizations: The equivalent is a risk or debt register. Leaders make tradeoffs transparent — “we chose speed here, but here’s the cost, and here’s the plan to repay it.”
Example: The UK’s National Audit Office often flags “policy debt” in major government programs, creating visibility before crises hit.
Dedicated Time to Pay Down Debt
In Software: Some teams use the “20% rule” — dedicating part of their time to addressing debt instead of just building new features. Others run “stability sprints” focused entirely on paying down debt.
In Leadership/Organizations: Leaders can apply the same principle by allocating cycles for capacity building, training, or system upgrades instead of chasing constant new initiatives.
Example: Google’s 20% time reduced tech debt and birthed innovations like Gmail. Toyota’s kaizen cycles kept quality high while enabling incremental improvement.
Leadership Accountability
In Software: Smart organizations don’t let debt become a finger-pointing game. Leadership shares accountability by setting realistic deadlines and funding long-term fixes.
In Organizations/Policy: Leaders must resist the temptation to frame debt as “a team problem.” Instead, they set balanced incentives: rewarding resilience and long-term stability, not just quick wins.
Example: Amazon’s leadership principle of “long-term thinking” explicitly guards against innovation debt. Their patience in investing in AWS is a case of leadership refusing to rack up debt for the sake of immediate returns.
Culture of Transparency
In Software: The healthiest teams talk openly about debt. It’s not shameful — it’s part of building systems. By naming it, they manage it.
In Leadership: Organizations can create the same culture by talking openly about the hidden costs of quick wins. This shifts conversations from blame to deliberate strategy.
Example: Bridgewater Associates institutionalized “radical transparency,” surfacing hidden risks before they spiral. It’s uncomfortable but prevents debt from festering in silence.
Part IV. Applying the Lessons Across Domains
Here’s how the practices above map to the broader examples:
Policy: Imagine if Congress had a policy debt register that tracked rushed legislation and built-in plans for reform.
Organizations: What if companies ran “stability sprints” — dedicated cycles for training, culture building, and process improvement — alongside quarterly growth pushes?
Innovation: Leaders could make innovation debt visible by tracking neglected R&D or delayed digital investments as explicit liabilities, not afterthoughts.
Part V. Dealing with Debt: A Practical Framework
When borrowing the “debt lens,” here’s a framework anyone can use:
Name It: Be explicit — “This is debt.” Label the shortcut and its likely cost.
Track It: Maintain a register, backlog, or log of known debts. Visibility prevents denial.
Plan for Repayment: Dedicate cycles, budgets, or policy reviews to address it.
Balance Incentives: Reward long-term resilience, not just quick wins.
Communicate Transparently: Treat debt as part of the system, not a hidden flaw.
Adopt Continuous Practices: Use Kanban, TQM, Lean, and continuous improvement to keep debt manageable and resilience ongoing.
The Value of Borrowing Lenses
By itself, “technical debt” explains why software becomes fragile. But when you borrow it as a lens across domains, it explains something larger: the long-term consequences of quick wins.
Whether it’s code, policy, organizations, or innovation, shortcuts create obligations. Some debts are strategic; others are fatal. The discipline lies in seeing them, naming them, and managing them. It sharpens our decisions and broadens our vision. The next time you’re offered a quick win, ask yourself: Is this progress — or am I borrowing from the future?
Hope this helps.
Nicole
https://d3.harvard.edu/platform-rctom/submission/the-failed-launch-of-www-healthcare-gov/
https://corpgov.law.harvard.edu/2019/02/06/the-wells-fargo-cross-selling-scandal-2
https://sloanreview.mit.edu/article/the-real-lessons-from-kodaks-decline/
https://hbr.org/2016/07/kodaks-downfall-wasnt-about-technology
https://allthingsopen.org/articles/netflix-innovative-technical-debt
https://sloanreview.mit.edu/article/the-real-lessons-from-kodaks-decline/
Excellent 👏🏻