Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Manage Their Reputation Across Teams
Transcript
- Lucas: There's this internal Google study from a couple years ago that tracked engineers who transferred teams and found that the ones who arrived with a documented reputation score from their previous team hit full productivity about 40 percent faster than those who didn't. Luna: Wait — a documented reputation score? Like, someone literally assigns you a number? Lucas: Not exactly a single number, but it's a composite from peer reviews, project retrospective mentions, and skip-level feedback that gets surfaced during the transfer process. The point is, reputation travels with you inside these companies more than most engineers realize. Luna: So it's not just the work you do — it's how people talk about the work you do. Lucas: Exactly. And that's something a lot of engineers, especially early- and mid-career ones, tend to underinvest in. They think good code speaks for itself. But in a big org, code doesn't speak nearly as loudly as the narrative around it. Luna: Right. I've definitely seen engineers who produce great work but stay heads-down, and then someone more visible gets the promotion. Lucas: That's the classic trap. So today I want to talk about the three pillars of cross-team reputation that I've seen matter most at places like Google, Meta, and Amazon: visibility, reliability, and advocacy. And I'll walk through concrete ways to build each one. Luna: Let's start with visibility. What does that actually look like in practice? Lucas: Visibility isn't about self-promotion or bragging. It's about making sure the right people know what you're working on and why it matters. The most effective approach I've seen is what I call the 'quarterly narrative' — every three months, write a one-page document summarizing the problem you tackled, the approach you took, and the impact. Luna: And who do you send that to? Lucas: Your manager, your skip-level, and two or three engineers you respect on other teams. Not a mailing list blast. The goal is to create a track record that people can reference when your name comes up in a promotion committee or a staffing discussion. Luna: That's smart. It also forces you to articulate your own impact clearly, which is harder than it sounds. Lucas: Much harder. The second pillar is reliability. And here I'm not just talking about shipping on time. I mean being known as someone who responds to code reviews promptly, who follows through on cross-team dependencies, and who communicates proactively when something slips. Luna: There's a study from MIT's Human Dynamics Lab that found the single best predictor of a team's performance was how evenly members contributed to discussions — not the team's average IQ. Reliability in communication matters that much. Lucas: That's a great data point. At Amazon, there's a leadership principle called 'Bias for Action' that basically codifies this. Engineers who are reliable build trust over time, and trust is the currency of internal mobility. Luna: The third pillar is advocacy. That's the one that trips people up the most, I think. Lucas: Because you can't really control it directly. Advocacy is what happens when other people voluntarily recommend you. The key insight from network science is that the most effective way to generate advocacy is to be a 'giver' — someone who helps others without expecting an immediate return. Luna: Adam Grant's research at Wharton showed that givers end up at the top of the performance distribution in technical roles, not the bottom. Even though they sometimes get taken advantage of in the short term. Lucas: Exactly. The practical takeaway: invest in helping colleagues with their design docs, volunteer to review code in areas you want to be known for, and share credit generously. Over time, those people become your advocates when you interview for a new team. Luna: So how does an engineer actually audit their current reputation before making a move? Lucas: There's a simple exercise I recommend. Pick five people you've worked with in the past year — your manager, a peer, a junior engineer, a product manager, and someone from another team. Ask yourself: what would each of them say about you in a thirty-second conversation? If you don't know, that's a signal. Luna: A more direct version: you can literally ask them. Most people will be honest if you frame it as 'I'm trying to understand my blind spots.' Lucas: And the best time to do that audit is before you start applying internally, not after. Because once you're in the pipeline, your reputation is already being evaluated. You want to shape it proactively. Luna: This is also where impostor syndrome can really mess with people. If you think you're a fraud, you're less likely to invest in visibility or ask for feedback. Lucas: That's such an important point. Impostor syndrome can make you go silent when you should be speaking up in design reviews, or decline to present at a team meeting. Each of those small withdrawals from the visibility bank accumulates. Luna: And the irony is that the people who need to build reputation the most are often the ones who feel the least entitled to. Lucas: Right. So here's a concrete strategy: next time you finish a project, write a brief postmortem or retrospective and share it with your team and a few people on adjacent teams. Not a corporate announcement — just a few paragraphs on what worked, what didn't, and what you learned. That one habit, done consistently, builds visibility and reliability simultaneously. Luna: I like that because it's low-stakes. It's not asking for a promotion, it's just documenting reality. Lucas: And it creates a paper trail that your future skip-level or hiring manager can find. A couple of years of those documents is worth more than a dozen glowing performance reviews. Because they show how you think. Luna: It's also worth noting that reputation management is not the same as politics. People who do it well are seen as helpful and competent, not scheming. Lucas: Totally. The distinction is intent. If you're sharing a postmortem to help others avoid the same mistake, that's generosity. If you're doing it to showcase your own brilliance, people can tell. And in engineering orgs, authenticity is surprisingly hard to fake. Luna: It's like that saying — your reputation is what people say about you when you're not in the room. You want that conversation to be accurate and favorable. Lucas: You know, this kind of conversation is exactly why we keep these episodes ad-free and focused on actionable advice. A couple of dollars a month from listeners is genuinely what keeps it going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, it's a small thing that makes a real difference in keeping the show independent and useful. Lucas: Okay, back to reputation. The last thing I'll say is that reputation compounds. The earlier you start being intentional about it, the more career capital you build. Every cross-team collaboration, every helpful code review, every clear doc — it all adds up. Luna: So if someone is listening right now and wants to take one action this week, what should it be? Lucas: Write that quarterly narrative for your current project. Even if you never send it, just the act of writing it will clarify your own story. Then share it with one person you trust. That's the first step. Luna: And the second step? Lucas: Pick one person on a different team whose work you respect, and offer to review their next design doc. That's the advocacy pillar in action. Do that consistently for six months and your reputation will shift dramatically. Luna: Alright, I think we've given people a clear playbook. Thanks Lucas. Lucas: Thanks Luna. See you next time.