How Software Leaders Make Room for Technical Debt

We made space for it by refusing to treat a feature and its maintenance as separate line items.

At Eprezto we are a broker, so we connect to insurance carriers and show their quotes. Every carrier we add is a feature from the business side, more options for the customer. From engineering it is a permanent cost, because every carrier connects differently, has its own API quirks, and breaks in its own way. Our debt was not something we took on carelessly. It was the accumulated weight of decisions that all looked like growth at the time.

We cut the carriers we display from eight to between four and five. That is not a refactor, it is a product decision, and that is exactly why it got approved when a cleanup sprint would not have. We could argue it on the customer side: fewer options means a faster decision, and it positions us as a recommender rather than an aggregator. The engineering benefit, a large drop in integration surface and ongoing maintenance, came along with it.

My advice to anyone in that conversation is to stop asking for time to pay down debt and start finding the places where less product is also better product. Those exist in most roadmaps and they are far easier to defend. One, the business gets a reason it already understands. Two, the team deletes the code instead of maintaining a tidier version of it.

1. I stopped using the term "technical debt" with customers and stakeholders. Nobody funds debt. They fund less downtime and faster delivery. In our trading infrastructure, examples of debt are the provisioning script that failed to provision MT5 servers for a broker who ordered dozens of them at once, and the monitoring that alerted after a trader had already noticed the slippage. Each of these items of debt is rewritten as a cost to the business: hours of support time, credits issued, delayed releases. They then get to compete with features on the same roadmap once they have a cost to the business.

2. The decision was a toll rule: every feature that touches fragile parts of the system gets to pay off those parts first within the scope of the estimate. Thus, launching a new trading account, for instance, also means re-engineering the provisioning of the provisioning pipeline for the new data center location. The extra weeks required for the launch of that location were well invested, as after that, launching additional locations only takes a few days and the business never ever lost confidence. They can watch one feature being deployed and then the next feature being deployed much faster. That is the only proof that the stakeholders actually believe you.

I've had a client with six servers where nobody knew what the third one was still running for. We switched it off and waited a week to see if anyone shouted, and nobody did. That's the planning step I'd copy for any roadmap: before the team builds something new, list what is still running and why, because every forgotten system slows down each later change. I founded hagel IT in 2004 and have spent over 20 years cleaning up exactly this kind of drag.

Jens Hagel, Founder & Owner, kjello (Hamburg, Germany)

We set a single planning rule: every sprint will include 20% of cleanup efforts, which will be known to the business side before starting the sprint.

In my company, customers constantly requested AI search checks. Yet, with a very messy codebase, we had to make more and more effort to develop every subsequent feature. It was like running while wearing a heavy backpack.

That's why I gave up using the term "technical debt" at all. Instead, I was saying "this cleanup allows us to create new features faster". Every cleanup activity should have a target feature and days saved associated with it. For instance, we managed to clean our messed-up codebase for generating reports, and since then development of any report features has become twice as fast, i.e., it takes us just one week now instead of two.

At the end of the month, I send a short update to stakeholders about what has been cleaned up and how much faster we ship.

My advice:- never ask for a big cleanup month. Take a small, fixed slice of every sprint, tie it to a feature people want, and show the results.

We make space for technical debt by never making it its own project. The moment debt paydown becomes a standalone sprint on the calendar, it competes directly with a feature deadline, which usually wins.

The planning decision that's worked is putting the cleanup call in the hands of the engineers touching the code, as they touch it. When someone's in a file to ship a feature and notices something that should be refactored, that's the moment to fix it, not a note for later. Debt reduction becomes small, doable work inside projects already on the roadmap. The tradeoff is accepting that it sometimes slows a ticket down. The alternative, building only new features and never touching what's underneath, eventually slows delivery to a crawl.

When we do have to choose, debt inside the features customers use most goes first. The end user experience is the priority, so friction in a high-traffic workflow outranks cleanup that's technically important but hasn't affected anyone. We also run regular performance and cost reviews outside of release cycles because as data grows and usage shifts, debt gets more expensive and eventually shows up as latency.

