Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Navigate Reorgs Without Derailing Their Career
Transcript
- Lucas: So you're a senior engineer at a FAANG company, you've got a solid project, your manager is happy, your promo doc is lining up nicely — and then one Tuesday morning, there's a calendar invite from someone in HR with the subject line 'Org Update.' Luna: That invite changes everything. Your manager might change, your project might get killed, your entire career trajectory can get scrambled in one thirty-minute meeting. Lucas: Exactly. Reorgs are one of the most destabilising events in big tech, and they happen constantly. At Meta, for example, there were at least two major reorganisations in the second half of 2025 alone — one in the ads business and one in the metaverse division. Google restructured its Assistant and Devices teams last year. Amazon does them so frequently they've practically normalised it. Luna: And the irony is, most engineers treat a reorg like a natural disaster — something to endure — when actually there's a pretty clear playbook for coming out ahead. Lucas: Right. So today we're going to walk through that playbook, and I want to anchor on a specific case. A staff engineer at Meta — let's call her Priya — went through three distinct reorganisations over eighteen months. The first one derailed her promo. The second one she handled okay. The third one she navigated so well that she actually accelerated her timeline to senior staff. Luna: Wait — three reorgs in eighteen months? That sounds brutal even by Meta standards. Lucas: It is brutal. But Priya's story shows that the difference between a reorg setting you back versus pushing you forward often comes down to three things: how you read the signs beforehand, how you position yourself in the first week after, and how you manage your relationships through the transition. Luna: Let's start with reading the signs. What were the early indicators Priya noticed? Lucas: The first reorg caught her completely off guard. She was heads-down shipping a new feature for the ads platform, and she didn't see it coming. After that, she learned to watch three signals. First, when your skip-level manager starts having one-on-ones with people on your team, that's a classic pre-reorg diagnostic. Second, when funding for your project gets pushed to 'pending review' — especially in the middle of a quarter — that's a big yellow flag. And third, when the org chart starts showing new dotted-line reporting structures that no one can explain. Luna: So basically, pay attention to things that seem off, even if they don't directly affect you yet. What did she do differently the second time? Lucas: The second reorg, she saw it coming about three weeks before the announcement. She had two concrete moves. One: she updated her internal project portfolio — what we sometimes call a 'brag doc' — with explicit metrics about the impact she'd already delivered. Two: she scheduled coffee chats with three senior engineers in adjacent teams who she knew were stable. Not to ask for a job — just to stay visible. Luna: That visibility piece is huge. When the reorg actually happens, managers are scrambling to figure out who goes where. If you're already a known quantity to someone on the other side, you're much more likely to land in a good spot. Lucas: Exactly. And that's where Priya's second reorg went okay but not great. She landed in a decent team, but the project she was on got deprioritised three months later. So she learned another lesson: don't just find any stable team — find a team that's tied to a core business priority. At Meta, that means anything related to AI infrastructure or monetisation. At Google, it's Search and Cloud. At Amazon, it's AWS and logistics. Luna: So the third reorg, she was ready. Walk us through that. Lucas: The third reorg happened in early 2026 — it was a consolidation of two engineering groups under a single VP. Priya saw the signs: funding pauses, a new org chart floating around in a shared doc that she happened to see. She had about a month lead time. This time, she did something different. She didn't just update her brag doc — she wrote a one-page summary of her top three projects, the business impact of each, and which teams she thought her skills were most relevant to. Luna: She essentially wrote her own job description for the reorg. Lucas: Exactly. And she shared it with her current manager and her skip-level. Not as a demand — as a 'hey, I want to make sure I'm aligned with where the org is going.' That made her look proactive and strategic rather than defensive. When the reorg hit, her manager already had that document in hand and made sure she was assigned to a team working on Meta's ai driven ad optimisation — which was the highest-priority initiative in that group. Luna: So being early and being clear about your value prop — that's the key. But what about people who aren't in that position? What if you're a mid-level engineer who doesn't have a strong relationship with skip-levels? Lucas: That's a fair point, and it's actually where most engineers get stuck. The advice 'network with senior leaders' is great if you're already comfortable doing that. But if you're not, the simplest thing is to focus on your immediate manager. Have a direct conversation: 'If the org changes, I want to make sure I'm working on something that plays to my strengths. Here's what I've done and here's what I enjoy.' Most managers will advocate for you if you make it easy for them. Luna: And what about after the reorg is announced? That first week is chaotic. Lucas: That first week is the most dangerous time to make decisions. Priya's rule was: don't volunteer for anything in the first five days. You don't know the full landscape yet. You might see an interesting project and jump on it, only to find out it's been a dead-end for years. Instead, she spent the first week just listening — reading the new org chart, understanding who reported to whom, and identifying the key decision-makers. Luna: That's counterintuitive because there's this pressure to 'claim your spot' fast. Lucas: Exactly. But the people who move fastest are often the ones who end up in the worst positions. The smarter play is to wait until the dust settles and then have targeted conversations. Priya waited two weeks before she even asked about project assignments. By then, she had a clear picture of which teams had strong leadership, which projects had clear metrics, and which ones were likely to get cut in the next quarter. Luna: And what about the emotional side? Reorgs are stressful. People worry about their job, their relationships, their promo timeline. Lucas: Totally. And the emotional toll is real. Priya said her first reorg caused her to lose about two months of productive work — she was anxious, distracted, second-guessing everything. By the third reorg, she had built a kind of emotional buffer. She reminded herself that reorgs are a feature of big tech, not a bug. They happen, they're rarely personal, and your best defence is to stay focused on what you can control — your output, your relationships, and your clarity about what you want. Luna: One thing I've heard from engineers is that reorgs can actually be a great time to reset if you've been stuck. If your project was going nowhere, a reorg might give you an excuse to pivot to something better. Lucas: That's a really important reframe. Priya's third reorg was actually a blessing in disguise. Her previous project was fine, but not high-visibility. The AI ad optimisation team she landed on ended up being her fastest path to senior staff because the project had executive visibility and clear business impact. So if you're in a reorg, don't just think about what you're losing — ask yourself what you might gain access to. Luna: Let's talk about the concrete tactics for that first month. What should an engineer actually do in the first 30 days after a reorg lands? Lucas: Three things. First, schedule one-on-ones with your new manager within the first week. Come with a one-page summary of your recent projects and your strengths. Don't complain about the old org. Be positive and forward-looking. Second, identify the key stakeholders for whatever project you end up on — who's your product manager, who's the tech lead, who are the dependent teams. Build relationships with them quickly. Third, set a 90-day goal with your new manager. Something concrete that delivers value quickly — a bug fix, a documentation improvement, a small feature — so you establish credibility fast. Luna: That third point is crucial. In a new org, people don't know you yet. A quick win builds trust. Lucas: Exactly. And it doesn't have to be a huge win. Priya's quick win in her new team was cleaning up a flaky test suite that had been causing false alarms for weeks. It wasn't glamorous, but it made the team's CI pipeline more reliable, and people noticed. That gave her social capital to then advocate for bigger technical decisions later. Luna: And what about the promo timeline? If you're six months away from a promo and a reorg hits, do you basically have to start over? Lucas: Not necessarily, but you do have to be smart. The key is to make sure your new manager and your new skip-level understand the work you've already done. Priya carried her promo packet from the old org into the new one. She made sure her new manager read it. She also got her old manager to write a brief endorsement that she shared. That continuity is critical. If you just assume people will know your worth, you'll be disappointed. Luna: So you have to actively manage your narrative across the reorg. Don't let your previous work get lost in the noise. Lucas: Right. And there's one more thing that Priya did that I think is worth highlighting. She kept a 'reorg journal' — just a private doc where she tracked what she learned each time. After the first reorg, she wrote down what she wished she'd done differently. After the second, she noted what worked. After the third, she had a full playbook. She said that journal was the single most valuable career document she's ever created. Luna: That's a great habit. Most of us just move on and forget, and then we repeat the same mistakes. Lucas: Exactly. And if today's conversation gave you something usable — a tactic, a reframe, a specific thing to try — the way we keep this show ad-free and focused on practical advice is through listener support. You can find us at buy me a coffee dot com slash fexingo. Luna: Yeah, it's a small gesture that makes a big difference in keeping these episodes coming. So if you got value from Priya's story, consider it. Lucas: Alright, back to the playbook. One last thing I want to mention: reorgs are actually an incredible opportunity to expand your network. When teams dissolve, people scatter to different parts of the company. Priya made a point of staying in touch with at least five people from each of her previous teams. Those relationships paid off later — she got early signals about future reorgs, she got referrals for transfer opportunities, and she got honest feedback about which teams were healthy and which were toxic. Luna: So the takeaway is: don't treat a reorg as something that happens to you. Treat it as a strategic moment where you have more agency than you think. Lucas: Exactly. And if you can combine that mindset with a few concrete moves — reading the signs, positioning yourself early, managing your narrative, and building network continuity — you can actually come out of a reorg stronger than you went in. Priya's case proves it. And the best part is, you don't have to be a staff engineer to do it. Any engineer can use this playbook. Luna: Next episode, we're going to talk about something that comes up a lot in the comments: how to handle a manager who isn't advocating for you during performance review season. That's a different kind of challenge, but it overlaps with what we talked about today. Lucas: It does. And we'll have a specific case study on that too. Thanks for listening, and we'll see you next time.