Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Deal With Underperformance on Their Team
Transcript
- Lucas: You join a team at a FAANG company — you're excited, you're motivated, you want to ship. But within a few weeks, you notice something: one teammate consistently misses deadlines, their code has more bugs, they rarely speak up in design reviews. What do you do? Luna: That's an uncomfortable spot. Because you're not their manager, but their output affects your velocity. Lucas: Exactly. And in big tech, especially at companies like Meta or Amazon, team performance is evaluated collectively. If someone is underperforming, it drags down the whole team's delivery metrics — and that can hurt everyone's performance review. Luna: So what's the first move? Do you talk to them directly? Lucas: The first step is actually a self-check. Ask yourself: is this a pattern or a one-time thing? One missed sprint could be a personal issue. Three missed sprints? That's a pattern. I've seen engineers jump to conclusions after a single delay, and that creates unnecessary friction. Luna: Fair. So you need data before any conversation. Lucas: Right. You want to look at specific, observable behavior. Not 'they seem unmotivated.' Instead: 'they committed to three tasks in the last sprint and completed one. Their pull request had five critical comments that went unaddressed for a week.' Concrete. Luna: And once you have that data, you talk to them? Lucas: Ideally, yes — one-on-one, informally. Phrase it as curiosity, not accusation. Something like: 'I noticed you've been struggling with the API migration. Is there something blocking you that I can help with?' That opens the door without putting them on the defensive. Luna: But what if they're defensive anyway? Or they say everything's fine but the pattern continues? Lucas: That happens. In that case, you document. Not in a gotcha way, but for yourself. Dates, specifics, what was discussed. Then you bring it to your manager — but carefully. You don't want to sound like you're complaining. Frame it as a concern about the project: 'I'm worried about the timeline for the API migration because I've seen X, Y, Z. Can we discuss how to support the team member?' Luna: So you're making it about the work, not the person. Lucas: Exactly. And a good manager will take it from there. They might already be aware. But here's where it gets tricky: sometimes the manager is the reason the underperformance isn't being addressed. Maybe they're overloaded, maybe they're avoiding conflict. Luna: That's a hard place to be. Do you escalate further? Lucas: It depends. If it's truly blocking your work and affecting your own performance review, you might need a skip-level conversation. That's where you talk to your manager's manager. But you need to be very careful — you don't want to be seen as going over someone's head without good reason. Luna: Is there a framework for when that's appropriate? Lucas: I'd say if you've tried direct conversation, documented the pattern, raised it with your manager, and three months later nothing has changed — that's when you consider a skip-level. But even then, frame it as a systemic issue, not a personal complaint. 'Our team's velocity is suffering because we don't seem to have a process for addressing stalled tasks.' Luna: I've heard of a 'fail fast, fix fast' culture at some FAANGs. Does that apply here? Lucas: It does. The idea is to identify underperformance early and address it quickly. At Netflix, they have a famous 'keeper test' — managers ask themselves: 'If this person told me they were leaving, would I fight to keep them?' If the answer is no, they're encouraged to let them go. That's extreme, but it creates a culture where underperformance isn't allowed to fester. Luna: That sounds harsh. But maybe it's better than the alternative — everyone knows someone is struggling but no one says anything. Lucas: Right. And that silent suffering hurts morale. I've seen teams where one underperformer causes the rest to burn out trying to compensate. That's worse for everyone. Luna: Let's talk about a real example. I heard about a senior engineer at Alphabet who was three sprints behind on a critical dependency. What happened? Lucas: I know that case. The team first tried pairing — they offered to pair program with him for a week. He resisted, said he preferred to work alone. Then they tried breaking the work into smaller tasks. Still no progress. They documented everything: four weeks of missed commitments, no communication about blockers. Luna: And then? Lucas: The tech lead escalated to the manager. The manager had a formal performance conversation, which led to a performance improvement plan — a PIP. The engineer was given six weeks to meet specific milestones. He didn't meet them. Eventually he was let go. It was painful, but the team's velocity recovered within two months. Luna: So the PIP worked as intended. Lucas: In that case, yes. But PIPs are controversial. Some people see them as a death sentence — once you're on a PIP, you're likely out. At Amazon, PIPs are notoriously hard to survive. At Microsoft, they're sometimes used as a genuine coaching tool. Luna: What about the emotional side? It's hard to be the person reporting a teammate. Lucas: It is. You feel like a snitch. But remember: underperformance isn't just about missed deadlines. It's about fairness to the rest of the team. Everyone else is working hard. If one person isn't pulling their weight, it's not kind to them to let it slide — they might be better off in a different role or company. Luna: That's a good point. Sometimes the kindest thing is to be honest. Lucas: And sometimes the person is just in the wrong seat. I've seen engineers who struggled on a backend team move to a tools team and thrive. Underperformance can be situational. Luna: So before assuming it's a talent issue, consider fit. Lucas: Exactly. That's another reason to start with a conversation. You might find out they're bored, or they're dealing with personal stuff, or they don't understand the codebase because they were onboarded poorly. All of those are fixable. Luna: Speaking of fixable — if you're the underperformer, what should you do? Lucas: First, acknowledge it. It's tempting to blame others or make excuses. But the best move is to ask for help early. Say: 'I'm struggling with this task. Can we pair on it?' That builds trust. Most managers would rather see you ask for help than silently fail. Luna: And if you're the manager, what's your approach? Lucas: Be direct but supportive. Set clear expectations with measurable milestones. Check in regularly. And don't let it drag on — the longer you wait, the harder it is for everyone. At Apple, I've heard managers use a '30-day fix' approach: identify the gap, give 30 days to show improvement, then reassess. Luna: That seems like a reasonable timeline. Lucas: It is. And it respects the person's time — they know where they stand, and if it doesn't work out, they can start looking for a new role sooner rather than later. Luna: I think a lot of listeners are probably nodding along because they've been in this situation — on either side. Lucas: Yeah. And honestly, if today's conversation gave you something usable, that's the link — buy me a coffee dot com slash fexingo. It's a small way to keep this show ad-free and focused on real career strategy. Luna: It's true. We don't run ads, so listener support is what keeps us going. Even five dollars helps. Lucas: So back to the practical takeaway: the key is to act early, with data and empathy. Don't let it fester. Whether you're the observer, the underperformer, or the manager, a timely conversation is almost always better than silence. Luna: And if you're the one struggling, remember: asking for help is a sign of strength, not weakness. Lucas: Well said. That's all for this episode — thanks for listening, and we'll see you next time.