Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Say No to Extra Work Without Getting Fired
Transcript
- Lucas: You get an email from your skip-level manager on a Tuesday afternoon. Subject line: 'Quick ask — would love your help on something.' And your stomach drops, because you already know this isn't a quick ask. This is a six-week project that'll derail the feature you're already behind on. Luna: And every engineer I've ever talked to says their first instinct is to say yes. Because you want to be helpful, you want to be seen as a team player. Lucas: Right. The fear is that saying no labels you as difficult, or not a team player. But the data from actual performance reviews at top tech companies tells a different story. Managers consistently rate engineers higher when they proactively manage their workload, as long as they do it transparently. Luna: So the problem isn't saying no itself. The problem is how you say it. Lucas: Exactly. There's a three-part framework that I've seen work at Meta, at Google, at Amazon. I learned it from a senior staff engineer at Meta who was asked to lead a reorg integration project — exactly the kind of thing that sounds strategic but ends up being 40 hours of meeting hell. Luna: Oh, I want to hear this. What was his approach? Lucas: He didn't say no in the first reply. He asked for a 15-minute call to 'align on priorities.' That's part one: buy yourself time without committing. On the call, he used the framework. Step one: name the trade-off explicitly. He said, 'I can take on the reorg integration, but if I do, the analytics dashboard milestone slips by three weeks. That's the trade-off.' Luna: And that forces the manager to make a choice. They can't pretend the work happens without cost. Lucas: Step two: offer an alternative. He said, 'If the reorg work is more important, I can hand off the analytics dashboard to Jordan, who's been looking for more ownership. It'll take me a week to ramp them up.' Step three: commit to the outcome. 'Either way, I'll make sure the transition is clean and nothing falls through the cracks.' Luna: So he didn't say no. He said, 'I can do this, but here's what you lose, and here's a path to avoid losing it.' Lucas: Exactly. The manager ended up choosing to keep him on the dashboard and found someone else for the reorg. The manager actually thanked him for being clear. And this is the key insight: senior leaders hate surprises more than they hate hearing a no. They'd rather know the trade-off now than discover it in a month when the dashboard is late. Luna: And I bet that engineer's performance review reflected the fact that he was seen as someone who thinks about the whole system, not just his own tasks. Lucas: That's exactly what happened. His manager wrote, 'Consistently prioritizes work that delivers the highest impact.' That language came directly from that conversation. The framework works because it reframes 'no' as a strategic decision rather than a personal refusal. Luna: Let's talk about the common mistakes people make. What's the worst way to say no? Lucas: Ghosting. Or saying 'I'm too busy' without specifics. That sounds like an excuse. Also, saying yes and then underdelivering — that damages trust way more than an upfront no. Another mistake is saying no to a manager in a public channel. Always take it to a DM or a quick call. Luna: Right, so the medium matters. A Slack message saying 'sorry, can't' is different from a five-minute conversation where you show you've thought about it. Lucas: And timing matters too. The best time to set a boundary is when you're not yet overwhelmed. If you wait until you're underwater, the conversation is more stressful and you're less credible. Proactive boundary setting — like saying, 'I can take on one more project this quarter, not two' — is seen as leadership. Luna: It's like you're managing upward. You're teaching your manager how to allocate your time effectively. Lucas: Exactly. And this is where the concept of 'impact math' comes in. You literally say, 'I estimate this project takes X hours and yields Y impact. Compared to my current projects, it ranks Z.' That's the language of senior engineers. They talk in terms of impact per unit time. Luna: Speaking of impact per unit time — and this is a little meta — but we try to make every episode of this show high-impact for you. And the way we keep it ad-free and independent is that a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo. That's literally what funds making this many episodes. So if today's conversation gave you something usable, that's the way to keep it coming. Lucas: Yeah, and we appreciate every single person who does that. It lets us spend time on topics like this without worrying about sponsors. Alright, back to the framework. I want to give listeners a specific script they can use this week. Luna: Please do. I'm taking notes. Lucas: Here it is. You get an extra request. You reply: 'Thanks for thinking of me. Let me check my priorities and get back to you by end of day.' That buys you time. Then on the call, you say: 'I have bandwidth for one more project this quarter. If I take this on, I'll need to deprioritize X. Would you like me to proceed with this, or should I keep X as my top priority?' Luna: And what if they say, 'Just do both'? Lucas: Then you say, 'I can try, but based on past velocity, doing both means each will take 50% longer and may slip deadlines. I'd rather we pick one and do it well.' That's the key — you're not refusing, you're offering a realistic assessment. Most managers will respect that. Luna: And if they insist on both, you have a paper trail showing you flagged the risk. That CYA is important. Lucas: Absolutely. One more thing: don't overuse this. If you say no to everything, you'll be seen as unhelpful. The framework is for when you genuinely can't take on more without dropping something important. Use it maybe two or three times a quarter. Otherwise, say yes to stretch assignments that build new skills. Luna: So the art is knowing which requests to say yes to and which to redirect. That's the judgment that comes with experience. Lucas: And that judgment improves when you track your own work. Keep a simple log: what you worked on, how long it took, what impact it had. Then when a request comes in, you can quickly compare it to your current workload. That data is power in those conversations. Luna: I know engineers who use a spreadsheet or even a Notion database. It takes five minutes a week and pays off enormously in performance reviews and boundary setting. Lucas: Exactly. So to recap: buy time, name the trade-off, offer an alternative, commit to the outcome. That's the framework. And remember, your manager would rather have an honest conversation now than a surprise later. Luna: And if you want more scripts like this, you know where to find us. We'll be back next week with another episode. Lucas: Until then, keep shipping, and keep your boundaries clear.