Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Product Thinking to Reduce Tech Debt
Transcript
- Lucas: Most CTOs I talk to describe tech debt as a code problem. You know the drill — too many shortcuts, too little refactoring, the codebase is a mess and nobody's paying down the principal. Luna: Right. And the typical fix is to carve out some percentage of each sprint for refactoring, or declare a 'tech debt week' every quarter. Lucas: Exactly. But I recently spoke with the CTO of a B2B SaaS company — about 80 engineers, growing fast — who took a completely different approach. He argued that the tech debt wasn't really a code problem. It was a product problem. Luna: That's an interesting reframe. How did he land on that? Lucas: He had his team do an audit of every unplanned maintenance ticket over a six-month period. Bug fixes, hot patches, emergency deployments — the stuff that people call tech debt. And they tagged each one with the feature it related to. Luna: So instead of classifying by which code module it touched, they classified by which product feature triggered the work. Lucas: Exactly. And what they found was that roughly 70 percent of those tickets clustered around just three features. Three features that had been built under intense time pressure, with vague requirements, and — crucially — no dedicated product owner after launch. Luna: So the features were orphaned, essentially. No one was actively managing them. Lucas: Right. And without a product owner, scope creep had set in early. Each of those features had been patched and extended by different engineering teams over two years, accumulating complexity without anyone asking 'should this feature still exist?' Luna: So the real problem wasn't that the code was bad. It was that the feature design was unfocused and nobody was saying no. Lucas: That's exactly it. So the CTO didn't launch a refactoring initiative. Instead, he went to the product leadership team and said: 'These three features are generating 70 percent of our unplanned maintenance. Let's decide what to do with them from a product perspective.' Luna: What options did they consider? Lucas: They had three categories. One: if the feature was genuinely valuable but poorly implemented, assign a product owner, rewrite the requirements, then rebuild it clean. Two: if the feature was barely used but still generating noise, deprecate it. Three: if the feature was core but the maintenance was just the cost of doing business, accept it and budget accordingly. Luna: So they stopped treating all tech debt as something to be eliminated and started treating it as a portfolio decision. Lucas: Precisely. And the results were pretty dramatic. Within six months, unplanned work dropped by about 40 percent. The engineering team wasn't grinding harder — they just stopped building bad features and stopped maintaining ones that should have been killed. Luna: I love that this came from the CTO, not the product VP. It shows that engineering leaders can drive better product decisions when they bring data instead of complaints. Lucas: That's a key point. He didn't go in saying 'you guys are giving us bad specs.' He went in with a simple spreadsheet showing exactly which features were costing the most engineering time. Luna: If today's tech conversation gave you something usable, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, it really does make a difference. And listener support is what keeps this ad-free and focused on the actual practice of engineering leadership. Luna: Alright, back to the framework. So how did they get product leadership to actually agree to kill some features? Lucas: That's the part I found most instructive. They didn't just present the maintenance cost. They also presented usage data. One of the three features had fewer than 50 active users per month. The product team had assumed it was more popular. Luna: So data changed the conversation. That's often the missing piece — engineering knows it's a pain, but product doesn't know the usage numbers. Lucas: Exactly. The second feature was actually popular — it was a reporting dashboard that customers loved. But it had been built as a prototype and never hardened. So they assigned a product owner, rewrote the spec, and rebuilt it in about eight weeks. The third feature was a configuration tool that was used by the internal sales team, not by customers. That one they decided to accept the maintenance cost because it was low frequency and high business value. Luna: So for each feature, the outcome was different. Not a blanket 'refactor everything' approach. Lucas: Right. And the CTO told me that the biggest win wasn't even the 40 percent reduction in unplanned work. It was that the product org started owning the consequences of feature decisions. Before, they'd hand off a feature and never look back. Now they know that every feature they ship will be tracked for maintenance cost and usage. Luna: That's a cultural shift. And one that's probably harder to achieve than any code refactor. Lucas: Absolutely. And it's more durable. Because the next time someone proposes a feature with vague requirements and no post-launch ownership, the product manager knows the data will come back to them. Luna: So what's the one concrete takeaway for a CTO listening right now? Lucas: Stop mapping tech debt to code modules. Map it to features. Then ask product to help decide what to do with the features that are generating the most noise. The answer might not be 'refactor' — it might be 'redesign' or 'retire.' Luna: That's a simple shift in data classification that can completely change the conversation. Lucas: It really can. And it starts with a spreadsheet and a six-month lookback at your ticket system. You don't need a big tool or a consultant. You just need to tag tickets by product feature and see the pattern. Luna: I wonder if this approach works equally well for larger orgs, say 500 engineers or more, where the feature mapping might be more complex. Lucas: That's a great question. The CTO I spoke to thinks it scales, but you'd need a product taxonomy that's consistently applied. In his case, they had about 40 features total, so mapping was straightforward. At a larger company, you might need to do it at the product area level rather than individual feature level. Luna: So the principle holds — map cost to product decision — but the granularity adjusts. Lucas: Exactly. And I think there's a corollary here for how teams think about tech debt in general. If you treat it as a code quality issue, you're stuck in an infinite loop of refactoring. If you treat it as a product design issue, you have an exit strategy. Luna: That's the sound bite. I'm going to remember that: tech debt is a product design issue with an exit strategy. Lucas: It's not always true, but it's true more often than most CTOs realize. And the ones who act on it end up spending less time in maintenance and more time building things that actually matter. Luna: That's a good place to leave it. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.