Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How to Evaluate an Engineering Team's Technical Debt
Transcript
- Lucas: If you run an engineering team, you've probably said something like, 'We need to pay down technical debt.' But how do you actually measure it? Not just talk about it — measure it. Luna: I think most teams measure the wrong things. They count the hours spent refactoring, or the number of bugs, but those are lagging indicators. Lucas: Exactly. I was looking at a Series B fintech startup last quarter. They'd been growing fast — 40 engineers over two years — and their CTO told me she was trying to make a case to the board for allocating 20 percent of capacity to debt reduction. But the board asked, 'How much debt do we actually have?' And she didn't have a good answer. Luna: So how did she figure it out? Lucas: She built something she called a 'debt to asset ratio' for their codebase. Not financial debt — engineering debt. She looked at the ratio of lines of code that were actively maintained with tests and documentation versus code that was untested, undocumented, or duplicated. Luna: That's interesting. But isn't lines of code a flawed metric? You can have a small amount of very bad code that causes huge problems. Lucas: Right, she didn't stop there. She weighted the 'bad' lines by how often they changed. A small module that gets touched every sprint is way more expensive than a big block of legacy code that no one touches. So she tracked 'change frequency' times 'debt density' per module. Luna: So the interest rate is higher on code that you're actively working on? Lucas: Exactly. That's the analogy she used with the board. She said, 'If we don't fix this module, every new feature in that area will take 30 percent longer. That's our annualized interest rate.' The board understood that immediately. They approved the 20 percent allocation. Luna: I think that's a much better framing than the typical 'we need to refactor because the code is messy.' It ties it to delivery speed. Lucas: The other thing she did was distinguish between deliberate and inadvertent debt. Deliberate debt is when you knowingly ship something that's not perfect because you need to hit a deadline. That's fine — you're making a trade-off. You can track it. Luna: And inadvertent debt is the stuff you didn't plan to accumulate. Bad patterns that spread, or dependencies that go stale. Lucas: Right. Most teams don't track the deliberate stuff, so they can't even tell which bucket each piece of debt falls into. She created a lightweight register — just a spreadsheet — where engineers logged any shortcut they took with an estimate of the 'interest' it would cost. Luna: That feels like it could become bureaucratic if you're not careful. Lucas: It can. But she kept it low-friction: a single row per sprint, per team, in a shared doc. The act of writing it down made the debt visible. And after a quarter, she had a heat map of where the pain was concentrated. Luna: What did the heat map show? Lucas: The biggest pain point was their payments pipeline. It had been built by a contractor in a hurry, and every time they added a new payment method — which happened every month — the team spent about two weeks untangling it. That was a clear high-interest debt. So they refactored that one module over six sprints. Luna: And after the refactor, did the velocity improve? Lucas: Yes. Adding a new payment method went from two weeks to three days. And the team reported a drop in stress levels, which is hard to quantify but matters. Luna: I've seen a similar pattern at larger companies. At a previous job, we had a monolithic build system that took 45 minutes for a full build. Everyone just accepted it. But when we measured it, the cumulative time spent waiting for builds was something like 150 engineer-hours per week. Lucas: That's a classic invisible debt. Nobody thinks to measure it because it's just part of the routine. But once you put a number on it — 150 hours a week — it becomes an obvious target. Luna: So the first step is making the debt visible. But then you have to decide what to tackle first. How do you prioritize? Lucas: The CTO I mentioned used a simple framework: for each item in the debt register, she estimated the interest cost per month — how many hours it cost the team — and the cost to fix it. Then she took the ratio: interest divided by fix cost. That gave her a return on investment for each refactoring. Luna: So the highest ratio items get done first. Lucas: Right. And she found that the top 20 percent of items accounted for about 80 percent of the total friction. Classic Pareto principle. So she didn't need to fix everything — just the stuff that was costing the most. Luna: I think a lot of engineering leaders feel pressure to fix all the debt, and that's paralyzing. It's better to pick the 20 percent that gives you 80 percent of the benefit. Lucas: Exactly. And the board appreciated that framing. They weren't being asked to write a blank check for 'code quality.' They were being asked to invest in specific modules with a projected return. Luna: One thing I wonder about: how do you prevent the debt from coming back? If you fix a module but the same patterns persist, you'll be back in the same place in six months. Lucas: She introduced two things. First, she added a 'debt budget' to the definition of done for every feature. If you ship a feature that introduces deliberate debt, you have to log it. Second, she had the team adopt a 'boy scout rule' — leave the code a little cleaner than you found it. Not a grand refactor, just small improvements. Luna: That's a cultural shift. It takes time. Lucas: It does. But she said the biggest change was simply having the data. Once engineers could see the debt register and the interest rate, they started self-policing. They didn't want to add to the pile. Luna: I think there's also a risk that the debt register becomes a blame tool. 'You took that shortcut two sprints ago.' Lucas: She was careful about that. The register was anonymous — no names attached to any item. It was about the code, not the person. And she framed it as a learning tool, not a performance review. Luna: That's smart. If you attach names, people will stop logging things. Lucas: And the other thing she did was celebrate the refactoring wins. When the payments pipeline fix went live, she sent a company-wide email with the before and after numbers. That showed that debt reduction wasn't just janitorial work — it was value creation. Luna: I think that's a great approach. It's methodical, data-driven, and it respects that you can't fix everything at once. Lucas: If today's tech conversation gave you something usable, the way these episodes stay ad-free is listener support. You can buy me a coffee dot com slash fexingo — that's buy me a coffee dot com slash fexingo. It helps us keep digging into these topics without any sponsors. Luna: Yeah, it's a small way to keep the conversation going. And speaking of going — I'm curious, Lucas, have you seen any teams use automated tooling to track debt? Like SonarQube or similar? Lucas: We can do a whole episode on that. But briefly — yes, tools can surface code smells and duplication, but they don't capture the business context. A high complexity score in a rarely-touched module is less important than a medium score in a frequently-changed one. So I think tools are a starting point, but the human judgment of 'what's costing us time right now' is still the key. Luna: Right. The numbers give you a conversation starter, not the answer. Lucas: Exactly. And that's the takeaway: measure what you can, prioritize ruthlessly, and make the debt visible to everyone — including the board.