Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Break Down Impossible Projects
Transcript
- Lucas: You get handed a project — and it's just… massive. Like, 'move our entire data pipeline from one system to another, and by the way, zero downtime.' Your first reaction is probably panic. Or maybe you start designing this elaborate architecture that's gonna take six months. Luna: Right — and that's when you end up building something that nobody asked for, or you never ship at all. Lucas: Exactly. So today I want to talk about what I've seen FAANG engineers do with projects that feel impossible. There's a pattern — they don't try to eat the whole elephant. They find the thinnest possible slice that still delivers value. Luna: A 'thin slice' — I've heard that term. Is that different from a minimum viable product? Lucas: Related but not the same. An MVP is the smallest thing you can ship to learn from users. A thin slice is the smallest end to end path through a system that proves the architecture works. It's not about features — it's about proving the flow is real. Luna: So you're not building the whole feature set. You're building one user journey from start to finish, but with real data, real infrastructure. Lucas: Precisely. Let me give you a concrete example. Say you're at a company like Uber — and you need to migrate the dispatch system from an old monolith to a new microservice. The natural instinct is to model every edge case: surge pricing, driver availability, rider cancellation, all of it. Luna: And that's a six-month project with a hundred-page design doc. Lucas: Right. A thin-slice approach asks: what's the smallest ride that goes through the new system end to end? Maybe it's a single city, a single time of day, with a fixed price and no surge. You build that, you test it with real traffic, and you prove the new system handles it. Luna: And once that works, you expand. City by city, feature by feature. Lucas: Exactly. I saw an engineer at my previous company do something similar. We had to migrate a search index — huge project, a hundred million documents. The team estimated six months. This engineer said: 'What if we migrate just the documents that were updated in the last hour?' That was the thin slice. Luna: And did it work? Lucas: He built a prototype in two weeks. It proved the new index was faster and more reliable for time-sensitive documents. Then we rolled out incrementally. The whole migration took three months instead of six. Luna: That's a massive time saving. But I imagine it requires buy-in from leadership — because they see 'thin slice' and think 'not ambitious enough.' Lucas: That's the hard part. You have to frame it as risk reduction, not scope reduction. Say: 'We can invest six months in something that might break, or we can invest two weeks in something that proves the approach, then scale.' Smart managers get that. Luna: So how do you actually identify the thin slice? Like, what's the heuristic? Lucas: There's a few. One is: find the most painful point for users or for your team. If onboarding is slow, the thin slice might be improving just the signup flow. Another is: find the path of least dependencies. If your project touches six services, can you start with the one that's independent? Luna: And you need to be honest about what's actually the thinnest slice. I've seen teams claim they're doing a thin slice but really they're still building a mini-monolith. Lucas: Yeah, that's a trap. The slice has to be end to end. You can't just build the new API and not hook it up to the database. You need to prove the whole chain works, even if it's a tiny chain. Luna: What about when the deadline is fixed and the scope is already set? You don't always get to choose the slice. Lucas: That's the reality for a lot of engineers. In that case, you negotiate scope. You say: 'I can deliver the full scope by the deadline, but the risk of bugs and outages is high. Or I can deliver this core slice on time with high quality, and we iterate after launch.' I've seen that work more often than you'd think. Luna: So it's about making the trade-off explicit. Not just saying 'I need more time,' but saying 'here are two paths, choose one.' Lucas: Exactly. Engineers who get promoted are the ones who frame trade-offs in terms of business impact. 'If we ship the full scope, we'll have four P0 incidents in the first week. If we ship the thin slice, maybe none.' That's a language leadership understands. Luna: I want to circle back to something you said earlier — about proving the architecture works. How do you measure that? Like, what metrics do you track for a thin slice? Lucas: It depends on the slice. For an infrastructure migration, latency and error rate are obvious. For a feature, maybe conversion rate or user engagement. The key is to pick one metric that — if you hit it — validates the whole approach. Then you design the slice to move that needle. Luna: So you're not trying to prove everything at once. You're trying to get a signal on the biggest unknown. Lucas: That's it exactly. The biggest unknown is usually: 'Will the new system actually be faster?' or 'Will users actually click this button?' So your thin slice answers that question, and nothing else. Luna: Let me ask about a specific scenario: what if the thin slice works, but then stakeholders want to add more features before you've fully proven the core? That scope creep can kill the momentum. Lucas: Yeah, that's a common problem. The thin slice works, and suddenly everyone has ideas. You have to protect the iteration cycle. Say: 'Let's run the thin slice in production for a week, collect data, and then we'll prioritize the next slice based on what we learn.' That keeps it data-driven instead of opinion-driven. Luna: And that also builds trust. When people see real numbers, they're more willing to wait for the next slice. Lucas: Right. And one thing I've noticed: engineers who are good at thin slices also get a reputation for shipping. They're the ones who always deliver something working, even if it's small. That reputation is gold at any big tech company. Luna: Speaking of delivering something working — and this is a bit meta — but I think our show benefits from a similar philosophy. We don't try to cover every angle; we pick one concrete thing each episode. Lucas: That's actually a great point. And you know, the reason we can keep doing this, ad-free and focused, is that a small group of listeners supports us directly. If today's tech conversation gave you something usable, and you want to help keep this going, you can find us at buy me a coffee dot com slash fexingo. Luna: Yeah, it's a low-key way to chip in. No pressure, but it genuinely helps us keep making episodes like this without any sponsor noise. Lucas: Alright, back to thin slices. One more technique I want to mention: the 'walking skeleton.' It's a term from software architecture — you build just enough of the system that it can 'walk,' meaning it does one tiny thing end to end. Then you add muscle. Luna: I love that image. A skeleton that walks. It's not pretty, but it's functional and it shows you the shape of the final system. Lucas: Exactly. And here's the counterintuitive thing: when you build a walking skeleton, you often discover that your initial architecture assumptions were wrong. Maybe the database queries are too slow, or the API contract doesn't work in practice. Better to find that out in week two than in month five. Luna: Absolutely. So the thin slice is also a learning tool. It's not just about shipping fast — it's about surfacing risks early. Lucas: Yes. And that's the real superpower. Engineers who embrace thin slices are constantly learning. They're not afraid to be wrong because they find out fast and adjust. Luna: Any final advice for someone who wants to start using this approach but their team culture is very waterfall — big design up front, long timelines? Lucas: Start small. Don't try to change the whole team's process. Pick a small, low-risk project — maybe an internal tool — and do a thin slice on it. Show the results. Share the metrics. Once people see that you shipped something real in two weeks that would've taken two months, they'll start asking questions. Luna: So it's almost like you need to create a proof of concept for the thin slice method itself. Lucas: Exactly. Lead by example. And if you're listening and you've tried this, let us know how it went. We'd love to hear your thin-slice story.