Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Handle Ambiguous Project Requirements
Transcript
- Lucas: You've been handed a project with a one-line description — 'improve developer velocity' — and told to run with it. No metrics, no deadline, no definition of done. Luna: That's not a project. That's a trap. Lucas: Exactly. And it happens all the time at big tech companies. I want to look at how FAANG engineers actually handle ambiguous requirements — not the textbook advice, but what really works on the ground. Luna: I've seen this firsthand. My friend at Meta was assigned something similar in early 2026 — 'reduce friction in the internal CI pipeline'. No numbers, no scope. He spent three months building a dashboard nobody asked for. Lucas: Right — and that's the classic failure mode. You interpret ambiguity as freedom and build something impressive but irrelevant. The engineers who succeed treat ambiguity as a negotiation problem, not a design problem. Luna: Speaking of negotiation — before we get into the tactics, I want to mention something. If you're getting value from these conversations, listeners like you are what keep this show going. We keep it ad-free and focused on real career strategy. Lucas: Yeah. If you find yourself forwarding an episode to a teammate or referencing one of these frameworks in a standup, that's the signal. The best way to support us is a coffee at buy me a coffee dot com slash fexingo. It genuinely helps. Luna: And it keeps the podcast independent — no sponsor pressure to dilute the content. So, back to ambiguous requirements. What's the first move when you get that vague one-liner? Lucas: The first move is to schedule a fifteen-minute meeting with whoever gave you the project and ask three questions: What outcome do you expect in thirty days? What metric would convince you this project succeeded? And who else needs to sign off on that metric? Luna: That last one is key. Because sometimes the person who assigned it isn't the real stakeholder. Lucas: Exactly. At Google, I saw a team waste a quarter on a 'latency reduction' initiative that looked great to their director but didn't matter to the product team actually using the service. The stakeholder wasn't the director — it was the product manager who never asked for faster load times. Luna: So who is the real stakeholder? Anyone whose work depends on your output — or whose metrics change because of your project. Lucas: Right. Once you identify them, you write a one-page 'definition of done memo' and email it to everyone involved before you write a single line of code. The memo states: the problem we're solving, the metric we're targeting, the expected improvement, and what we will not do. Luna: The 'will not do' part — that's the boldest move. Most engineers are afraid to say no. Lucas: It's also the most respected move. At Amazon, writing a 'what we will not do' section is practically a requirement for any new initiative. It shows you understand scope. And it prevents the stakeholder from adding features later and blaming you for scope creep. Luna: What if the stakeholder pushes back? Like, 'no, we need this too'? Lucas: Then you use the 'three options' strategy. You present three versions of the project: Option A — minimal scope, delivers in one month on the core metric. Option B — includes the stakeholder's extra request, delivers in three months. Option C — full wish list, delivers in six months. You force a trade-off decision. Luna: That's brilliant because it reframes the conversation from 'can you add this?' to 'what are you willing to deprioritise?' Lucas: Exactly. And it works because stakeholders respect engineering judgment when it's presented as a clear decision, not a complaint. I've seen this used at Apple to navigate a notoriously vague 'improve app stability' directive. The engineer proposed three timelines tied to crash rate thresholds, and the product manager immediately picked the middle option. Luna: Let's talk about the emotional side. When you're a junior engineer and your manager hands you something ambiguous, it's easy to feel like you're failing because you don't know where to start. Luna: I think the worst thing you can do is pretend you understand and then try to figure it out alone. Lucas: Completely agree. The best engineers I've seen at any level — at Microsoft, at Netflix — they ask clarifying questions openly in the first week. They don't worry about looking smart. They worry about wasting time. Luna: And they often frame those questions as 'I want to make sure I deliver what matters most to you — can you help me rank these priorities?' Lucas: That's a great phrase. It signals humility and competence at the same time. Now, there's a specific pattern I've noticed at Meta that's worth dissecting. Meta's internal tooling teams often get projects with a vague goal like 'increase developer happiness'. Lucas: Engineers who succeed there immediately anchor to a proxy metric — like time saved per developer per week — and get that metric validated by at least two teams before they start. Luna: So it's not about finding the perfect metric. It's about finding a defensible one that everyone agrees is directionally correct. Lucas: Yes. And if you can't find a defensible metric, that's a red flag. It means the project is either too vague to succeed, or the real goal is political — like making a team look busy. In that case, the smart play is to propose a very short exploration phase. Luna: What does that look like in practice? Lucas: You say: 'Let me spend two weeks interviewing five teams who would use this, gather their pain points, and come back with a ranked list of opportunities. Then we decide together.' That buys you time to understand the landscape without committing to a solution. Luna: I've seen that work at Amazon. The engineer who does that often ends up discovering that the real problem is completely different from what the vague directive implied. Lucas: Exactly. A classic example: a team at Google was told to 'improve code review turnaround time'. The engineer who did the exploration phase found that the bottleneck wasn't reviewer speed — it was that the CI pipeline broke so often that reviews were abandoned. They fixed the CI pipeline instead, and review time dropped thirty percent. Luna: So the exploration phase also protects you from solving the wrong problem. Lucas: It does. And it builds credibility with stakeholders because you're showing you care about outcomes, not just shipping code. Luna: Let's get tactical. What's the single most underused tool for taming ambiguous requirements? Lucas: The one-pager. Not a design doc — a one-page, bullet-point document that you share before any coding starts. It forces you to make your assumptions explicit. And it gives stakeholders a chance to disagree early, when it's cheap. Lucas: At Netflix, engineers are expected to write a one-pager for any project that takes more than two weeks. It's not optional. And it's saved countless projects from going off the rails. Luna: What about when the ambiguity comes from multiple conflicting stakeholders? You get one manager saying 'move fast' and another saying 'make it robust'. Lucas: That's the hardest scenario. The move there is to invite both stakeholders to a thirty-minute meeting, present your one-pager, and explicitly call out the tension: 'I can optimize for speed or for robustness. Which should I prioritize for this first release?' Lucas: If they both insist on both, you escalate to the decision-maker who outranks them — usually a director or VP — and let them make the call. Luna: So you're not asking for permission to make a decision. You're forcing the tension to surface where it can be resolved. Lucas: Exactly. And that's a leadership skill that gets noticed at promo time. Managers remember the engineer who unblocks a project by making tough trade-offs visible. Luna: I want to circle back to the emotional resilience angle. I think a lot of listeners — especially early career — feel like if they ask too many questions, they'll seem incompetent. Luna: But the data from internal surveys at companies like Microsoft shows that engineers who ask clarifying questions in the first two weeks are rated higher by their managers at the end of the quarter. Lucas: That makes sense. Because asking questions early signals that you care about delivering something useful. The engineers who don't ask questions often deliver something irrelevant and then need more time to fix it. Lucas: My closing thought: ambiguous requirements are not a bug in big tech culture. They're a feature. Companies like Meta and Google intentionally give you room to define your own impact. The engineers who thrive are the ones who treat ambiguity as a design constraint — not a blank check. Luna: And the ones who struggle are the ones who wait for clarity to come from above, instead of going out to find it. That's a good note to end on. Lucas: Next episode: how top engineers handle the opposite problem — when the requirements are so detailed that you have no creative freedom. See you then.