Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Manage Technical Debt Without Breaking Things
Transcript
- Lucas: I want to talk about something that lives in the shadows of every FAANG codebase — technical debt. Not the abstract concept, but the actual cost it imposes on a team and how good engineers manage it without breaking things. Luna: I feel like every engineer I know complains about tech debt, but nobody ever agrees on what to do about it. How do you even measure something that's invisible? Lucas: Right. It's invisible until it isn't. Let me give you a concrete case. A couple years ago I was talking to an engineer who'd been on a payments pipeline team at Meta. They had deferred refactoring for about 18 months — just piling features on top of a system that was never designed for the scale it hit. Luna: Eighteen months. That's not just debt, that's a mortgage. Lucas: Exactly. And the cost became visible when a simple A/B test that should have taken two weeks took six. Every change required three extra rounds of testing because nobody was confident the spaghetti wouldn't break. By the end, their feature velocity had dropped about 30 percent compared to a parallel team that had kept their codebase cleaner. Luna: If today's conversation gives you a framework for thinking about your own codebase — and I hope it does — the way this stays ad-free is listener support. People who find it useful sometimes drop a coffee at buy me a coffee dot com slash fexingo. Just a mention, not a pitch. Back to the payments pipeline — how did that team eventually dig out? Lucas: Yeah, so they did a phased rewrite, but the interesting part is how they prioritized. They didn't try to fix everything. They picked the top three pain points — the modules that caused the most merge conflicts and the longest test cycles — and tackled those first. That's actually a principle you see at Google: the 'boy scout rule' — leave the code a little cleaner than you found it. It's a small habit, but over a quarter it compounds. Luna: So you're not talking about a big bang rewrite. You're talking about incremental improvement baked into the normal workflow. Lucas: Exactly. A lot of teams at Google use what they call a 'debt budget'. They allocate 20 percent of every sprint to refactoring and cleanup. It's not a separate project — it's just part of the definition of done. That way debt doesn't accumulate to crisis levels. The key is making it a shared norm, not a heroic effort by one engineer. Luna: But how do you sell that to a product manager who only cares about shipping features? I've seen engineers try to say 'we need to refactor' and PMs hear 'we want to waste time on stuff users can't see.' Lucas: That's the million-dollar question. The best engineers I've seen reframe it in terms of shipping delay. Instead of saying 'this code is ugly', they say 'this module adds three days to every feature we build in this area. If we clean it up, we can ship the next three features two weeks faster.' Now you're speaking the PM's language — time to market. Luna: I like that. It's not about purity, it's about economics. Lucas: Right. And the numbers can be striking. A team at Uber that tracked their technical debt found that investing one sprint in refactoring a critical routing service cut their bug rate by 40 percent and increased their deployment frequency by 25 percent. That's real ROI. Luna: But isn't there a case where technical debt is actually strategic? I think about Monzo — they deliberately launched with a monolithic architecture even though they knew it wouldn't scale, because they needed to get to market fast. That debt was a conscious trade-off. Lucas: Absolutely. Strategic technical debt is a thing. The difference is intention. Monzo's team knew exactly what they were taking on and they had a plan to refactor once they hit certain milestones. The dangerous debt is the kind you accumulate by accident — the 'we'll fix it later' that never gets a later. That's what kills velocity. Luna: So how do you prevent that kind of accidental debt? Especially in a big org where no single person sees the whole picture? Lucas: A few things. First, code reviews that explicitly flag debt. At Amazon, some teams have a checkbox in the review tool: 'Does this change introduce technical debt? If yes, describe the plan to address it.' That forces the conversation. Second, regular architecture reviews — every quarter, the team spends two hours looking at the biggest sources of friction and ranks them. Third, and this is the hardest one — you need a culture where saying 'we need to slow down to speed up' is not a career-limiting move. Luna: That last one feels like the real bottleneck. I've seen junior engineers afraid to speak up because they think they're the only ones who see the mess. Lucas: And senior engineers sometimes enable that by acting like the debt is beneath them. But the best staff-plus engineers I know actually lead the debt conversation. They use data — like 'this service fails its SLAs 15 percent of the time because of this architecture' — and they present it calmly. They don't shame anyone. They just say 'here's the cost, here's the fix, here's the plan.' Luna: So it's a leadership skill as much as a technical one. Lucas: Exactly. And one more thing — avoid the trap of rewriting something that works. I've seen teams waste six months rewriting a perfectly functional internal tool just because the code was 'old'. That's not debt reduction, that's vanity. The question should always be: does this debt actually cost us anything? If a piece of code is ugly but nobody ever touches it, leave it alone. Luna: Good point. Not every messy closet needs to be organized — only the one you open every day. Lucas: Right. So to summarize: measure the cost of debt in shipping time, not aesthetic pain. Use a debt budget — 20 percent of each sprint. Frame it to PMs in terms of velocity, not engineering purity. And be intentional — know when you're taking on debt strategically and when you're just deferring pain. That's the difference between a team that moves fast and a team that's stuck. Luna: I think the 20 percent budget is the most actionable takeaway. I might try that in my own team. Lucas: Start small. Just track one sprint's worth of debt work and see how it feels. If the team gets faster, you've got your proof of concept.