What keeps the business confident is slowing how fast new debt piles up. Security scanning on every deploy, linting rules, and automated testing in the pipeline don't eliminate debt, but they keep it from accumulating at the same rate.

In infrastructure, technical debt doesn't stay hidden for long. It shows up as incidents, slow model onboarding or engineers spending their week on manual workarounds instead of building. That actually makes the conversation easier, because you can describe debt in terms the business already cares about. "Refactor the scheduler" gets pushback. "Cut the time it takes to bring a new model online for customers" gets support. So the first thing I ask engineers is to translate every major debt item into the customer or business outcome it affects. If they can't, it probably isn't urgent. The planning decision that helped most was giving reliability and platform work its own visible line on the roadmap, reviewed in the same meetings as new features, instead of hiding it in buffer time that gets eaten the moment a deadline slips. Once leadership could see what that work was protecting, like uptime and how fast we could support new customers, it stopped feeling like a tax and started feeling like part of the product.

I framed technical debt as customer protection, and the conversation with stakeholders changed immediately.

When I told the business side "we need to spend two sprints on tech debt," the response was always "can it wait?" When I said "there is a 40 percent chance this component fails under load during our next traffic spike, and recovery takes a full day," suddenly the business cared. The mistake I made for the first year at Pigment was treating tech debt as an engineering concern. It is a business risk that engineering happens to own.

The planning decision that worked: we allocated 20 percent of every sprint to what we called structural work. Not a separate tech debt sprint. Not a quarterly cleanup. A consistent slice that the engineering team controlled without approval. That consistency prevented the debt from compounding to the point where it required a heroic effort to address.

What made the business confident was showing results differently. Instead of saying "we refactored the assessment engine," I reported "assessment load times dropped from 3 seconds to 800 milliseconds, which means 12 percent fewer users abandon mid-completion." Same work. Different story. Engineers think about code quality. Stakeholders think about what the user experiences. When you translate one into the other, the resistance disappears.

Kenneth Shen, Founder & CEO, Pigment (pigment.is)

The planning decision that helped most was treating technical debt as a standing capacity allocation in the roadmap instead of something we squeezed in only when things broke. In practice, that meant every cycle had protected engineering time for reliability, cleanup, and tooling, even when feature pressure was high. Once debt work became a planned line item rather than an apology, the business stopped viewing it as abstract engineering preference and started seeing it as the cost of keeping delivery speed predictable.

What made that credible with stakeholders was how we framed it. We did not present technical debt as "refactoring for its own sake." We tied it to visible business outcomes: slower release cycles, bugs that affected onboarding, manual work that made experiments harder to run, or fragile systems that increased support load. In a SaaS environment, especially when you are shipping quickly, hidden drag compounds fast. A feature may look cheap on paper, but if the underlying system is messy, each new release gets slower and riskier.

A practical rule that worked for us was separating roadmap work into three buckets: growth features, reliability/platform work, and maintenance. That forced honest tradeoffs early. If a feature request could not fit without stealing from the reliability bucket, we had to explicitly accept the future cost instead of pretending it did not exist. That made conversations with the business much cleaner.

Another helpful shift was prioritizing debt that unlocked future speed, not just cleanup that felt satisfying. For example, improving internal workflows, reducing repeated edge-case fixes, or simplifying a core integration can pay back faster than a broad rewrite. Stakeholders usually support debt work when you can clearly say, "This reduces release friction for the next five launches," instead of, "The codebase needs love."

Technical debt gets easier to defend when you show it as protection of future velocity and customer trust, not as a detour from roadmap execution.

An effective approach to balancing technical debt against new feature development involves the use of a weighted prioritization matrix. Consider assessing technical debt across multiple dimensions, such as risk, velocity, scope, and growth rate.

Assign a weighted multiplier to each dimension to enhance objectivity in the decision-making process; for instance, risk could be weighted at 4x, velocity at 3x, scope at 2x, and growth rate at 1x.

