Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Side Projects to Get Promoted
Transcript
- Lucas: So there's this assumption I keep hearing from engineers, especially early in their careers, that side projects are for your resume. You build a cool app over a weekend, you put it on GitHub, maybe it gets some stars, and you hope a recruiter notices. And that can work for getting an interview — sure. Luna: Right, it's like a signal of genuine interest. But you're saying there's a much more strategic use for side projects once you're already inside a faang level company. Lucas: Exactly. Once you're in, side projects shift from being a signal to a lever. I'm talking about projects that exist outside your immediate team's roadmap but that you can build, deploy, and get adopted by other teams inside the same company. And those are what actually move the needle on promotion. Luna: Give me a concrete example. I've heard the theory before, but I want to see the mechanics. Lucas: Sure. I talked to a Meta engineer — let's call her Priya — who was a level-five on the ads infrastructure team. She noticed that every time her team ran an A/B test on a new ad delivery model, they'd have to pull data from four different internal dashboards manually. There was no unified view. Her manager told her, 'That's not a priority this half, we're shipping the new relevance model.' Luna: Classic. So the official roadmap says no, but the pain point is real. Lucas: Right. So on her own time — she estimated about six hours a week for six weeks — she built a lightweight internal dashboard that aggregated those four data sources into one view. She didn't ask for permission. She just built it, showed it to two teammates, and they started using it. Luna: And then what happened? Did she get pushback? Lucas: Initially, no. Her manager was actually happy because her team's productivity on analyses went up maybe thirty percent. But the real move came when she presented it at an internal engineering all-hands. Two other ads teams asked for access. Within three months, three teams were using it daily. She had internal adoption metrics — number of queries, number of unique users, time saved per engineer. Luna: So she had numbers to put in her promotion packet. That's the key, right? It's not just that she built something — she could quantify its impact. Lucas: Exactly. And quantification is the whole game at FAANG promotion committees. They don't care about creativity. They care about scope, impact, and metrics. Her dashboard saved roughly two hundred engineer-hours per quarter across those three teams. That's a level-six impact number. She got promoted to level six the next cycle. Luna: I love that she didn't wait for permission. That's the part that scares people — they think a side project has to be greenlit by management. Lucas: And look, I'm not saying you should go rogue and build something that conflicts with your team's priorities. But if you see a gap that's clearly not being filled, and it's orthogonal to the roadmap — meaning it doesn't compete for resources — most managers will be fine with you spending some off-hours on it. Especially if they see you're doing it to increase your team's efficiency. Luna: What's the flip side? I've definitely seen engineers build something cool but totally outside the company's tech stack — like a React Native app for a company that's all-in on SwiftUI. That's just not going to get adopted. Lucas: That's the classic mistake. Priya built her dashboard using the exact same front-end framework and internal API patterns her company already used. She didn't introduce any new technology. She just combined existing pieces in a novel way. Adoption friction was near zero because any engineer could look at the code and understand it immediately. Luna: So the rule is: use the company's own tools, even if they're not the sexiest. Don't try to bring in a new database or a new language. Lucas: Exactly. Internal tooling is often ugly and clunky, but it's what people know. If your side project runs on the same internal platform, it can be deployed with one click. If it requires setting up a new service, it's dead on arrival. Luna: Another mistake I've seen — people build a side project that solves a problem for their own team, but they don't document it. So even if it works, nobody else can adopt it because there's no onboarding guide. Lucas: Big one. Priya wrote a one-page internal wiki entry that covered the setup, a few screenshots, and a Slack channel for questions. That's it. She didn't write a full design doc. She just made it easy for someone to try. And when they tried, they stayed. Luna: How does this compare to, say, Google's promotion process? Because I know at Google, side projects that aren't tied to your team's goals can actually hurt you if they distract from your core work. Lucas: That's a real concern. Google's promotion packets are judged against your role's expectations. If your side project consumes time that should have gone to your core deliverables, your manager will call that out. But if you can show that your core work stayed strong — which Priya did, because she built the dashboard outside work hours — then side projects are viewed as evidence of 'beyond scope' impact, which is exactly what gets you promoted. Luna: So it's about time management and expectation setting with your manager. Did Priya tell her manager she was building this? Lucas: She mentioned it informally after she had a prototype. She said, 'Hey, I threw together a little dashboard that pulls in the four data sources. Want to see?' That's different from asking, 'Can I spend twenty percent time on this?' She framed it as a small experiment. By the time her manager saw the value, it was already working. Luna: That's smart framing. It's easier to apologize than to ask permission, but in this case she didn't even need to apologize. She just showed value. Lucas: Yeah. And the other thing she did right — she made sure the dashboard was used by at least one person on each of the three teams before she even mentioned promotion. She had organic users. That's way more credible than saying 'I think this could be useful.' Luna: You know, this kind of thing is exactly why I love doing this show. We get to dig into real strategies that actually work. And speaking of things that work — we keep this podcast ad-free, and that's entirely because of listeners who support us with a couple of dollars a month at buy me a coffee dot com slash fexingo. It genuinely makes a difference — it covers hosting, transcription, and keeps us independent. If you've gotten anything useful out of these episodes, that's the place to chip in. Lucas: Yeah, it really does. We don't run ads, we don't have sponsors. It's just listener support. And we're grateful for every coffee. Anyway — back to side projects. Another angle I want to cover is the mistake of building something that solves a problem only you have. That's not a side project, that's a personal script. Luna: Right. You need to validate that at least a handful of other engineers feel the same pain. Otherwise it's not a promotion-worthy project. Lucas: Exactly. Priya validated by talking to two teammates before she built anything. She asked, 'Would it save you time if you could see all four data sources in one place?' They both said yes. That's market validation, internal style. Luna: So the takeaway is: find a pain point that's shared, build a solution using the company's own stack, document it minimally, get a few users, and then measure the impact. That's the formula. Lucas: That's the formula. And it works at any FAANG — Meta, Google, Apple, Amazon, Netflix. The specifics of the promotion process differ a bit, but the core requirement is the same: you need to show impact beyond your immediate team, and side projects that get adopted across teams are one of the most reliable ways to demonstrate that. Luna: One more thing — how do you protect yourself from your side project becoming 'just your job'? I've seen managers who, once they see the value, try to absorb it into the official roadmap and then you're just doing it for your regular salary. Lucas: That's a real risk. Priya handled it by not handing over ownership until after her promotion was approved. She kept the project under her own GitHub account inside the company, not a team repo. She maintained it personally. Once she got promoted, she handed it off to a junior engineer as a growth opportunity. That way, she got the credit, and the project continued. Luna: Smart. So you keep control until you've extracted the career value. Lucas: Exactly. And if your manager tries to take it over before you're promoted, you can say, 'I'm happy to help transition after the next review cycle.' Most managers will respect that because they know you're being strategic. Luna: Alright, so for anyone listening who's at a FAANG or a big tech company and thinking about their next promotion — what's the one action item from this episode? Lucas: Identify one pain point in your organization that affects at least two other teams, that you can solve using existing internal tools, and that you can build in under a month of off-hours work. Talk to two potential users. If they say yes, build a minimal version. Then measure adoption. That's your promotion lever. Luna: And if you've already got a side project that's gathering dust, consider whether it meets those criteria. If not, it might be time to pivot. Lucas: Great point. The hardest part is starting. But once you see that first team adopt something you built, it changes how you think about your own career agency. Luna: Thanks for listening to The Tech Career Podcast with Fexingo. We'll be back with another episode soon.