By Akinyele Olubodun
“Technical debt” is, I have come to think, one of the most expensive phrases in our industry, and not because of the debt itself. It is the framing that costs money. The word “debt,” in everyday usage, carries a moral weight that financial debt does not. We talk about getting out of debt, paying down debt, and eliminating debt. Apply that instinct to an engineering portfolio, and you end up doing exactly the wrong thing: spending expensive engineering capacity on liabilities that were never costing you much, while the debt that actually compounds against your balance sheet sits quietly in a backlog because nobody thought to flag it.
Debt, in finance, is not inherently bad. It is a tool. Some debt accelerates returns. Some debt compounds against you. The decision is not whether to carry debt, but rather which kind of debt to carry, at what rate, against which assets, and with what exit strategy. Engineering organizations that fail to make that distinction either pay down debt that should have been refinanced or hoard debt that is quietly consuming the asset side of the ledger.
After five years managing engineering teams across fintech, logistics, and platform infrastructure, I have come to believe that the most useful mental model for technical decision-making is not the debt metaphor at all. It is the portfolio metaphor. And the framework I call the Debt Portfolio Method has changed how I plan roadmaps, report to executives, and decide which engineers to assign to which problems.
This article lays out that framework, the two axes that drive it, the four quadrants it produces, and a case study from a platform migration where the method saved roughly fourteen months of engineering time and prevented what would have been, in hindsight, a strategically catastrophic refactor.
Most engineering organizations treat technical debt like an over-cautious household treats a credit card balance: they drive it to zero. Sprints get half a “debt ticket.” Quarterly planning carves out a “tech debt budget.” Senior engineers grumble about how the number never goes down. When you treat debt as a liability to eliminate, three things happen. First, you pay down debt indiscriminately, which means you spend expensive engineering capacity on items that were never going to cost you anything meaningful. Second, you underinvest in debt that is genuinely dangerous because it is mixed in with the noise. Third, and most damaging, you lose the option to deliberately take on debt as a competitive move, because the cultural framing has made all debt morally suspect.
I have watched teams spend four engineers for six weeks rewriting a configuration system that had never caused a production incident, while a payments reconciliation job that silently failed twice a quarter sat in the backlog because nobody had labeled it as debt. The configuration rewrite produced a cleaner repository. The reconciliation job, when it finally broke at scale, cost the business a regulatory inquiry. Both were “technical debt”; only one was actually expensive. The capital lens resolves this issue. In capital terms, debt has two properties that matter: the rate at which it compounds and the optionality it preserves or destroys. Every engineering decision fits on those two axes, and its location tells you what to do.
The rate of compounding is the speed at which the cost of carrying a piece of debt grows over time. Some debt is dormant. A library two minor versions behind, in a stable system with no security advisories, has a compounding rate close to zero. You can carry it indefinitely at near-zero cost. Other debt is exponential. A schema design that forces every new feature to add another join doubles its servicing cost every two quarters in a database already at the edge of its query budget.
The mistake most engineering managers make is estimating the compounding rate by the discomfort the debt causes engineers today, rather than by the slope of that discomfort over time. A piece of code that everyone hates but that is touched twice a year is cheaper than a piece of code that everyone tolerates but that sits on the critical path of every new feature. To measure the compounding rate, I look at three signals: how often the debt is touched in a given quarter; how much the touch cost has grown quarter over quarter; and how many adjacent systems depend on the current behavior. The third signal is the most predictive. Debt with many dependents compounds faster because each new dependent locks in the cost.
Strategic optionality is the amount of future flexibility the debt preserves or destroys. This topic is the axis that most engineering conversations miss entirely. Some debt destroys options. A premature commitment to a specific cloud vendor’s proprietary queueing service, baked into the domain layer, destroys the option to migrate. It does not just cost money to undo; it forecloses a strategic direction. Other debt presents options, sometimes deliberately. The classic example is the modular monolith. It carries debt against the textbook ideal of microservices, but it preserves the option to decompose later along whatever seams the business actually reveals, rather than the seams an architect guessed at on day one. The optionality lens is also where engineering leadership earns its place in strategy discussions. Executives care about optionality intuitively, even when they cannot name it. When I started framing architectural decisions as option preservation rather than best practice, board-level conversations got noticeably shorter, and approvals got significantly easier.
High compounding, low optionality: acute debt. This is debt that gets more expensive fast and constrains your future moves. Pay it down immediately, and treat the cost as non-negotiable. Examples: a security model that does not support the customer tier you are about to sell into; a database design that is six months from a hard scaling ceiling; an authentication flow that is blocking a regulatory certification you need to enter a new market. Acute debt is where the “debt is bad” framing accidentally gives you the right answer, but for the wrong reason. High compounding, high optionality: Leveraged Debt. This is debt that is expensive to carry, but that is genuinely funding something valuable, usually speed. The right move is not to pay it down. It is to refinance it, the way a business refinances a high-interest loan once it has stabilized. Examples: a monolith that is slowing senior engineers but allowing the product team to ship three features a week during a critical market window, and a restrictive vendor dependency that bought you twelve months of focus on differentiation. The discipline here is to set explicit refinancing triggers, usually tied to a product or revenue milestone, so the debt does not silently roll over forever.
Low compounding, low optionality: stable debt. This is debt that is mildly annoying, mildly constraining, and not going anywhere. The correct move is almost always to tolerate it, document it, and resist the social pressure to fix it. The cost of fixing stable debt is almost always higher than the cost of carrying it, and the engineering time has a much higher return elsewhere. The hardest part of this quadrant is cultural. Senior engineers often have strong aesthetic objections to stable debt, and engineering managers have to be willing to defend the decision to leave it alone. Low compounding, high optionality: Strategic Debt. This is debt you deliberately take on because it preserves future flexibility at a known, modest cost. The MVP hard-codes three customer types because you do not yet know whether the segmentation will hold. The internal tool is built on a stack the team already knows, even though a better stack exists, because the time to the first usable version matters more than the long-term elegance. Strategic debt is the quadrant where most of the competitive value of engineering leadership lives, and it is the quadrant most often punished by junior engineering culture.
I joined a payments-adjacent platform as engineering manager for a team of fourteen, inheriting a roadmap that had a full quarter blocked out for a migration away from a legacy Python service onto a newer Go-based architecture. The argument for the migration was orthodox and superficially strong: the Python service was slow, the team disliked working on it, and the Go service would be faster, cleaner, and more aligned with where the rest of the platform was heading. The estimated cost was one quarter of engineering capacity, roughly six hundred and thirty engineer days. Running the migration through the debt portfolio method changed the decision entirely.
On the compounding axis, the team touched the Python service roughly once every three weeks, and the per-touch cost remained flat for four quarters. Two adjacent systems depended on the behavior of the first system, and both were stable. Compounding rate: low. On the optionality axis, the service implemented a clearly bounded function (transaction enrichment) with a stable interface contract. Migrating off it later, if needed, would be a self-contained piece of work. Optionality: high.
The service was, in other words, strategic debt. It costs very little to carry. It constrained nothing. The migration would have spent six hundred and thirty engineer days to move a working asset from one quadrant to a slightly more aesthetic version of the same quadrant. We cancelled the migration. The freed capacity went to a customer onboarding rebuild that the same exercise had flagged as acute debt: high compounding, low optionality, and sitting directly on the critical path of the next two enterprise deals. Time to first transaction for new customers dropped from eleven days to three. The two enterprise deals have closed. The Python service is still running, two years later, and has cost roughly forty engineer days of maintenance in that period. The migration, had we run it, would have cost fifteen times that, displaced revenue-critical work, and produced no measurable change in customer or business outcomes. The lesson is not that migrations are bad. The lesson is that the quadrant determines the action, and the quadrant is rarely what the team’s intuition initially says.
A framework that exists only in the engineering manager’s head is not a framework. It is a habit. To make the debt portfolio method operational, I run it as a quarterly exercise with three artifacts. The first is the portfolio map, a single-page document that places every significant piece of engineering debt on the two axes. I keep it to one page deliberately. If it does not fit on one page, the team is either tracking noise or has lost the ability to distinguish material debt from background friction.
The second is the refinancing schedule, which lists every item in the leveraged debt quadrant alongside the explicit trigger that will move it to acute. Triggers are written in business terms, not engineering ones. “When we close our second seven-figure customer” is a trigger. When the codebase reaches a certain complexity score, it is not.
The third is the strategic debt register, which is the most counter-cultural of the three. It lists debt that the team has deliberately taken on, alongside the optionality it is preserving and the conditions under which it will be retired. The register exists primarily to protect the team from itself. Without it, well-meaning engineers quietly clean up strategic debt without knowing it was load-bearing.
The Debt Portfolio Method is, on the surface, a decision framework. Underneath, it is an argument about what senior engineering leadership is actually for. The traditional model treats engineering managers as throughput optimizers. Ship more features, reduce more debt, and improve more metrics. The portfolio model treats engineering managers as capital allocators. The question is not how to do more, but how to deploy a finite engineering balance sheet against a changing set of business opportunities, with explicit reasoning about which liabilities to carry and which to retire. That reframing has hiring implications. The senior engineers who thrive in a portfolio model are those who can reason about optionality and time horizons, not just code quality. It has planning implications. Roadmaps stop being a list of features and start being an allocation across quadrants. It has reporting implications. Engineering becomes legible to finance and to the board, in their own language, without losing technical depth.
Most of all, it changes the cultural posture of the engineering organization. Debt ceases to be a moral failure that requires an apology. It becomes a tool to be used, with discipline, in the service of compounding returns. That is the posture I want every engineering team I lead to operate from. It is also, in my experience, the posture that produces the best engineering outcomes, because it forces every decision to answer the only question that ultimately matters: what is this debt buying us, and is the price right?
Akinyele Olubodun is a Senior Software Engineer