This framework helps prioritize engineering debt that needs remediation based on its impact on business risk, preventing the common pitfalls of endless debates or crisis management as issues arise.

To emphasize the implications of velocity impact, make the costs of technical debt visible to non-engineering stakeholders. Clearly articulating that "XYZ technical debt will increase the time required to develop features by 50%" creates a compelling case for prioritization.

Conducting a quarterly review of technical debt is crucial. During this review, score and update the priority of each item in the backlog. Afterward, focus on the top n items and allocate 20-30% of the sprint capacity to addressing these debts.

Communicating the priority scores to stakeholders fosters confidence in the remediation efforts, demonstrating that the focus is on addressing the most significant operational impacts.

By following this structured approach, the technical debt management process becomes transparent and aligned with overall business goals.

We introduced a readiness threshold for features entering the roadmap. Before assigning a timeline, we identify dependencies, operational risks, and engineering improvements needed to support each request. Requests that do not meet this threshold remain in discovery instead of becoming promises. This approach helps us set realistic expectations while giving the team time to address important gaps.

This decision improved trust because it made uncertainty visible early, when changes were less costly. It also gave engineers room to fix issues before they became blockers. We explain these choices by highlighting the risks of missed deadlines, inconsistent performance, and repeated work. Rather than treating technical debt as simple cleanup, we present it as a way to protect reliable commitments and maintain a flexible, realistic roadmap.

The planning decision that helped us most at Streamrise: pay down debt as a series of small, reversible moves inside normal operations, never as a big "migration project" that competes with features for a quarter. The business keeps seeing service run while the old system shrinks.

A real example. We run work on two engines: an older one that starts a separate process for every customer order, and a newer one built to replace it. In late September, 614 orders of one type were still sitting on the old engine. Moving them all at once would have been a risky big-bang cutover. Instead, on 28 September we added a temporary rule to a database setting that the old engine already reads live, so it handed over orders 10 at a time every 5 seconds, and the new engine picked each batch up immediately. 612 of the 614 moved within minutes, with no restart. The two that lacked data the new engine needs were deliberately left where they were. Afterwards the temporary rule was removed and the setting restored byte for byte.

Why we keep prioritising this kind of debt: two days later we found a process on the old engine that had kept working for 25 days after its order had completed, because the old shutdown query only matched orders still assigned to their original controller, and this one had been reassigned. Debt is not just slower development; it is work done for nobody.

What I have learned about making space for it without losing the business's confidence: 1. Tie each debt item to a cost the business already feels: wasted resources, a past incident, a customer complaint. Our rule against schema changes at service start-up exists because one such change hung production on 8 August, with 24 queries stuck and the oldest waiting 878 seconds. 2. Choose moves that can be undone the same day. A setting that can be restored exactly is easier to approve than a rewrite. 3. Report debt honestly, including what is still not done. In early October we had protection code written for one failure mode that was not yet switched on, and we reported it that way rather than counting it as finished.

Features earn trust when they ship; debt work earns it when nothing visible breaks and the numbers show the old system getting smaller.

I put technical debt on the roadmap when I can name the feature it will obstruct and when the fix has to happen. We minimize debt already blocking delivery, and work likely to block the next feature goes into the plan. Hypothetical cleanup with no clear horizon stays visible without displacing agreed feature work. A stakeholder can then judge a fix against the work the business wants shipped.

Our planning decision is to look a step ahead and give larger debt tasks an owner. Small fixes happen while the code is open or during review. A substantial fix becomes a separate backlog task owned by a project manager or tech lead, then goes into a delivery gap or toward a project's end as feature work thins out. We don't reserve a fixed percentage of every sprint for debt. An owned task makes the tradeoff visible without consuming capacity by default when the feature path doesn't need that fix.

We watch dependencies and tooling so a deprecation notice can become scheduled upgrade work before it disrupts the next release. Developers flag friction they encounter day to day, and our regular developer experience survey gives us another way to catch it. The owner can place a substantial repair before the work it threatens, or wait for a delivery gap when the risk allows. Customers still see the agreed features progress.

