Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Performance Metrics to Drive Promotions
Transcript
- Lucas: Luna, you know how every FAANG engineer I talk to says the same thing about promotions? They work hard, ship big features, get great peer reviews — and then the promo packet gets kicked back. Luna: Right. The feedback is always something vague like 'not enough impact' or 'needs more scope.' It's frustrating because they don't know what they're missing. Lucas: Exactly. And the thing is, most engineers focus on the wrong kind of evidence. They lead with code shipped or bugs fixed — raw output. But promotion committees at FAANG are looking for something different: metrics that tell a story about business impact, leadership, and operational efficiency. Luna: So what does a good metrics-driven promo packet actually look like? Like, can you give me a concrete example? Lucas: Let me tell you about a senior engineer at Amazon — let's call him Raj — who made the jump from L5 to L6 in 18 months. That's fast for Amazon. His secret wasn't just working more hours. He systematically tracked three categories of metrics: latency reduction, team scalability, and cross-team leverage. Luna: Latency reduction is a classic one. How did he frame it? Lucas: He owned a microservice that handled recommendation requests. Over six months, he reduced p99 latency from 320 milliseconds to 180 milliseconds. But he didn't just say 'I optimized code.' He showed that this reduction directly improved customer click-through rates by 3.2 percent — which he tied back to an estimated $4 million annual revenue impact. That's the kind of metric a promo committee can't ignore. Luna: Wow. So he connected a technical metric to a business outcome. That's the whole game. Lucas: Right. And for the second category — team scalability — he built a set of automated regression tests that cut manual testing time by 40 hours per quarter. That opened up capacity for his teammates to work on higher-value features. He framed it as 'enabling the team to ship 20 percent more features per quarter.' Luna: So he's showing that he made everyone around him more productive. That's the classic 'scope' lever. Lucas: Exactly. The third category was cross-team leverage. He created a shared library that three other teams adopted, reducing duplicated effort. He tracked usage: the library was imported in 12 repos and saved an estimated 100 engineering hours per month across teams. And he got written endorsements from the tech leads of those teams. Luna: That's smart — because a promo committee hears your manager's voice, but when another team's lead says 'Raj's library saved us two weeks of work,' that's independent validation. Lucas: If today's deep dive into promotion metrics is giving you a clearer picture of how to build your own case, you might be wondering where to go next. Honestly, episodes like this stay ad-free because of listener support — people who find them genuinely useful and want to keep that resource available. If that's you, you can help by visiting buy me a coffee dot com slash fexingo. No pressure, just a way to keep the conversation going. Luna: Yeah, and it really does make a difference. Every contribution helps us keep bringing you these specific, actionable breakdowns without any ad breaks. Lucas: So back to Raj's case — his promo packet didn't just list achievements. It structured them as a narrative around those three metric categories, each tied to a leadership principle. For Amazon, that's Customer Obsession, Deliver Results, and Invent and Simplify. Luna: So he mapped each metric to a principle. That forces the committee to see the connection between his work and Amazon's values. Lucas: Exactly. And here's a counterexample I saw recently. An engineer at Google — let's call her Priya — was trying to make the jump from L4 to L5. She had great metrics: she reduced page load time by 15 percent, which impacted millions of users. But her packet only listed the technical metric. She didn't tie it to user engagement, ad revenue, or any business outcome. The committee asked: 'Fifteen percent... so what?' Luna: Ouch. So the same metric can be powerful or useless depending on how you frame it. Lucas: Right. The lesson is: always add the 'so what.' For every metric, ask yourself: why does this matter to the customer? To the business? To the team's velocity? If you can't answer that in one sentence, you need to dig deeper. Luna: What about metrics that are more qualitative? Like mentorship or code review quality — those are harder to quantify. Lucas: Great question. For mentorship, the best approach is to track outcomes, not activities. Don't say 'I mentored three junior engineers.' Say: 'I mentored three junior engineers; two were promoted one level within 12 months, and one of them received the 'Rising Star' award in their org.' Then back it up with quotes from their performance reviews. Luna: So you're proving your impact through the success of others. That's powerful because it shows leadership scope. Lucas: Exactly. And for code review, the typical mistake is to count the number of reviews done. Instead, track the number of bugs caught in code review that would have gone to production — and the estimated cost savings. Or show that your reviews reduced the average time to merge for your team by X percent. Luna: So it's always about converting activity into measurable impact. That makes sense, but it also requires discipline to track these things week after week. Most engineers don't think about promotion evidence until review time. Lucas: That's a huge mistake. The engineers who get promoted fastest keep a 'brag doc' — a running list of achievements, metrics, and endorsements updated every two weeks. When promo packet season comes, they don't scramble. They just curate. Luna: A brag doc — I've heard that term before. What should go in it besides metrics? Lucas: Include specific numbers, links to design docs, quotes from peer reviews, and any recognition — like a 'spot bonus' or a shout-out in a team meeting. Also note the context: was this a high-pressure project? Did you unblock a critical path? The committee doesn't know the backstory unless you tell it. Luna: So it's not just about the metric, but the narrative around it. The 'how' matters as much as the 'what.' Lucas: Exactly. And one more thing: don't ignore operational metrics. A lot of engineers think they need to build something new to get promoted. But improving system reliability, reducing on-call burden, or cutting deployment failure rates can be just as impactful — if you quantify the savings. Luna: Give me an example of an operational metric that worked. Lucas: A DevOps engineer I know at Microsoft reduced the number of Sev-2 incidents from 12 per quarter to 3 by implementing a monitoring dashboard and automated rollback scripts. He calculated that this saved the team 200 hours of on-call time per quarter — which he translated into $50,000 in engineering cost savings. That became the centerpiece of his promo packet for senior DevOps engineer. Luna: That's brilliant. He turned a boring ops improvement into a clear dollar figure. Committees love money. Lucas: They do. And the key is to be honest and conservative with your estimates. If you inflate a number and someone questions it, you lose credibility fast. Luna: So what's a common mistake engineers make when presenting metrics in their promo packet? Lucas: The biggest one is comparing apples to oranges. For instance, saying 'I reduced deployment time by 30 percent' without giving a baseline. The committee needs to know: from what to what? And over what timeframe? Also, avoid vanity metrics like 'number of lines of code written' — that's almost never a positive signal. Luna: Right, because more code isn't always better. Sometimes it's tech debt. Lucas: Exactly. A better metric would be 'reduced code complexity score for the module by 15 percent as measured by Cyclomatic Complexity metrics.' That shows you're improving maintainability. Luna: I love that. It's specific, measurable, and shows engineering judgment. Lucas: So to wrap up: if you're aiming for a FAANG promotion in 2026, start your brag doc today. Pick three metric categories — technical performance, team scalability, and cross-team leverage — and track them weekly. For each metric, ask yourself the 'so what' question and tie it to a business outcome or leadership principle. That's how you build a promo packet that tells a story, not just a list. Luna: And if you want to keep getting episodes like this that give you that concrete, actionable edge, you know where to find us. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.