How to Manage Technical Debt in Legacy Software

Tech debt can bring down even the brightest of startups. Here are three ways we reversed ours at Plivo: 1. We restructured our org chart. Initially we had three specialist teams: backend engineering, infra (CloudOps/SRE/DevOps today), and VoIP engineering. As a CPaaS company we have a complex voice-calling API stack. This worked well when Plivo had 10 employees, but by 2016, we had 40 and multiple products, which led to constant context switching and the exacerbation of our tech debt. To solve this, we switched to a new product-based team structure. The goal of this new structure was to reduce context switching and ensure that each employee could focus on what they were best at. We built teams for our voice API, SMS API, Billing/Payments, and SDKs, and each team had its own developers, QAs, engineering managers, and product owners. When we switched to this new structure we began to notice improvements across the board: bugs were getting fixed faster, latency and uptime were improved, teams had the bandwidth to break down monoliths, and our products were getting better and faster. 2. We built infrastructure for scale. In the early days of Plivo, we were deploying a new AWS EC2 image with each release instead of incremental code upgrades. This gave us the flexibility to access and re-deploy older images, but the process was quite slow and hurt our productivity. It resulted in the rapid accumulation of tech debt because we could not iterate fast. We didn’t have a staging environment either. Services would crash and we had no logic to switch so we created a dedicated AWS account for our staging setup. This dual-account setup was sufficient for a while but when we switched to product-based teams, we chose to replicate this structure for each product within Plivo. This increased our overhead substantially but also gave us much more stability. The addition of QA engineers for each product reduced surprises further. In 2018, we integrated all our operations into Docker, significantly transforming Plivo's development process. We were able to set up a robust CI/CD pipeline with added layers of security, compliance, and immutability. Consequently, our engineers could develop on local setups and accelerate deployment times. 3. We made customer experience our north star metric. As a tech person, I tend to prioritize tech metrics, e.g., our p99 latency. However, during the five months we spent reversing our tech debt, we decided to prioritize the one thing that would improve customer experience the most at any given moment. To determine what that one thing was, we paid attention to the number of incidents, support tickets, and alerts. Rome was ablaze, but we still needed to pick and choose which specific buildings to throw buckets of water at—these metrics informed our firefighting efforts. Our battle against tech debt is ongoing, but we now feel well-equipped to fight it thanks to our scalable org structure, CI/CD pipeline, and customer-centricity!

The older a platform gets, the harder it becomes to evolve. Not because it’s inherently better or worse but because of the layers of decisions, trade-offs, and expansions built up over time. Enterprise platforms in banking, fintech, and insurance aren't designed all at once. They’ve been expanded and modified for years, even decades. Add mergers & acquisitions into the mix, and suddenly, you're stitching together multiple systems, each with its own history and logic. The result? Technical debt. Most people think of technical debt as purely a bad thing. But in reality, technical debt isn’t a curse, it’s a tool. I’ve seen this firsthand working with hundreds of financial firms over 20 years. Technical debt (when used strategically) allows companies to move fast, delivering value before every piece of the system is perfect. But when ignored, it compounds, making innovation harder, slower, and riskier. So how do companies balance moving fast while managing technical debt? 1️⃣ Recognize that technical debt isn’t just a problem, it’s a strategic decision. 2️⃣ Build with awareness: technical debt is a tool, but only if it is managed responsibly (just like financial debt). 3️⃣ Align engineering and business teams so one isn’t slamming the brakes while the other floors the gas. 4️⃣ Modernize responsibly: replace what’s necessary, refactor what’s valuable, and don’t treat legacy systems as obstacles, but as histories of past decisions. If your Fintech is in need of an upgrade, the team at Praxent is here to help.

Fix tech debt when it impacts your business, and include it in your planning. Last week, I had a conversation in which a product manager asked the group what our philosophy on retiring tech debt was. I said "oh, you are going to get platitudes", and then proceeded to spout platitudes. I mentioned the above, but only in passing - but I've found it's key to getting product and engineering on the same page about tech debt. I've had experience with teams where relentless feature requests, without tech debt remediation, have led to slowed velocity and declining product quality. The solution was to show product that tech debt reduction is in their interest. If you can't deliver features because you have flaky tests, and you have a huge pipeline of new features you need to deliver, budget the time to fix the flaky tests. If you can't onboard new hires because your documentation is terrible, and you are doing a lot of hiring, budget the time to fix the documentation. If your product has developed a reputation for being a buggy pile of garbage, prioritize fixing the worst of the bugs. And, if you can do so, surface the problem with metrics! How long does it take for a change to get to users? How long does it take a new hire to land their first change? If you can show you've moved the needle on these numbers, you can show the impact of tech debt reduction even more clearly. Finally, and critically: incorporate tech debt into your roadmap.  It may take a long time to fix those flaky tests. But if you have a roadmap that stretches out a year or more, future you will be grateful you did it. This strategy is less effective when the tech debt catches you unaware. For example, you can go a long time without a compiler or library upgrade, and then find you are in a huge amount of trouble because you have to upgrade through 10 years' worth of releases to fix a critical security flaw. In cases like that, it makes more sense to budget regular time to address the problem incrementally. However, the strategy *does* provide a way to build a culture where you foster collaborative discussions that help you prioritize tech debt effectively, and I've found that it can lead to a healthier product and a more efficient development process. What are your strategies for making sure product and engineering are on the same page about tech debt?