If someone asks why a debt item is in this roadmap, I'd show the feature it would slow down and the point by which the repair must happen. When neither is clear, the item stays in the owned backlog until its blocking horizon changes.

Balancing technical debt with new feature demands comes down to simple backend reality—if you let messy API scripts and bloated database queries pile up, system latency creeps up, cross-system syncs time out, and delivery grinds to a halt. Executive leaders push back on refactoring because code cleanup sounds like abstract work. When you show them that rewriting a slow database query stops high-volume user provisioning from crashing during peak hours, stakeholders back the effort immediately.

In a multi-entity setup connecting our core HR software, payroll platforms, and recruitment tools across nine separate organizations, rushing out features without maintaining integration pipelines creates massive operational drag. Rushed integration logic relying on heavy nested loops meant simple user access syncs took minutes and frequently timed out, forcing teams to waste hours manually fixing failed account updates. To eliminate that recurring pain, we set a firm 20% capacity budget into every sprint strictly to refactor integration scripts, optimize database indexes, and clean up role-based access rules right alongside new feature work.

When larger bottlenecks hit, like re-architecting a core cross-system data pipeline, we took a full sprint between major rollouts to rebuild that underlying foundation. We backed it up with clear results: user sync processing time dropped from four minutes to under three seconds, integration errors dropped to zero, and downstream system updates stopped breaking. Proving that backend maintenance directly prevents outage risk and speeds up future rollouts keeps business leadership completely confident in the engineering roadmap.

At Molecule, an enterprise customer kept pushing for newer and newer integrations before we had validated the data the existing ones were producing. Nobody had identified the data gaps or put checks and monitoring in place.

We explained the tradeoff with examples rather than in the abstract. We showed them a past instance where an integration that was not thoroughly checked produced wrong results. We also put the data in front of them on a dashboard, so they could see the gaps themselves and had a better way to monitor them going forward.

Validation was already part of delivery, but not at the level the data needed. The planning decision was to drastically raise the quality bar for validation on every delivery, before sign-off, instead of leaving problems for a cleanup job later. Going back to old work means context switching, digging through it and uncovering problems, which costs far more than making the work you are delivering now reliable and thorough.

With the customer, we agreed on a joint process for queuing new integration requests, and together we wrote a better checklist and SOP documents for quality checks. The result was more reliable integrations and less technical debt building up going forward.

I have found that technical debt gets attention when you can show how much engineering time it is consuming, rather than treating it as a separate cleanup project.

At Yahoo Finance, we had an existing WebdriverIO test framework that needed to be migrated to Playwright. It was a substantial amount of work, and a principal engineer had estimated that the migration could take about a year. Keeping the older framework running indefinitely would also mean continuing to maintain tests and infrastructure we eventually wanted to retire.

I built an AI assisted migration process that could inspect our application code and help recreate tests in Playwright. We divided the migration into smaller tasks, coordinated work across engineers, and reviewed the converted tests rather than accepting generated code without checking it.

The team completed the migration in about five weeks. I personally authored 54 of the 104 pull requests involved.

The biggest lesson for me was that technical debt becomes easier to prioritize when you change the cost of addressing it. Instead of asking the business to accept a year of engineering work, we found a way to make the work considerably more manageable while continuing to protect test coverage.

I stopped calling it "technical debt" to stakeholders. That was the single decision that unlocked actual roadmap time for it.

Here is why. When you say "technical debt" to a product manager or a VP, they hear "engineers want to refactor code for fun." It sounds optional, academic, like something that can wait. So I started calling it "delivery risk" instead. Same items on the backlog, completely different conversation.

At MyTona, where I spent about eight years building backend for mobile games with around 50 million users, we had a Kafka message queue setup that worked fine at 10 million daily events. When we hit 35 million, it started dropping messages during peak hours. Not catastrophically, just enough that maybe 2 percent of in-app purchase events got lost. That translates to roughly $4,000 per day in untracked revenue.

