Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Turn Down Projects Without Looking Lazy
Transcript
- Lucas: A couple of weeks ago I was talking to a staff engineer at Google who told me the single hardest skill he learned in his first five years wasn't writing faster code or debugging production incidents. It was learning how to say no to a project without making his manager think he was lazy. Luna: That is such an underrated skill. Because in FAANG especially, there's this cultural pressure to say yes to everything, right? Every project is framed as high-impact, every ask is urgent. Lucas: Exactly. And the default move for most early-career engineers is to just take it all on, which leads to burnout and mediocrity across the board. But the problem is, saying no the wrong way can brand you as not a team player. So today I want to look at a specific case — a senior engineer at Meta who turned down a high-visibility initiative to stay focused on a platform migration, and how she did it without damaging her reputation. Luna: Was this the one where the migration was already behind schedule and a VP came in with a shiny new feature request? Lucas: Exactly that. The migration was a core infrastructure piece — moving a critical service from a monolithic backend to a microservices architecture. It was already slipping because of dependencies on another team. Then a VP from a product org comes in and says, 'Hey, can you lead this new feature we want to ship for Q4? It's high-visibility, execs are watching.' Luna: And the natural instinct is to say yes because it's a VP asking, right? You want that visibility. Lucas: Of course. But she had a staff engineer mentor who told her something really specific: 'If you say yes to this, you're implicitly making a bet that you can deliver both. If you can't, you'll be known as the person who drops balls.' So instead of a flat no, she scheduled a 1:1 with the VP, and she framed it around trade-offs. Luna: How did she frame it? Because I imagine 'I don't have bandwidth' sounds like an excuse. Lucas: Right. 'I don't have bandwidth' is passive. It makes it sound like you're overwhelmed and can't handle your workload. She did something different: she said, 'I want to make sure I deliver excellence on the migration, which is already behind. I can take on this new initiative, but I'd need to push the migration by two quarters and I'd need to hand off the microservices design to someone else. Are you comfortable with that trade-off?' Luna: That's smart. She's not saying no — she's saying 'here's the cost of yes.' And she's putting the decision back on the VP. Lucas: Exactly. The VP thought about it for a second and said, 'No, the migration is more important. I'll find someone else.' And she came out of that conversation looking like a thoughtful engineer who understands priorities, not someone who's dodging work. Luna: So the reframe is: instead of 'I can't,' you say 'I could, but here's what would suffer.' That aligns with the company's goals rather than your personal capacity. Lucas: That's the core move. And I think it works because it uses the manager or VP's own prioritization framework against them. You're not protecting your time — you're protecting the outcome they care about. Let me give you another example. I know a senior engineer at Amazon who was asked to join a new 'innovation sprint' team. It sounded exciting, but he was already the lead on a critical latency reduction project. Luna: What did he do? Same framing? Lucas: Similar but slightly different. He went to his manager and said, 'I'd love to contribute to the sprint. I could spend 20 percent of my week there, but that means the latency project's timeline would stretch by about a month. If that's acceptable, let's do it. If not, maybe I can contribute a design doc early on and then step back.' Luna: So he offered an alternative. He didn't just say no — he created a smaller yes. Lucas: Right. The manager ended up going with the design doc option, which took maybe a week of his time, and then he stayed focused on the latency project. And the manager appreciated that he'd thought through the trade-offs. That's the difference between being seen as inflexible versus being seen as strategic. Luna: I want to push back a little though. Doesn't this assume you have a manager who's reasonable and open to that conversation? What if you have a manager who just says, 'Figure it out, do both'? Lucas: That's a great point. That happens. In that case, you need to escalate the trade-off conversation to a wider audience. You can say in a team meeting or a sprint planning session, 'I've been asked to do X and Y. Both are important. I can only fully deliver on one in the next quarter. Can the team help me prioritize?' That forces the decision into the open. Luna: And it protects you because you're not the one making the call — you're surfacing the constraint. Lucas: Exactly. Another tactic is to use the phrase 'I want to make sure I don't become a bottleneck.' That signals awareness that taking on too much can actually slow things down. It's a more mature framing than 'I'm too busy.' Luna: I've also heard of engineers using a simple rule: before saying yes to anything new, they ask 'What should I deprioritize to make room for this?' That forces the asker to acknowledge the trade-off. Lucas: Yes. And if they can't name something to deprioritize, then they're not serious about the ask. Let's talk about timing. The worst time to say no is in a group setting — like a sprint planning meeting where everyone's watching. The best time is in a 1:1, where you can have a candid conversation. The Meta engineer I mentioned did it in a 1:1 with the VP. The Amazon engineer did it with his manager in their weekly sync. Luna: So the rule is: say no privately, not publicly. That avoids any perception of grandstanding or negativity. Lucas: Exactly. And it gives the other person room to save face. They can pivot without looking like they were overruled. One more thing: if you've built a reputation for delivering on commitments, your 'no' carries more weight. People trust that when you say you can't take something on, it's because you're already doing something important. That's why it's worth under-promising and over-delivering early in your career. Luna: That's a really good point. Your track record is your currency for being allowed to say no later. Lucas: Right. Nobody trusts the person who says no but also misses deadlines. So if you want to be able to say no effectively, first make sure your yeses are reliable. And you know, this whole conversation reminds me of something — if you've found today's episode useful, there's a simple way to help keep these conversations going. Luna: Yeah, and it's not about a big commitment — it's more like a coffee's worth. Lucas: Exactly. We keep the show ad-free because that feels right for the kind of deep-dive conversation we want to have. If you've gotten something out of it, you can support us at buy me a coffee dot com slash fexingo. That's buy me a coffee dot com slash fexingo. Even a couple of dollars a month genuinely makes a difference in keeping the podcast sustainable. Luna: And it helps us keep bringing in guests and digging into these practical career angles. So if you've ever thought about it, that's the place. Lucas: Alright, back to the topic. I want to talk about one more nuance — how to say no to a project that's already been assigned to you. That's a different situation because you're not just declining a new ask, you're backing out of something you've already committed to. Luna: That's even harder, because there's an expectation you'll deliver. Lucas: Right. The key there is to catch it early. If you realize two weeks in that the project is going to take twice as long as expected, don't wait until the deadline to say something. Go to your manager and say, 'I've spent two weeks on this and I'm seeing that the complexity is higher than anticipated. I think we have two options: either we adjust the scope or we bring in another person. Otherwise, I'm worried we'll miss the deadline.' That's not a no — it's a renegotiation. Luna: It's a course correction. And most managers prefer that to a surprise failure. Lucas: Absolutely. I've seen engineers earn more trust by surfacing a problem early than by trying to heroically power through and then missing the mark. So to sum up today: if you want to say no without looking lazy, frame it as a trade-off, offer alternatives, say it privately, and make sure your track record backs it up. And if you're already in a commitment you need to get out of, speak up early with options. Luna: One thing I'd add: practice saying no to small things first. Like, if someone asks you to join a meeting that could be an email, say 'I can't make that time, but happy to review the notes.' That builds the muscle. Lucas: That's a great way to start. It's low stakes, and it gets you comfortable with the language. Alright, that's all for this episode. Next time we'll talk about how FAANG engineers handle being the only person who knows a critical system — and how to avoid becoming a single point of failure.