Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Prepare for Promotion Packets
Transcript
- Lucas: You spend a year shipping projects, hitting every deadline, maybe even mentoring a junior engineer. Your manager says you are doing great. Then promotion cycle comes around — and you do not get it. If that has ever happened to you, the problem might not be your work. It might be your promotion packet. Luna: The promotion packet. That is one of those things nobody really explains until you are in the middle of it. What exactly is it? Lucas: It is a written document — sometimes ten to fifteen pages — that your manager submits to a promotions committee. It makes the case for why you should move from, say, L4 to L5 at Google, or from E4 to E5 at Meta. The committee does not see your code. They do not sit in on your meetings. All they see is this packet. So if the packet is weak, your promotion is dead. Luna: That is a lot of pressure on a document. But who actually writes it? The manager or the engineer? Lucas: Ideally it is a collaboration. The engineer drafts a self-assessment — a detailed summary of their projects, impact metrics, and leadership examples. Then the manager takes that, layers in their own perspective, and writes the final packet. But here is the thing: at Meta specifically, the manager owns the packet. If your manager is stretched thin or just not great at writing, your packet might be generic. And a generic packet gets rejected. Luna: So you cannot just assume your manager will handle it. You have to help them help you. What does a good packet actually look like? Lucas: A strong packet starts with a crisp summary of your top two or three achievements for the cycle. Each achievement needs three things: the problem, your specific contribution, and the measurable impact. For example, not just 'I improved the search latency.' It should be 'I redesigned the caching layer for the search backend, reducing p99 latency by 40 percent, which saved two million dollars in compute costs annually.' Numbers. Specifics. That is what the committee wants. Luna: And the contribution part is key. Because if you were on a team of ten, the committee will wonder what you personally did, right? Lucas: Exactly. The worst thing you can do is write 'we' everywhere. 'We shipped the new recommendation engine.' The committee does not promote teams. They promote individuals. The packet needs to make it crystal clear where you led, where you unblocked the team, where you went beyond your assigned tasks. At Google, they call this the 'role and scope' section. At Meta, it is about demonstrating impact that is clearly at the next level. Luna: So the bar is not just doing your job well. It is proving you are already operating at the next level. Which makes sense, but it also means you have to start building your case months before the cycle begins. Lucas: Right. And that is where most engineers slip up. They treat promotion as something you apply for when the cycle opens. But the smartest engineers I have seen start preparing at the beginning of the half or the quarter. They keep a running doc of their wins, with metrics. They ask their manager for feedback on whether a project is visible enough. They volunteer for high-impact cross-team work. Because by the time the cycle starts, it is too late to go find impact. Luna: That reminds me of something I read about Meta's promotion process. They have these mid-cycle check-ins where your manager basically gives you a signal on whether you are on track. If you get a yellow or red signal, you still have time to course-correct. Lucas: Yeah, Meta calls them 'promotion checkpoint conversations' and they are incredibly useful. Google has something similar with the 'Promo Check' mid-cycle. But even with those signals, a lot of engineers ignore them. They think 'I will just work harder and it will be fine.' But the issue is often not effort — it is visibility and narrative. The packet is a story about your impact. If the story is not compelling, working harder on the wrong things will not help. Luna: So let us talk about the narrative. What are some common mistakes that make a packet weak? Lucas: One huge mistake: listing responsibilities instead of achievements. 'I was responsible for the payments API.' That tells the committee nothing. What did you change? What happened because of you? Another mistake: giving too much technical detail. The committee members might not be in your area. They are looking for business impact and leadership, not a deep dive into your algorithm. And the third mistake — this one is subtle — is not addressing potential weaknesses head-on. If you had a quarter where your project was delayed, do not hide it. Explain it. Show what you learned and how you recovered. Committees appreciate honesty and growth. Luna: That is interesting. So a packet should actually acknowledge a setback, because it shows resilience. But how do you balance that with the need to present a strong case? Lucas: You frame it as a learning moment that led to a better outcome. For example: 'In Q2, our initial approach to the data pipeline was too fragile. I led a root-cause analysis and proposed a redesign that reduced failure rates by 80 percent in Q3.' That turns a negative into a demonstration of leadership. Committees love that. Luna: Okay, so the packet is partly about storytelling. But it also depends on your manager's advocacy, right? What if your manager is new, or just not invested? Lucas: That is a real problem. If your manager has never written a packet before, or if they are overwhelmed, your packet might suffer. One thing you can do is find a mentor or a skip-level manager who has served on a promotions committee. They can review your draft and give feedback. Some companies even have 'promotion buddies' — engineers who have gone through the process and can coach you. At Amazon, I have seen people form informal promotion prep groups where they share drafts and critique each other. Luna: That is smart. Because the committee itself is made up of engineers and managers from other teams. So getting feedback from people who think like committee members is invaluable. Lucas: Exactly. And here is another thing: the committee reads your packet cold. They do not know you. So every claim needs to be backed by data or by peer quotes. Some companies allow you to include peer feedback directly in the packet. If you can get two or three senior engineers to write a short paragraph about your impact, that goes a long way. Luna: So part of preparing for a promotion is also cultivating those relationships early. Asking for feedback, building a reputation across teams. That is not something you can do in a week. Lucas: No, and that is the harsh truth. A lot of engineers wait until three weeks before the cycle to start thinking about promotion. By then, it is too late to build a network or create new impact. The ones who get promoted consistently are the ones who treat promotion prep as a year-round activity. They are intentional about their projects. They talk to their manager about what the next level looks like, every month, not just at review time. Luna: That is the kind of advice that actually changes how you work. And it makes me think — a lot of the resources on this topic are behind paywalls or internal company wikis. It is hard to find a clear, public explanation of how these packets work. We try to keep the show ad-free so people have access to this kind of practical information without paywalls. If today's conversation gave you something usable, and you want to support that approach, the link is buy me a coffee dot com slash fexingo. Just a small way to keep these episodes coming. Lucas: Yeah, it matters. We hear from listeners who say these episodes helped them navigate their career in ways they could not elsewhere. So thank you to anyone who chips in. Luna: Alright, so back to the packet. Let us talk about what happens after your manager submits it. What is the timeline? Lucas: Once submitted, the packet goes to a promotions committee — usually three to five senior engineers or managers. They read it independently, then meet to discuss and vote. At Google, this committee is called the Promotion Committee. At Meta, it is the Promo Committee. You typically do not get to present or answer questions. The committee's decision is final, though you can appeal if there is a procedural error. Luna: No presentation? So the packet really has to stand on its own. That is wild. Lucas: It is. And that is why clarity is everything. If a committee member reads a sentence and has to wonder 'what exactly did this person do?' — that is a failure. Every sentence should be unambiguous. Use active voice. Be specific. Avoid jargon that only your team understands. Write for a general technical audience. Luna: So if someone is listening right now and thinking 'I might be up for promotion in six months,' what is the one thing they should do today? Lucas: Start a promotion document. Right now. Open a Google Doc or a Notion page. Write down the projects you are working on this quarter. For each, note the problem, your role, and the metrics you plan to move. Then every week, add a sentence about progress. By the time the cycle comes, you will have a rich draft ready. And it will be easy to see where you need to fill gaps — like if you have no cross-team collaboration example, you can go find one. Luna: That is really concrete. And it takes the panic out of the process. I think a lot of engineers assume promotion is mysterious or political, but at least at FAANG, it is actually pretty structured. The structure just demands preparation. Lucas: Exactly. And the more you understand the packet, the more you realize that promotion at these companies is not about politics. It is about evidence. And you control most of that evidence. So take control of it. Luna: Good place to leave it. For anyone who wants to dig deeper, we will put a link to a sample packet outline in the show notes. Lucas: Thanks for listening. See you next time.