I brought that number to our product planning meeting. Not "we need to refactor our event pipeline" but "we are losing $4,000 a day because our infrastructure cannot handle current load, and it will get worse as we grow." We got two sprints allocated the following week. Same technical work, different framing.

At Softline Solutions now, where we manage cloud infrastructure for about 1,500 corporate accounts on Google Cloud Platform, we formalized this into what I call a "debt tax" model. Every quarter, we calculate the actual cost of our top five technical debt items in terms of engineer hours lost to workarounds, incident response time, and missed SLA penalties. Then we present it as a line item: "This quarter, technical debt cost us approximately 340 engineer-hours in workarounds and three SLA breaches." That is a number a CFO understands.

The planning decision that helped most was reserving a fixed 20 percent of every sprint for debt work, but letting the engineering team choose which debt to tackle based on their "cost of delay" calculation. Leadership controls the budget percentage, engineers control the prioritization. Neither side feels overruled. We have maintained this model for about two years now and our deployment failure rate dropped from roughly 8 percent to under 2 percent.

I make the case for technical debt in terms of the work it obstructs: slower delivery, repeated operational effort, or a constraint on capacity. Then I look for a migration boundary that lets us improve that constraint while the product keeps operating.

At Market Brew, one useful planning decision was to move website data to a new shared database as each site was recrawled. We maintained separate legacy and shared-database paths during the transition. That spread the work over many months, instead of requiring a system-wide shutdown to rebuild all the data in the new schema.

The tradeoff is that we have to support both paths during the migration. I would make that cost explicit in the roadmap, alongside the checks needed before retiring the old path. Otherwise, an incremental migration can become permanent duplication.

For me, the business case is stronger when modernization has observable stages and protects availability along the way. I would explain what each stage removes, how we will verify it, and what customer work can continue while it happens. That gives stakeholders something concrete to assess when deciding how much feature capacity to allocate to the migration.

Tie the debt to a risk the business already cares about.

When we inherited the code base for a long-lifecycle industrial product from another organization, it came without static code analysis and with thin regression coverage. I raised it as a project need in my monthly reports, but what actually moved it up the roadmap was a serious field issue: the device and our offline post-processing tool disagreed on calculated results, and the root cause turned out to be a compiler optimization problem. We shipped a workaround quickly. Then, instead of asking for a separate "cleanup" budget, we proposed a continuous-improvement project to automate full-range regression tests through a hardware simulator, so this class of problem would be caught before any release. In the same year I volunteered to set up static code analysis for the code base. Those regression tests became part of validating every release that followed.

We used the same approach on the hardware side: a known board initialization issue was bundled into a redesign that a parts-obsolescence change already required, so one project paid for both.

The planning decision that kept the business confident was framing debt work as risk reduction on something they already worried about, with a clear closure presented back to management, rather than as a line item that competes with features.

Technical debt gets roadmap space on our team because we stopped asking for it as a favour and started planning it as a category. A fixed share of each cycle's capacity is reserved for platform health before feature planning begins, the same way on-call and incident response are reserved. Product partners see the share, they see what it bought last cycle, and they can argue about its size once a quarter. What they cannot do is spend it silently in a crunch, which is how debt budgets usually die.

Inside that share, debt items compete with each other, not with features. We keep the list short and written in operational terms: this legacy flow doubles the testing time of every change in its area, that unsupported library blocks a security patch, this manual step fails twice a month. When a debt item's cost shows up in an incident review or a slipped date, it moves up the list with evidence attached. When it just bothers the engineers, it waits, and sometimes waiting is the right call. Not all debt is equal and pretending otherwise is why debt backlogs grow into hundred item wish lists nobody funds.

The result is unglamorous and that is the point. Debt work appears on the roadmap as named items with owners and dates, it survives contact with feature pressure because its capacity was negotiated in advance, and the team can point to what the investment removed. Roadmaps fail at debt when it is treated as an apology attached to feature work. Treat it as rent on the systems you run, budgeted like rent, and it stops needing a crisis to get paid.

