Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Handle Co-Workers Who Don't Pull Their Weight
Transcript
- Lucas: You're on a pod at a FAANG company — say Google, Meta, Amazon — and there's this one engineer with the same title as you, same level, same expectations. But they're just... not delivering. Their pull requests come in late, the code is buggy, they skip design reviews. And you're the one picking up the pieces. Luna: It's one of the most awkward situations in tech because you don't want to be the complainer. But you also don't want to burn out carrying someone else's weight. Lucas: Exactly. And the standard advice — 'just talk to them, give feedback' — often backfires if you haven't done it right. So today I want to walk through a specific case I heard from a senior engineer at Google. This person had a peer, same L5 level, who was consistently underperforming on a shared project. The project was slipping. The senior engineer was staying late to fix bugs the peer introduced. Luna: What did they do first? Lucas: They didn't go to their manager right away. Instead, they spent about two weeks collecting what I'd call 'behavioral data' — not opinions, not vibes. Specific instances: three pull requests that missed the sprint deadline by two days, two design reviews where the peer showed up unprepared and then didn't read the follow-up comments, four bugs in production that traced back to their code. Luna: So concrete examples rather than 'you're not pulling your weight.' That's smart. Lucas: Right. Then they scheduled a one-on-one with the peer. Not an ambush — they said, 'Hey, I want to talk about how our collaboration is going on Project X.' And in that meeting, they used a framework I really like: they framed it as 'project health,' not personal failing. They said something like, 'I've noticed the project is slipping in these areas, and I think we can work better together. Here are three specific things I've observed...' Luna: How did the peer respond? Lucas: Initially, defensively. The peer said they'd been busy with on-call rotations and that the requirements were unclear. Which is a common deflection. But because the senior engineer had data, they could say, 'I understand, but these three pull requests all had the same kind of regression bug — it suggests we need a stronger testing habit.' They kept it about the work. Luna: And did that lead to improvement? Lucas: For about two sprints. Then it slipped again. So the senior engineer had to escalate — but they did it carefully. They went to their tech lead first, not their manager. They said, 'I want to share some patterns I'm seeing because I'm worried about the project timeline. Can you help me think about how to support this person better?' Luna: That's a subtle reframe — you're not complaining, you're asking for help to support the team. Lucas: Exactly. And the tech lead already had suspicions because they'd seen the same patterns in code reviews. So together they came up with a plan: the peer would get paired with a more senior engineer for the next complex feature, and the tech lead would do more frequent check-ins. No one got fired. No one got a bad performance review overnight. But the project started moving again. Luna: I think a lot of engineers in this situation are afraid that if they speak up, they'll look like they can't work with others. But the way this person handled it — data, project health framing, tech lead as ally — it's almost invisible escalation. Lucas: And that's the key. You want to escalate the problem, not the person. And you want to do it in a way that gives the underperformer a path to improve. Because sometimes they're not lazy — they're overwhelmed, or they've been given unclear expectations. Luna: Talk to me about when you should just absorb the slack versus when you have to speak up. Because there's a cost to both. Lucas: There's a framework I've seen from engineering managers at Amazon — they call it the 'two-week test.' If you can absorb the extra work for two weeks without burning out or blowing your own commitments, and if the project isn't at risk of missing a major milestone, sometimes it's okay to just cover. But if after two weeks you're still picking up slack, or if the project is visibly in jeopardy, you have to escalate. Because at that point, staying silent is hurting the team more than it helps the peer. Luna: I like that — it gives you a concrete boundary instead of just wondering 'am I being too harsh?' Lucas: And this is also where company culture matters. At Amazon, the ownership principle means you're expected to speak up if the team is at risk. At Google, there's a stronger norm of peer feedback and assuming good intent. But in both cases, silence is not a virtue. Luna: What about when the underperformer is more senior than you? Like if it's a staff engineer who's disengaged? Lucas: That's harder because the power dynamic flips. In that case, you almost never go direct. Instead, you go to your own manager and say, 'I'm struggling to get the guidance I need from this staff engineer on this project. Can you help me think about how to get unstuck?' Your manager will likely have a conversation with the staff engineer's manager. But again, you're framing it as a need for help, not an accusation. Luna: Good. I also want to touch on something that comes up a lot in our listener questions: what if the underperformer is a friend? You've worked with them for years, and now they're slipping. Lucas: That's the toughest version. I had a friend at Microsoft who went through this. His buddy from two jobs ago joined his team, and six months in, the buddy was clearly checked out — taking long lunches, missing stand-ups, delivering half-baked code. My friend didn't want to damage the friendship. But the project was suffering. Luna: What ended up happening? Lucas: He had an honest conversation outside of work — over coffee, not in the office. He said, 'Dude, I'm worried about you. You seem disengaged. Is everything okay?' And it turned out the buddy was dealing with a family issue and was afraid to ask for a leave of absence. So they worked together to get him the time off he needed. He came back three months later, refreshed, and was fine. Luna: So the underlying issue wasn't laziness — it was personal. And treating it as a human conversation first, rather than a performance escalation, saved the friendship and the project. Lucas: Exactly. Which is why my number one piece of advice before escalating anything is: assume good intent, but verify with data. Talk to the person as a human being first. Ask if they're okay. Because sometimes the fix is simpler than you think. Luna: And if they're not okay, and the personal issue persists, then you loop in HR or the manager — but you do it with compassion. Lucas: Right. And for the listener who's dealing with this right now — maybe you're three sprints into covering for someone and you're exhausted — I want to give you one concrete script. You can say: 'Hey, I want to talk about how we're working together. I've noticed a few patterns that are making it hard for me to keep the project on track. Can we spend fifteen minutes on Thursday to align on expectations?' Luna: Short, neutral, action-oriented. That's good. Lucas: And if that conversation doesn't lead to change within a sprint or two, then you escalate to your tech lead using the same neutral language. 'We had a conversation about expectations, and I'm not seeing the shift yet. Can you help me think about next steps?' Luna: You know, it strikes me that this whole conversation is about a skill that's rarely taught in engineering bootcamps or even in most management training: how to have these difficult horizontal conversations without damaging relationships. Lucas: It's absolutely a meta-skill. And I think it's one of the things that separates engineers who stay at senior levels from those who plateau. Because at L5 and above, your impact depends on your ability to influence peers — not just write code. And if you can't handle a teammate who's not carrying their weight, your whole pod suffers. Luna: Before we wrap, I do want to pull back the curtain on something. A handful of you listening right now make this show possible. We keep this podcast ad-free because listeners chip in through buy me a coffee dot com slash fexingo. And honestly, that's what funds us producing episodes like this — deep dives on the real interpersonal stuff that most career advice glosses over. Lucas: Yeah, we don't run ads, we don't sell courses, we don't do sponsored segments. The only reason we can spend this much time on a single episode is because some of you choose to support the show directly. So if you've been getting value from these conversations, that's the way to keep them coming. Luna: Okay, back to the topic. One thing I want to add: after you've escalated, don't become the de facto manager of the underperformer. That's not your job. You've raised the flag. Let the system handle it. Lucas: That's a really important point. Once you've surfaced the issue to the right person — your tech lead or manager — you don't need to keep monitoring. You've done your part. If the organization doesn't act, that's on them, not on you. And it also protects you from being seen as the person who's always complaining. Luna: Alright, let's leave listeners with a question to think about: Is there someone on your team right now who you've been covering for — and what would happen if you stopped absorbing that slack for one sprint? The answer might tell you whether your silence is helping or hurting. Lucas: That's a great challenge. And if you have a story about how you handled this situation — or if you're stuck and want advice — send us a note. We read every one.