— Vishnuvardhan Reddy Kaithapuram, Software Development Engineer at Amazon Advertising

I stopped framing it as debt versus features and started ranking work by what it costs users in trust.

On our trading app, a product for buying tokenized U.S. stocks with USDC, people asked for plenty of new things: connecting Phantom or MetaMask, a ticker, a bigger leverage control. Our user interviews showed the real drag was underneath. Swaps that failed, a withdrawal that sat on a bridge, a spinner that kept going after a transaction had already failed, and separate balances for spot and leverage that made sense for our architecture and none to the user.

The planning decision that helped most was one rule anyone on the team could repeat: if a problem can make someone wonder where their money is, it goes first. The point of the rule is that it isn't engineering's preference against the business. It's about the thing that decides whether a customer trusts you with money.

The second decision was saying no to some features on purpose. We kept one embedded wallet instead of adding external ones, because one wallet model meant one funding flow to make reliable.

If I did it again I'd go further: one balance from day one, and failure states designed before the happy path.

Balancing technical debt while stakeholders push for rapid feature delivery comes down to tying code health directly to scalability and future development velocity. Instead of viewing technical debt reduction as a separate engineering chore, we allocate a fixed percentage of each sprint (typically 15% to 20%) exclusively to refactoring and performance optimization.

A key planning decision that helped reduce future drag without losing business confidence was implementing a strict modular architecture and moving heavy processing logic client-side (such as handling document utility operations directly in the browser). By designing features to be isolated and lightweight from the ground up, we minimized systemic technical debt, reduced server overhead, and ensured we could ship new user features faster without compromising code quality.

— Muhammad Zeeshan, Full Stack Web Developer

Rather than treating technical debt as a separate roadmap item competing with new features, we've found it works better to group related features together and tackle an entire area of the platform at once. This allows us to rework the underlying code, address technical debt and introduce new functionality at the same time. Customers and stakeholders still see the improvements they're asking for, while our engineering team gets the opportunity to clean things up properly instead of continually building on top of legacy code. It also means we're not constantly revisiting the same areas of the platform, making future development faster and easier.

We avoid the problem by not creating avoidable debt in the first place. Every line of AI-assisted code is reviewed and tested before it ships, and the codebase is documented so a future engineer can pick it up without starting over. For debt that does appear, we show it where the business can see it: working software reviewed weekly. Problems found in week two cost a fraction of what they cost after launch, and stakeholders can see the trade-off in a demo, not hear it in an argument. Cheap changes early are the best way to keep debt off the roadmap.

We stopped treating tech debt as a separate project that has to win a budget fight. It almost never wins that fight against a feature a customer wants this month.

What works better is tying the cleanup to the feature that needs it. When a new feature runs through a messy part of the code, the estimate we give the business already includes fixing that part. We say it plainly. This feature takes eight days, and three of those days are about making sure the next feature in this area doesn't take twenty. Most business owners are fine with that, because they can see exactly what they are paying for and why.

The planning decision that made the biggest difference was keeping a short, visible list of the debt that is actually slowing us down, written in business terms instead of engineering terms. Not "refactor the auth module" but "every new login option costs us a week." When that line sits next to a feature request in the same planning meeting, the trade-off stops being abstract and the conversation gets a lot easier.

Debbi Chandel, Founder and CEO, Zygobit

The argument goes better when technical debt stops being one big "refactor" request and becomes dates and small tickets the business can see.

Mobile gives you the easiest version of this. Apple and Google publish their toolchain and target API deadlines months ahead, so those go in the same tracker as feature work, with an owner and a reminder two months before the cutoff. Nobody argues with a deadline set by the app store, and each one forces a small upgrade before the debt piles up.

For everything else, a scheduled build of the main branch with updated dependencies, run even in months with no feature work, shows you early when something has drifted. Fixing it then takes a day or two. The planning decision that keeps the business on side is offering that day or two before a deadline, rather than asking for a month of cleanup with no date attached.