YouTube Deep SummaryYouTube Deep Summary

Star Extract content that makes a tangible impact on your life

Video thumbnail

26 Year Old Meta Staff Eng (IC6) On Promotions, Redefining Expectations, Secret Equity Bonuses

Ryan Peterman • 77:29 minutes • Published 2025-07-04 • YouTube

📚 Chapter Summaries (12)

🤖 AI-Generated Summary:

From New Grad to Staff Engineer in 3 Years: The Meta Success Story

How Simon achieved the highest performance ratings and built a rocket ship career through ownership, curiosity, and exceptional mentorship


The Remarkable Journey

Simon's career trajectory at Meta reads like a Silicon Valley fairy tale. Starting as a new graduate (IC3), he reached Staff Engineer (IC6) in just three years—a feat that typically takes 5-7 years. Along the way, he earned two "Redefines Expectations" (RE) ratings, Meta's highest and rarest performance rating that most engineers never achieve even once in their entire careers.

But this isn't just a story about promotions and ratings. It's about the strategic decisions, mindset shifts, and key relationships that accelerate career growth in big tech.

The Foundation: Early Momentum Matters

Strategic Preparation Before Day One

Simon's success began before he even started full-time. As a former Meta intern, he had already learned the internal tools—a crucial advantage that saved him "4-8 weeks of ramp-up time." But more importantly, he spent time before joining learning technologies like React and exploring different programming patterns.

Key Insight: "We're pattern matching machines. The more patterns we've seen, the easier it is to apply them." Even if you haven't used Meta's internal JavaScript type checker Flow, having TypeScript experience makes the transition seamless.

The Power of the Right Manager

Perhaps the most critical factor in Simon's success was his manager, Bala. When Simon expressed his ambitious goal of reaching IC5 in three years, Bala didn't dismiss it—he drew up a plan on the whiteboard. This manager had made a similar journey himself and knew it was possible.

Bala's impact extended far beyond technical guidance:
- Deep technical mentorship (he was a recently converted IC6 to manager)
- Product strategy and roadmap setting
- Communication coaching
- Experiment design and execution

The relationship lasted 5.5 years—an eternity at a company known for frequent reorganizations.

The Secret to "Redefines Expectations" Ratings

First RE Rating: The Power of Impact

Simon's first RE rating came from driving projects that exceeded the team's half-year revenue goal by multiple times. But it wasn't just about the numbers—it was about the behaviors:

  1. End-to-end ownership: When experiments showed neutral results, Simon didn't stop there. He dug deep with data scientists to understand why, iterated on targeting, and worked with designers to improve the experience.

  2. Technical breadth: He reviewed code across Android, iOS, JavaScript, and PHP—helping uplevel both the codebase and his colleagues through thoughtful code reviews.

  3. People development: He took responsibility for recruiting and onboarding new team members, growing the team from 2 to 8 people.

Second RE Rating: Scaling Through Others

The second RE rating demonstrated a crucial transition from individual contributor to force multiplier. Simon began leading "pods" of engineers, taking responsibility not just for his own output but for project success and team member growth.

The key behavioral shift: Moving from "I hope this person gets it done" to "I am responsible for the outcome, regardless of who executes it."

The Promotion Progression: Behavioral Evolution

IC3 to IC4 (6 months): Task Completion to Project Ownership

  • Before: Complete assigned tasks
  • After: Drive projects to completion and identify follow-up opportunities
  • Key behavior: Taking ownership of project outcomes, not just individual deliverables

IC4 to IC5 (3 halves): Individual Impact to Team Leadership

  • Before: Responsible for your own success
  • After: Responsible for others' success and project outcomes
  • Key behavior: Leading pods of engineers, mentoring, and ensuring team success

IC5 to IC6 (2 halves): Team Leadership to Organizational Impact

  • Before: Managing people and projects directly
  • After: Scaling yourself through systems and delegation
  • Key behavior: Creating processes that catch problems early, delegating effectively while maintaining accountability

The Management Detour: Lessons Learned

Despite his IC success, Simon tried management for nearly a year. The transition was challenging for several reasons:

  1. Identity crisis: "Will I just become a middle manager who's lost all technical abilities?"
  2. Bad timing: His mentor manager had an accident, his skip-level was on leave, and he had to relocate from London
  3. Over-promising: Trying to get two people promoted from IC5 to IC6 simultaneously on the same team
  4. Technical attachment: Struggling to let go of hands-on technical work

When his director asked, "Simon, do you want to go back to IC?" his gut response was immediate: "Yes, yes I do."

The realization: As an IC6 who enjoys mentoring, he could pick and choose coaching opportunities as a "bonus" rather than having it be his primary evaluation criteria. This provided more flexibility and aligned better with his interests.

The Communication Multiplier

One of Simon's manager's key teachings was that many people are held back not by their technical abilities, but by their inability to communicate their impact effectively.

The 5-Second Rule for Written Communication

Simon's framework for effective workplace communication:
- Assume 5-10 seconds of attention: Make it incredibly parseable at a glance
- Lead with TL;DR: Include numbers and concrete outcomes
- Structure for different audiences: High-level impact for leadership, technical details for fellow engineers
- Stay above the fold: Critical information should be visible without expanding the post

The Meta Internal Forum Strategy

At Meta, a single workplace post can reach thousands of people. Simon learned to write updates that clearly communicated:
1. What was accomplished (with numbers)
2. Why it mattered to the business
3. What the next steps were
4. Technical details for those who wanted to go deeper

The Hidden Rewards: Discretionary Equity

High performers at Meta can receive "Additional Equity" (AE)—discretionary stock grants that only directors can approve. Simon received this twice:

  1. First AE: After his IC5 to IC6 promotion, likely to address equity compensation gaps from starting as a new grad
  2. Second AE: After successfully shipping a company priority product ahead of schedule while transitioning to management

These grants can significantly impact total compensation beyond standard promotion cycles.

The Intern Success Formula

Having managed interns and served as an intern director, Simon identified the key differentiators:

What Makes Great Interns

  1. Velocity above all: The primary measure is project completion
  2. Ask questions early: Use the first few weeks when expectations are zero
  3. 30-minute rule: If stuck for more than 30 minutes, ask for help
  4. Leverage peer network: Don't rely solely on your manager for support
  5. Build relationships: Peer feedback is crucial for final evaluations

The Sustainable Pace

Simon averaged about 50 hours per week during his growth phase, but emphasized that sustainability comes from interest and passion. When he lost enthusiasm for his work, the same hours felt like a grind, prompting his team switch.

Universal Principles for Career Growth

The Ownership Mindset

"Nothing at Meta is someone else's problem." When blocked, don't wait—read the code, understand the decisions, propose solutions. This curiosity-driven ownership was Simon's primary growth driver.

The Technical vs. Non-Technical Balance

Simon estimates you can reach IC5 with just baseline technical skills if you excel at:
- Cross-functional collaboration
- Communication and influence
- People development
- Project management
- Strategic thinking

Technical brilliance can be a differentiator, but soft skills are often the limiting factor for rapid career growth.

The Meta Advantage

What kept Simon at Meta for his entire career:
- People: Empathetic, technically excellent colleagues
- Flexibility: Global mobility and internal transfer opportunities
- Growth opportunities: Ability to switch teams when losing motivation
- Scale: Impact potential across billions of users

The Takeaway

Simon's journey from new grad to Staff Engineer in three years wasn't about working 80-hour weeks or having exceptional technical talent. It was about:

  1. Strategic preparation before starting
  2. Finding exceptional mentorship and maintaining that relationship
  3. Taking ownership beyond your immediate responsibilities
  4. Scaling impact through others as you grow
  5. Communicating effectively to amplify your contributions
  6. Being curious and treating problems as puzzles to solve

The most powerful insight? Career acceleration comes from expanding your circle of ownership—from tasks to projects to teams to organizations. Each promotion represents a fundamental shift in how you create value, not just doing more of the same work.

For ambitious engineers early in their careers, Simon's story provides a concrete roadmap: focus on ownership and curiosity, find great mentors, and remember that your technical skills are just the foundation—your impact on others and the organization is what drives exponential career growth.


📝 Transcript Chapters (12 chapters):

📝 Transcript (1984 entries):

## Intro [00:00] If I switch to management now, will I just become a middle manager? Then like I've stopped providing value. This is Simon. He grew from a new grad to a staff engineer at Meta in 3 years, earning the highest ratings twice. And RE stands for redefineses expectations, which there's meets all, there's exceeds, there's greatly exceeding expectations, and then there's redefineses. You didn't just exceed the expectations, you redefined them. He also had some stories to share about the secret bonuses that only the highest performers receive. Additional equity is when a director chooses to give you more RSUs, right? More stock options. Later, he struggled with his transition to management and eventually switched back. I had some really bad luck actually in my manager transition. I remember my director, she asked me like, Simon, you want to go back to IC? And it hit me like, yes, yes I do. The absolute highest rating that almost no one gets that you don't get promoted. Why is that? I actually believe that a lot of people are held back in their career because here's the full episode. Okay, before we get into your promos to staff in 3 years, I kind of want to go over a little bit of the high level like what was the thing you were working on the space? Was it all on one team? Can you tell me about that? My experience at Meta has been pretty unique because I actually stuck with the same team and the same manager for about five and a half years and at a company like Meta there's usually a lot of reorganizations happening and you end up switching either teams or manager as a result and it's true that our team ended up switching a lot in terms of like our responsibilities but we're able to keep all the people and the manager together. So the scope changed scope changed a lot but I can talk through it a little bit because it was always within the payment space ads payments uh specifically improving that experience. It's like a payments growth team. Um so the primary metric we were looking at is just revenue right which was great uh cuz it's very easy to to prove impact there. We were doing a big migration in the ads payment space. So we kind of became a bit more of a ads payments infra uh team for a little bit uh to support the the migration. People across the world use our apps very differently. Uh, for example, in Thailand, a lot of people purchase things on Messenger, right? They they send bank slips back and forth uh to prove that the purchases happened. Um, so that was a big focus for for our team for a while as well. I see. So, this is within monetization, went to like product infrastructure a little bit and then maybe went back to product at some point. That's right. All the same manager direct. Yeah, sounds good. Let's ## Staff promotions in 3 years [02:34] talk about the the promos. So, three promos in 3 years and this was including the promo block with co that we can talk about in a bit. You know, let's be super transparent about all the ratings and everything if you're willing. The first promo from 3 to four that was in 1/2 and that was a GE rating, right? Correct. Yeah. I seeing I mean for that to happen you basically needed to start immediately as an IC4 cuz you need at least 6 months of trailing performance before you can get promoted. How did you start as an IC4 on that team? I do think there are a couple important factors to it, right? One is I was a previous intern at Meta, which meant that I didn't have to go through the ramp up of learning the tools, right? And I often see that that is one of the biggest hurdles as people join a big company like Meta where everything is custom. I'd kind of like already learned how to use Fabricator, the internal task tool, etc. So I probably shaved off at least four to eight weeks of of ramp up. And then the other thing is that I had spent some time before I joined Meta learning so many technologies, right? And I had built a little bit of side projects, right? But it was primarily like exploring, right? Like what is React? Like can I build some basic stuff in it? How does the type system work, right? So that when I arrived at Meta and I started doing the boot camp tasks to you know learn how we actually land uh code at Meta, I was able to move quite quickly and also even help some of the other new joiners um together with me uh which immediately um increased my uh I guess scope and impact right there. Yeah, I think a lot of really eager, ambitious, it's either interns or new hires, they will reach out saying, "What do I need to read before I come here?" What do I need to do? And there's not a lot of great resources out there. I kind of wonder how effective that preparation would even be until they got here and the working on the internal tools. It sounds like for you it actually was pretty effective. How'd you find those those early resources? The resources primarily was just trying to build stuff in React to be honest. Right. And also I spent a lot of time on hackernews um and and Reddit at that point, not so much Reddit at this point actually. Being aware that technologies exist and kind of like knowing what they mean and just the basics of how to use them really makes everything easier. Uh cuz I strongly believe that we're as humans or engineers just like pattern matching machines. The more patterns we've seen in the past, the easier it is to to apply them. So for example, maybe you've never used Meta's internal JavaScript type checker like Flow, right? But maybe use TypeScript, right? They're not onetoone mapping, but they're pretty close. So if you're good with TypeScript, you would do very well with Flow and and vice versa. Just exploring and being aware of different technologies um gets you very far. You kind of ramped up a little bit before you even started at Meta with that with the internship. Was the internship on a different team then? Yes. Okay. So even though it's a different team still all the internal knowledge of the tools and everything applied when you came in you were just immediately able to land code quickly. What was the thing that kind of drove that that GE promo in one half? One thing that really set me up for success is it actually ended up joining um a very new team. Right. So I was the second engineer which did mean that I did get a lot of one-on-one time with our manager. Right. So he helped me a lot throughout that right to ensure that you know I got that early momentum and had impactful projects etc. I would say the the rating um was actually primarily due to my impact right so we were an ads payments team that was focusing primarily on revenue right as our goal I was just a second engineer we didn't have a lot of engineers right and the projects that I worked on right these were the ones that brought in more than three times of our half goal and one important thing to note about promos at Meta is that they're lagging right so you really do need to show that um the behaviors of the next level. One big difference between IC3 and IC4 is taking ownership of kind like the completion of a project rather than like smaller tasks. When I was given a task, I made sure to bring that to conclusion and then figure out what's the next similar thing that we can keep working on, right? So, it was a continuous motion of let's get more impact out of this one thing, right? And then maybe we, you know, got to the the maximum impact that we could have there and then I was pointed towards a new area and I was able to drive that forward. And if something didn't go right and like the results weren't there, then, you know, taking ownership of figuring out why it didn't go well and, you know, obviously I'm new. I'm I'm seeking a lot of assistance from others, but the willingness and the kind of pushing that forward um is the behavior that likely got me to IC4. You mentioned that going to a new team was an asset, but the the other side is there's probably less mentorship available if you're one of two engineers, you're a new grad. Did you seek that out that that team and you know, how'd that play? Where'd you get the mentorship from? How'd you grow in that sense? Yeah. So when I joined Meta, I was planning on going into an infra team, right? So I said I had done some research into React and stuff and I thought that was that was good, but my actual passion was in like C++ infra stuff, which is what I did during my internship. Back in the day, the way that it worked when you joined Meta is that you did went through boot camp and you spoke to many different managers to see which team would you like to join. Um, I set up one meeting with um, Baloa, the manager of the the team I ended up joining. Baloa was the first manager I spoke to and he told me that, you know, Simon, we care about impact at Meta and what's more impactful than revenue. So, I ended up there, right? So, he he kind of like lured me into it. It was more so there was a really good feeling within the team with the manager. We didn't have a PM yet, but she was kind of helping out on the side. Um but because my manager he was uh somewhat recently converted IC6 to manager as well. So he had that deep technical knowledge though. Um so he was the one that actually guided me a lot through that those technical decisions and I think really grew me in other things that are important at Meta such as like running experiments. So my first half at Meta I ran 20 experiments. Um and we were a pretty small or uh within payments and not really like used to run experiments right. So the entire or ran 50 and I ran 20 of those, right? So kind of like I was able to have a high velocity at the start and I think that was a lot thanks to the direct mentorship from my manager. It was very technical. I see. You mentioned that he lured you in with impact as a new grad. Why did you care about impact at the time? Was that for career growth aspect or some other Yeah. So I don't know why I had this goal but when I joined Meta I decided for myself I want to be IC5 within 3 years. So I guess I overachieved there but that was kind of my goal, right? So as I chatted with the different managers, I told him this, right? I was like, "Hey, I would like to get to IC5 in 3 years, right? I know it's ambitious, but like how could you help me?" And Bala, you know, he brought me to the whiteboard when he drew up a plan of like this is what it might look like, right? So I think he actually did that exact same path. Um, similar to uh to me in terms of like how quickly he grew to six. He knew that it was possible to grow this fast and in some ways how to do it. I mean, he delivered and he's a common thread through your experience of your your growth. So, 100% I I credit a lot of my success and growth to to Balo. So, definitely shout out to him. When it comes to IC4 to IC5, this was interesting because this took three halves, but there was the co half which may or may not have blocked a promo. And ## “Redefines” expectations ratings [10:32] you had two RE ratings, which most people would never achieve that rating in their career even once. It's a very rare rating. And RE stands for redefineses expectations, which for reference there's there's meets all which is great. There's exceeds even better. There's greatly exceeding expectations, which is pretty much the upper bound of doing well. And then there's redefineses. I remember when I first heard redefineses. I was think that is the coolest one. You you didn't just exceed the expectations, you redefined them. It was so insane. So yeah, I do want to go into the RE ratings. Um, so the first half you got RE rating as IC4. Not only is that impressive because it's RE rating, but you had just gotten promoted. So it's almost like you you leaprogged IC4 almost you were you know doing like IC5 IC6 stuff maybe immediately what drove that RE rating that first one there's one primary thing that drove it uh which is impact right of course ratings overall especially at early levels is primarily about how much impact you can achieve right so uh our second half in the team we've actually recruited a few people which I was a big part of uh recruiting them and onboarding which is part of the rating. But our second half, we had a goal of let's just say many many dozens of millions of dollars um that we had to increase the revenue metaphor, right? The project I drove and worked on um overachieved even that half goal that had a very heavy lean as to why the redefineses. Right. Right. Right. Makes sense where Yeah. We just cared a lot about impact at Meta and I guess my manager was right when he lured me to the team saying that uh you know we didn't care about revenue, right? Um did you know that that project was going to exceed the team goal by multiple like at the beginning when I was so we we did not know right we did have a great data scientist um who I also really enjoyed working with and he had you know a hunch that it might be impactful right but I think it's it was partly also how I went about it right where many of these projects initially didn't pan out right they they were neutral but then by by showing grit And once again taking ownership and really like ensuring that when something didn't have the expected outcome, digging in to understand why didn't it, right? Like why didn't this work? So I can take two different examples here. Yeah. Where we had one project where um when an advertiser fails a payment, right, we obviously let them know and we asked them, hey, you failed a payment um if you want to keep running ads, please pay us, right? But um that experience was not very obvious to advertisers, right? So we worked on improving that to make it more obvious so that the advertisers that want to pay us actually can. When we first rolled out this improvement, completely neutral, right? And we just couldn't understand why. But we went in, we dug into it, worked together with data scientists to figure out why. And we're able to update the targeting, uh work with the designer, improve it. Um and it uh became you know about 20% of my impact that half. Um same thing with another project together with this really great DS that we had. This was the majority of my impact that half. But we were running a script once a day to update some settings for advertisers, right? And for whatever reason the experimentation logging just didn't work as expected. I made sure to fully understand why it didn't work. I reached out to the experimentation team. I reached out to the to DS. I looked deeply in the code to you know come up with a hypothesis of like what's happening. It's that behavior of full end to end ownership of the success of a project that had another big impact here. Um and as a result actually this this DS which I think at the time he might have been five maybe six and I think now is either a seven or an eight. Um he left a peer feedback saying that Simon's one of the favorite engineers um I've worked with. Right. Right. And that to me is still a feedback that I that I hold dear just cuz like that to me showed that my behaviors of truly taking that end to end ownership is important not just to to my success but also to others um enjoyment of working with me. When I was just entering the industry and you're in experiment review, there's a very big difference between the people who are really exceptional and the people who are still growing, which I found it interesting that the the some of the most exceptional engineers or maybe even my manager at the time, they were so curious about the counterintuitive results in experiment review. Whereas a lot of engineers who were just kind of like, oh, this is my future. I'm just, you know, bringing it cuz someone told me to bring it. It looks okay. They would stop there. But the the really great IC's would continue to dig and say, why is this neutral? And at least have a explanation. I think, you know, it's it's okay if, oh, it's neutral because we expected it to be neutral. There was some, you know, something here that's just not going to do the effect we want. But if there's some counterintuitive result and really digging deep and understanding, that's often where there's uh either an interesting learning forge excellence, something where it's like, oh, this is a class of problems that's going to hurt uh the team, something like that, or it's its impact because there's a fix there, like in your case, and it leads to, you know, really outsized wins. So that that makes a lot of sense. We had recruited I think another five people at this point, right? So I think the team had grown from like the two three we were at the very start to to eight, right? And I took a big part in uh the recruitment of these people but then also the the onboarding, right? And one challenge we had as a team is that now we actually had one Android and one iOS engineer. That's all we had. So and within the the payments org, we didn't really have that expertise either. I actually stretched myself and started reviewing code on all these other platforms, right? So I was reviewing code on on Android, on iOS, on the the main meta back end, which is hack, you know, PHP um as well as JavaScript, right? So I was really stretching myself in um the the excellence and and the the people um and I got a lot of positive feedback in how I do diffuse that they actually help people grow. probably not much on the Android and iOS side. Uh but specifically in like the the JavaScript side, I ensure that um as I leave different view comments, I not only uplevel the the codebase, but also the the people and it took me a few halves to like find the right um balance there where I I got feedback that hey Simon, you're you're being a little overbearing in your different views, right? But primarily I got a lot of feedback that what Simon tells me these different views makes me a better engineer and like can helps me contribute more to the team. Right. Right. Um makes sense. If you if I had asked you throughout that half, what rating do you think you're going to get? Would it have been aligned with what happened or what or did you even think about that at all? Ratings were just a byproduct of your work. To be honest, I I had no idea what to expect. I was a pretty fresh, blue-eyed person from from Sweden coming into Silicon Valley. Yeah. I didn't really know what RSUs were when I joined. Um I just looked at the salary. I was like, "Yeah, that looks good." Um I had no idea that like RSU was going to become, you know, a major part of compensation, right? Um when my for my first half when I got my my promo, right, my manager actually just told me, "Hey, meet me down in the lobby." I had no idea what to expect, right? Like we hadn't had our PC chat yet, right? But uh we met in the lobby. We took an Uber to a restaurant and uh turns out that he actually has this uh routine of whenever one of his uh reports get a promo, he takes them out to dinner, right? So I sat there not knowing what to expect at all. I guess at that point I started to suspect a little, right? But um kind of come the second half for the re I really had no idea. like I I didn't know what the expectations were really just that I knew I was doing well but not how well. That's one thing I missed after co happened is no there wasn't a lot of inerson stuff and I remember before that my manager would come with like an envelope and like paper and here you go. Um and when you got the re were you what was the reaction? I mean I was definitely happy right? Um, but the problem is that it came so early in the career, right, that it's like it was hard to know that it was a difficult rating, right? Where like I got in GE my first time plus a promo. Now I got an RE, no promo. It's like it's hard to contextualize it when all I've seen thus far is just like a promo plus a GE. Obviously, my manager told me that it's a hard one to achieve. Um, but I actually knew someone. I'm not sure if he got re when he was an IC3 or an IC4 in like a sister team. So I was like, okay, maybe it's not so hard, right? So re are really special actually. So So you mentioned no promo. How's that ## Redefining expectations without promotion? [20:01] possible? You get the absolute highest rating that almost no one gets. You don't get promoted. Why is that? There's a difference between promo and ratings. And I think this becomes especially important actually in the in the four to five because I find that often times in the four to five especially since we do have that time limit to it at meta where five is the terminal level that you need to reach within 3 months is it something like that. Yeah. Um where promos and ratings are correlated but there's not a onetoone mapping between them. Right. where ratings is more so about what you achieved and promos are more so about how you achieved it. As a four, right, the expectation is that you can drive your project forward, right? That that's kind of it. But as a five, you need to take more ownership of other people and I was starting to to touch on that a little bit, right? In terms like onboarding others, but I wasn't responsible for their success or the success of their projects. my behaviors didn't align with those VC5 uh because I didn't take that larger um responsibility and scope. Was that a question that you asked your manager when you got the RE or you didn't think too much about that? I think I was happy enough with the RE to be honest where uh I would be too promos are all about how you're getting it done and that you're getting it done in a sustainable way that is expected of the next level. But if you chanced upon or you just did a lot of IC4 work and it was very impactful that may not necessarily get you closer to the promo. Correct. I see. So then and then in the next half uh that was the co half right. Correct. Yeah. So during that half, right, there was kind of like a star, I guess you could get like a annotation in your uh performance review, right, that said like the first half of of COVID, you were significantly above, which is practically equating to a GE rating, right? Uh because we didn't do any official ratings. We didn't do any promos that half, which um I remember being a little bit sour about, right? Because now I was like, okay, I had my RE the first half as an IC4. I felt like as if I would have been on track for that um second half promo especially knowing that I you know he didn't truly say that I got the the annotation right but like he he was hinting at it so I knew that I I was doing really well right so a little bit sour on that obviously our careers are are long right so like one half isn't a big deal but um since that that half was 33% of my career right like it felt like a like a big loss time. Okay, then let's talk about the next half because you got another re. So, wait, what happened there? How you didn't just get one, you got two. How did you redefine expectations a second time? Got to say it was a little bit of a fluke slightly easier because they did boost the the rating somewhat from the previous one. So, it's possible it would have been a GE, but I was probably pretty close to the to the line regardless. I see. I see. And you're saying the the bump was because they were trying to forward credit the lack of correct. I don't think they bumped everyone to RE that had a GE. Um, but um I think um I was probably on the border if I would have gotten it otherwise. So I got the RE um my third half um or third half is IC4 plus the IC4 to IC5 promo, right? Um and I think the important thing here is that my behaviors actually started to change. Um so the team like I mentioned at the start we were kind of pivoting between different responsibilities right now we've switched from being um a bit more of an infra team back onto product uh and we took on a new product space right we ended up um splitting the team into two virtual teams or two teams and we and I took responsibility of one half of it right so for four people plus me or three people plus me um I was now responsible for going from idea completely unscoped space to completed projects and that was a first for me. Uh that required a lot of growth in terms of like how I operated but this was that big step change in terms like my scope and responsibilities where now I'm no longer responsible for my own output and my own success. I'm now responsible for the project success and the people within it. Right. Right. Um and in the end the product wasn't actually as successful but we dealt with it really well in terms of like how we behaved. Um we ended up having a bunch of leadership escalations up to director level you know um with um IC8s and stuff. You know me being an IC4 at the time um I was getting a lot of credit for that um communication. Why did your manager or whoever trust you as an IC4 to lead a pod of engineers? I and I imagine not all those engineers were just new grads or something. So there was some identifying of you to lead that that was a little bit earlier than maybe your your experience. Why do you think that is? So I think as a engineer there are kind like two primary themes to me where I am just good technically right in terms of like the diff views etc right where like I I just really love tech um and in Sweden we actually choose our major already in high school so I did computer science since I entered high school right so that's I think helped me kind of like get a nice head start and I've tried to keep ahead of that the entire time just solid technically which means that if there's hairy technical issues, I can help solve them. Uh actually regardless of platform um often times and number two, I love people, right? like I really enjoy working with people uh growing people uh ensuring that people are successful. Obviously when um I get responsibility kind like leading this pod right I am responsible for the outcome of the product the project but actually what I find more important is the outcome of the people that's working on it and I think I had shown many of these behaviors throughout um of kind of like helping others improve um and I believe that that was one of the big reasons why Bala was willing to kind of give me this responsibility um and I had been um doing some sprint planning for a couple people uh before once again I wasn't really responsible for for their success or the project success but I was responsible for for prioritization of of projects with them. When you mentioned that you were leading that pod were you meeting with these engineers one-on-one and also talking about career with them aside from just the the day-to-day tasks? Mhm. A couple people I was talking about uh career, right? But um some of them it was more just like high level stuff ensuring that like they're they're happy and um they are growing on maybe the the axis that they're lacking in rather than like how to get to the next level kind of thing, right? Like I I spot a gap and I help them fill it kind of thing. Um but I was mentoring about I think four people that have Yeah. Um I think one IC3 and like three IC4s. Yeah, I remember I was an IC4 at the time, right? Uh, and the other thing about people, right, is that this was the first half that I was an intern manager. At the same time, I was an intern peer for four different interns. Um, that's a lot. Yeah. So, I was an intern manager and and my intern struggled a lot at the start. Actually, it's one of the my proudest moments actually ensuring that they got that return offer. Yeah. Uh, because they were really struggling kind of getting them through that that finish line. How'd you turn that around? So if I remember correctly, it was u like a react project um or a hack project, one or the other, right? And it was just some of the fundamentals that took longer to understand and really gro than uh you know anticipated. Sometimes you often just need to get people over that hump and then after that they're totally fine, right? Um and I think at meta that hump can sometimes be quite high, right? I often see interns struggling quite a bit um setting up um our internal data model right with with ants um that can be a very like big hump sometimes right with her I was very generous with my time and I think that's um another thing that I find very important that be be generous with your time and in return that's going to you know help others grow which is going to make you a force multiplier which is going to like give you back time later so being generous with your time is a very high leverage projectivity. Yes. Um cuz it's going to work out better later. Yes. In in most cases, there's also the case where you invest a bunch of time and the needle never moves and Yes. There are definitely the cases where you need to call it quits. Yeah. Um and I do think that I have not yet found the right balance. I think that I might stick with people for longer than uh is worth it sometimes. Yeah. Yeah. But at least that way my conscious is clear um throughout uh cuz I do care a lot about each person's success. The turnaround case that is very impactful taking someone cuz the opposite could have happened too. You could have saved your time and they could have kept going the other direction and kind of lose a person's worth of of bandwidth. So yes. Yes. Uh it's actually quite funny. My uh my wife was getting a bit upset at me with just how much time I was spending with the intern cuz it was eating into our dinner and like date time, right? So yeah. Okay. So you got the the IC5 promo double re and everything was kind of you know it all it all made sense. You're leading a pod. Uh and then the last ## Staff promotion story [29:55] thing is you know growing from five to six. You did that very quickly. Two halves. Kind of want to dig in. And I think this one's more interesting, too, cuz the behaviors change even more than, you know, four to five or 3 to four. So, yeah, maybe you can tell me the story about the promo from five to six and we kind of dig in. So, it took me two halves. Um, and if we look at just like some of the behavior issues that I had kind of like um as got promoted to five and kind of looking forward as like what was missing for for six, right? that like while I was responsible for others um I had like fully gro that right I wasn't very good at like holding them accountable in return right to ensure that like things are on track and like I wasn't very good at just like tracking things knowing where things were etc right so I was still operating a lot on like a a trust model and just like hoping that everything works out um so that was a big gap in general so kind of like as I went from 5 to six and my two halves. Yeah. From four to five, I started leading one pod. My first half as a five, um I started leading two pods. Given more responsibility, I'm now leading um two pods uh with seven people uh in total. So the the scope is increasing for me as a result. Um which means that I need to learn how to scale myself, which is another important skill set to learn as you're growing from being responsible for a small amount of people to a large amount of people. um you know maybe as we're doing sprint planning now previously I did it now instead I you know assign um pod leads that do it for me right or like for for the team right where I am involved guiding coaching um but I let others take that uh which is another beautiful thing because now they are growing in return right now they're successful and they can make it towards um whatever goals they have I think my first half as an IC5 where It's where I'm starting to unlock the how to scale myself where whether it be sprint planning, uh whether it be recruiting onto the team, right? Where, you know, we were still meeting with a lot of boot campers to to keep growing the team. It was a different time at Meta for sure. And um I can no longer do all of this by myself, right? Where I um get a people within the team was like, "Hey, we need to coach more people." So I coach them in like how we do outreach, how we, you know, track the progress of each candidate. Um, and then I might still do the the hardest thing which might be like that first sell call, right? Like really get them hooked, right? But then I have the others kind of like take responsibility of uh the candidate moving forward, right? So unlocking that skill was a very kind of like step change for me, right? Um, but still this first half I didn't really know how to keep others accountable for that success where things were still slipping. Um, and I didn't uncover it until way too late. M um and my second half as an IC6 is then where I start to more so get that where I'm starting to be able to zoom out enough that I see that either when projects are starting to drop or people are starting to to struggle right that there are I've set up systems in place that can uncover either of these problems to ensure that people are successful and products are successful so that either, you know, some kind of intervention is required or I just need to spend some time kind of like covering a gap for a little bit. It can be just like, oh, this person is struggling with this one specific piece. Well, let me as a TL step in kind of like fix that one hairy bug and then I know that they'll be totally fine. when I was going for IC6 and that was the biggest gap that of feedback that I received which was scaling myself and sounds like your first half you delegated you gave people pieces of work and you scaled yourself but then there were maybe some gaps in assuring that those things were successful afterwards is that did I understand correctly yeah I think that that's correct there was a lot of kind of like oh the half is ending this is not done yet wow let's like figure out what happened and like how I can fix it ASAP. Um and that was I'd say pretty systematic systematic from the time I kind like just got to five up until kind of like my um or like at the half I got from four to five, right? Like this this was a problem. My second half as a five, this was a problem. And then kind like the towards the end of my five to six journey is kind of when that really clicked. Yeah. Yeah. Um cuz I um my second half as a five um I was given a lot of responsibility. We the two pods I had before right about seven people. We had recruited some more. We ended up splitting the team officially into two parts right. So I now was responsible for one part of the team which was eight people right so responsible for ensuring that you know they hit their goals. Um and we did we exceeded those goals. Uh but at the same time we spun up a separate project uh which ended up including um 13 people. So I was kind of like tailing both of these at the same time. So that really stress tested my ability to to scale myself. Yeah. Right. Specifically in that five to six journey, right? Like it's the scaling yourself. But something that is often discussed during kind of like someone preparing their promo packet for five to six is like what's the deep technical contribution, right? During my second half here, I think I was able to balance these two quite well, right? where the high level stuff of like setting the road map of uh this project right ensuring that like we have we have clear milestones. Um same thing with the with the other team where you know we have uh we have set the goals we have um hypothesis for how we might hit those goals um and then coaching the people to move in that direction right at the same time you need to show that you are a skilled engineer right and I did this through um a couple different ways one was continued diffuse throughout my career I've always valued diffuse specifically high quality differs um I've often been in the top three, top five of amount of diff reviews plus the amount of words in diff comments, which is a metric that I really enjoy looking at actually cuz I find that there's a strong correlation between the amount of words you write and the quality um that you uh give in those diffuse. So I was spending hours a day just like reviewing code which I found to be a very high leverage activity especially when you're like in a small to medium team because then you as a TL can have a really good understanding of like all the different parts of the codebase and how they fit together um and you can really you can catch issues early right for example I was reviewing you know Android iOS iOS server which meant that when I saw that um the Android engineer in um implemented something this way, the iOS engineer implemented this way, the server engineer was trying to do it a third way. It's like wait, hey guys, like let's figure out like how what's the one unified way of doing it, right? So, different use was one very high leverage activity in terms of like technical contributions. Mhm. And number two, um, on the big project that we had, um, we were getting really close to the, um, the milestone, but we were really struggling to kind of get it over the that line, right? It was, it was a payments product, um, that crossed between IG to Meta's main backend stack onto the um, payments back end, which is in C++ um, onto a third party payments partner, right? M and we just couldn't make it all happen, right? So I went in as a TL. I spent many many hours just like digging deep into the code, which meant that I had to go from the Android iOS code onto the um IG servers back end onto the the meta main back end onto C++ and I had like break points all over these code bases, right? would just show that like I was able to work at a very wide span but also just like very detailed um and and go deep and solve the the hairiest problems that we had. You were able to hand off things but maybe not assure their their success. What was the the the one thing that you switched in that half where that really made the big difference and close that gap? My manager uh used to say delegation is not abdication. It means that you may delegate whatever you want but in the end you were responsible for the outcome. I assumed that this person would get it done and I I hoped they would, right? But as I grew, I internalized this more and I also set up processes that helped me catch these issues. Whether it's like a weekly um me um sprint meeting or something where like you catch up with people and see like oh are they progressing and you actually pay attention and see is the thing they're working on actually moving as we intended. I strongly believe actually that every team should have a people breakdown and a project breakdown. Yeah. Uh because I I find that that to be incredibly helpful where a project um might be on track, right? But that project might be um supported by multiple different people. But then when you look at the people breakdown, it might be that oh this one person is doing really well on the project, but this other person is really struggling and hasn't really landed anything for a few weeks. And that's a huge red flag which like if you only look at the project level, you might be missing that there's someone on the team struggling um that needs your support. So when you say abdication, you just mean that when you hand something off for delegation, you continue to in your mind think that this is still my responsibility. I'm going to deliver this. It's just it's coming through someone. It's a a tactic for getting it done, but it's not just like trust and forget about it kind of thing. You like continue to stay on top of it. I think early in my four to five journey um as I'm trying to scale myself through others, I got feedback like, "Hey, Simon, like take a step back, right? Like you're you're stepping on my toes like I need some room to like implement this, right? Like you you gave me a project just like step away for a bit to ensure that like I can grow." I think that's uh one of the big steps between four and five where you actually need to learn to let go right you can no longer achieve everything yourself even more so five to six where like now you need to uh you might not even be able to review all the code anymore right like you you need to trust that the other people in your team can support um the different projects but you still verify through them just maybe not micromanage exactly I'm curious after you got ## Transitioning to and from management [41:00] promoted to six because your your trajectory was rocket ship, right? Did you what what were you thinking in terms of career planning? Cuz you had exceeded your original goal. You wanted to get to five. You got to six faster than you know a lot of people thought. Were you thinking about seven or did you want to do management or were you thinking I achieved the goal I want it's time for personal life or something like that? Yeah. Um I mean I was definitely you know hungry for more, right? Uh, and I guess I still am in some ways. Yes. Um, but um I also recognize that like in some ways it's a bit of a crossroads, right? Where like now there's the option of management and uh I guess we'll get to this, but I did choose the manager route for a little bit, but I struggled a lot with that decision. My identity was definitely part of like being a good engineer, right? And I was so worried about losing that 5 10 years down the line. uh if I switch to management now will I just become a middle manager that have lost all their uh technical abilities and like I've stopped providing value and I'm just you know existing right that was a a huge concern of mine to be honest right so in the end I did choose the the management route um but ended up switching back to to IC yeah so I mean I had a very similar exact thinking because I love the the building aspect of it and the technology so how did you make that decision to become a manager? One large part actually is that I was still with my same manager. The same manager that I had since I started the company as an IC3. He was still my manager now as an IC6. Uh and the funny thing is that we started together or I mean he started before me but when I started, you know, I was in California. Now we're actually in London, right? We're both working in London. So you moved with him, correct? Yeah. So uh he sounds like a great manager, so it's seems worth it. Truly. Yeah. So, you know, I'm now in in London. We're working together. Uh we're starting up a new team. So, he he was leading two teams. I got one of the teams as a TL and then, you know, there was the opportunity to become a manager um because the team was like seven, eight people. my manager was getting too many direct reports and because I knew that I had my manager support uh and that he's been coaching me so well throughout my entire career uh and I find him to be an extraordinary manager uh it felt like if I do the manager shift doing it together with him might be the best thing I like how he is as a manager if I become a manager I would like to become similar to him and thus um now might be the time to do it. Right. Right. Having a good manager may be the best gift that someone could have uh if they're very ambitious in career and wanting to grow. And you are were very lucky and fortunate to have such a wonderful manager. What are the the things that made him special as a manager? He cared, right? He cared about people. He cared about projects um about impact. He he knew the company right he I mean by now he's been here 10 years bit more um so when I joined he had probably been at the company like fourish years so he knew the process you know he he knew everything right and he himself had had such a rocket ship uh trajectory within the company uh that he uh I think really understood what I wanted to achieve. Uh I think the other thing that really made him stand out um as an engineering manager is that he was probably more of a product person really uh which is funny because he actually just a few months back switched as to a PM uh within meta right so um he was really able to set the road map of the team um at a really great level of detail um upwards communication downwards communication um which then let the engineers in the team uh once we were uh ready to I guess you know as he had um coached us to really run with it right on the engineering front and then he kept coaching us on the the product management and like data and and growth front uh to ensure that like we can become engineers that are you know valuable to the company and one more skill that he does very well is communication right and it's something that he coached us really well in because I do believe that to be successful at a large company as Meta, communication is key. Written communication especially is incredibly high leverage. I mean we have our internal forum workplace at Meta. If you post a post, thousands of people can see it. If you write effectively so that people actually get the message uh from what you're trying to say, it makes such a huge difference. Um I actually believe that a lot of people are held back in their career because they might be doing amazing things but they can't communicate just how good that is. Of course, sometimes it's like in meetings um if people are struggling to communicate clearly um in spoken word. Uh but I believe that the biggest hindrance for people might be written communication where when they write a post to communicate that I achieved this project, this is why it's important. They might just say I did this, right? But like but why? What was the learning? Like what did Meta or the team or the or gain from this? And I think that's one big gap that that people have. I agree 100%. And written versus spoken, I agree. Written is definitely higher leverage because the largest audience the average engineer is speaking to is maybe dozens of people at most. But in written language, it can be read by, you know, at least a hundred very simply. And you know, over time too, it's referenced again later. People look back on it. it's uh used for future decisions and you know I agree 100%. What is it that makes an effective update or piece of writing about your project? Like what makes it effective? Consider that the person that will read it will spend 5 10 seconds most make it incredibly parsible at a glance. Yes. Right. The TLDDR, right? Make sure it's truly a TLDDR. Yeah. If possible include numbers, right? like people understand the numbers much better than you know written words truly that's like the the most important thing and that should be so in workplace we kind like you know um fold the posts uh together right when they're too long so ensure that TLDDR is truly above the fold so that it's it's right there oh you're talking about the see more yeah okay so whatever that first thing is that they see really gets across a strong message exactly I see and then also make sure that when you write the post. Um, consider the audience or try to write the post in different sections, target different audiences. Um, if you try to communicate to a large audience, let's say hundreds, likely most of them won't have that same technical knowledge of the specific piece that you're working on, but they might care about um the outcome and the why and maybe the next steps. So I often do, you know, like the flashy title, TLDDR with some numbers, you know, set the context and um then kind of like the the impact and next steps, right? That's kind of like always what I keep towards the top as like the top three sections. But then I might have like a and here's more have all the technical details to, you know, attract the the fellow nerds, right? Like get the other people that are like really interested in like the the how, not just the why. Uh 100%. I think that's the biggest communication mistake that software engineers make is they've been deep in the weeds of the project details and then I read a post and it's full of all this stuff of you know I went to into this system and then I found this line of code and then you know it turns out that this this didn't execute and there's an exception well and all of that I mean that only matters to maybe your one or two collaborator that knows all those details and that happens in meetings as well. Someone's giving an update and it's just all the stuff that I mean it matters but just not to the people that are listening. What's the what's the high level? Is it on track or not? Is what was the number movement? Why should they care in like two lines? Like that's the most important fix I feel. You said you were worried about losing the technical after having tried management. What did you you learn? Was it actually a concern that you lose the technical aspects? So, I was only a manager for about a little bit less than a year, right? So, I didn't have the time to measure if I would truly lose my technical ability, right? Um, and to be honest, it was one of the feedback I got from uh the people I was um managing. It's like Simon step away from the technical. So, I think I was struggling a little bit in the IC to manager transition and that I still wanted to do some technical work. This was bit of a struggle for me partially because at the company they were trying at the time to encourage managers to do a bit more technical work but also if if you've been the TL you're now the manager you see a gap and you're like I I really want to fill that gap. I was really struggling there to be honest. I got feedback on it. Uh I don't think I fully truly corrected in the end. Yeah. Um before I ended up switching. Uh I had some really bad luck actually um in my manager transition. my immediate manager that had been with um for such a long time um ended up in a accident. Had to be out out of work for like three four months, right? So no immediate u support network there. Um my skip manager um was on path leave, right? So okay, no support there. Um the closest person in the management chain management chain was a director in California and remember we were in London. So time zones were hard. And this director had come back from long-term sick leave as well. So weren't like fully up to date on all that had happened. Yeah. So that was tough, right? I I was given this um where I move into this role and pretty immediately after lost a lot of my strong support network. I also had two people that wanted to grow from five to six. Uh and I think I overpromised, right? I was like, you know, maybe we can make this happen. Yeah. Um, and I think I had one of them on the right trajectory, right? Because they were able to kind of take my role as TL. Um, but then for the other person, it was hard to really slot that in. Uh, to like get two people from five to six at the same time in the same team of like eight people, right, is a really tough thing to do. I think I overpromised there a little bit which is definitely a learning uh if I ever transition to management again. And um for reasons um we also had to leave London and uh chaotic ridiculous. Exactly. So with all that um there was just too much going on a lot of just like heartache in leaving London and supporting team at the same time. So I I got burned out a little bit as manager just decided to move back into IC which I've been very happy with since. I mean, you could have also found another manager role or without all that chaos. What was the thing that made you want to go back to IC specifically? Yeah, I remember my director, she asked me like, "Simon, do you want to go back to IC?" And it hit me like, "Yes, yes, I do." I think it was more of a gut feel to be honest. Um, just like, "Uh, all right." I tried it. Incredibly poor timing. let me just like take a break from it, go back to what I know, just like get back into the previous groove, right? And you know, I'm totally open to management. Um, not yet though. I think I want another 3 to 5 years. I actually think that I see six is a great level at Meta specifically when it comes to like um compared to management, right? Where because the type of engineer I am is that I enjoy growing others, right? So now I actually get to spend my time doing edge work, spend a lot of time like mentoring and coaching others. Mhm. And that like mentoring and coaching becomes a bit more of a uh a bonus, right? In terms of like my performance evaluation, right? Right. Compared to if I'm a manager, that becomes now like the main thing I'm evaluated on. And you know, not everyone's fun to coach. And like now I can kind of pick and choose a little bit like who and what I'd like to coach. Yeah. Um, so I find that as an IC that enjoys people stuff, I actually have way more flexibility in how I apply um that people stuff. As a manager, you take on responsibility for everyone and it's an unconditional support. As an IC, you you kind of pick your project. You know, you're you're creating scope as IC6. So you kind of create scope that you you want to work on and you are helping the people you want to help. I mean not not fully there's still some stuff where you need to take responsibility but there is a lot more optionality that that makes a lot of sense and you got burned out not specifically because of management but there the circumstances around it uh was just really tough. Um I think I probably would have stuck with it if the circumstance had been better. Um I might have still switched back to IC. I I find that quite likely to be honest, but I think I would have stuck with management for longer before I made that switch back. Before we fully leave your kind of fully transparent ratings and promos. Um ## Secret equity bonuses [54:50] I think you had mentioned that you received DE uh once or twice throughout your journey and DE stands for discretionary equity. U I think it's called AE in some cases like additional equity. What what is that? H how does it work? Maybe you could tell us about your experience. Yeah. Yeah. Additional equity um is when um a director chooses to give you more RSUs, right? More stock options. This happened twice in my career. Um first time around was in my 5 to6 promo where I got a random 15 minutes calendar slot on my calendar one day. Um I with a with a director um I show up um he's there and he's like, "Simon, do you know do you know why we have this meeting?" I'm like, "I have no idea." He's like, "Oh, no. Uh and he told me, you know, like, hey, yeah, like we decided to give you um discretionary equity. Um which, you know, I had heard about because I've been in the company for like 3 years now, but once again, I was pretty like naive and new and like I didn't really know what to expect, right? Cuz you sometimes you go into kind of like the internal compensation group where like people post about their their success and it's a huge selection selection bias about who posts in there, right? It's usually the people that get great ratings that get AE. Um, so obviously I'd seen a bunch of those posts. I was like, "Okay, like all right, great. That that happens, right?" So like I was incredibly humbled, right? And like it felt really good. Um, but I didn't like understand it really. But I guess I, you know, I got in um great ratings throughout. Um, and since I started as an IC3, I assumed that maybe um, they were worried about some attrition given um, that my stock options when I started probably quite a bit lower compared to what it would be for for an IC6. I see. So that first DE was it wasn't gamechanging. It just kind of gave you maybe a little bit more than market. Is that right? Yeah, I believe so. Um it was a bit hard to know at the time because the meta stock had just crashed which is great now when it has not crashed. Um that was actually similar with the second um AE uh that I got a year later. Um so I've been IC6 for a year. I guess I just transitioned to to management. Yeah. Um and I ended up getting uh my second AE. Mhm. I believe it's primarily due to the success of the team I took over. Right. So I I moved to London, right? took over part of the team. We shipped the product in a much faster timeline than anticipated, right? And it was a company priority as so many things are at the company. Um, but we executed well and like we got it done, right? Um, so I think that the success of that uh and the behaviors I showed uh were a large part as why I got that second AE. Um, and I would say that these two combined have definitely had a large impact on my total comp and what it would be compared to normal market rate. When you see a 15minute no agenda meeting from some senior director you never talked to. Did what did you think when you saw that on your calendar? I don't even know, man. Like it's uh I I honestly had no idea what to expect. I was a little sweaty going in. I was like, "All right, what's what's going to happen here?" Turns out it was a good one. So yeah. Yeah. Yeah. Yeah, I have a friend who, you know, this is happening to and he's like, I think I'm going to get fired cuz it's like you you never get a meeting like that. So, you ## The best interns [58:14] mentioned you were you were an intern, but also at some point you told me you were an intern director, too. So, you kind of seen internships on both sides of it. What's something that is like the, you know, top things to keep in mind or like the the 8020 tips that Yeah. you see separate the best interns from the people who are not as good. Yes. Let me briefly touch on my history when it comes to to interns, right? So, I was an intern to start. Um, and honestly, I didn't do very well. I think I was very close to not getting an offer. Um, luckily I'm here today because I did get the offer. Uh, but I think that I didn't do that well and I think maybe we'll cover that. But then I was an intern manager twice. Uh the first time around I had an intern that um like I mentioned went from kind of meets most expectations to actually meeting and getting a return offer. Um sec and and that at the same time I was a peer intern for interns. The second time around uh I had an intern um rockstar intern, right? Like we had a couple um new hire IC3s at the same time and my intern was coaching the IC3s, right? Like Yeah. How's that? What? He he was just so good at JavaScript, so good at uh React that like he blew through everything and was like coaching the others like this is how you do it. What university? It was over in Mexico. Okay. So, yeah, it's and I asked by the way cuz I had I had a lot of interns as well and I noticed the ones that come from Waterlue were just like the water ones are great. They came in and they're like I icy for I'm like you know how to do everything already. Then I had two summers or I guess one winter and one summer that I was an intern director, right? And the responsibility of an intern director is that you practically manage 10 intern managers. So you as the intern director is responsible that the intern manager actually produces a solid uh project plan. Um and then you do three check-ins with the intern managers. You do a three-we check-in making sure that the intern is ramping up all right. You do the midpoint checking to make sure like are things like on track for the project. and then the final check-in where you know ahead of the the final review. Um so on to your question of like what are some of the the things that stand out between really solid interns maybe interns that that don't make it. The simplest way to look at it, right, is like velocity in some ways, right? Like velocity is incredibly important, right? Because the main measure of success for an intern is did you complete your intern projects. That is the primary thing we look at. Of course, it's important how you do it, but if you didn't do it, then that's almost like a a fail by itself. Obviously, there are safeguards to see like was the project just like completely misscoped, right? But uh hopefully throughout the process that's been like corrected already. Um so velocity is incredibly important, right? And with that comes trying to do a fast ramp up, right? And I think a lot of interns that don't make it don't ask enough questions early on. Whether you're an intern, whether you're an IC3, whether you're like joining a new team, those first couple weeks are so important to like utilize your ability to be dumb, right? To like ask those dumb questions, right? like it's the most valuable time that you have because the expectations of you are practically zero. So you can ask people however much you want. And this is something that I kept repeating to um interns I had as well as like IC3's joining especially just like if you have a question that takes you more than like 30 minutes to an hour like ping me please right like if you keep spending an hour on like all these small questions that like we could resolve in 30 seconds like you will not be successful right so please please ping questions right it's incredibly important especially early on because it's very different to ask a question of like oh how do I do the super basic thing week one compared to week six, right? Like please get that done early. Um it's very uh it will really help your velocity. And another thing here is that the the intern program at Meta is set up that you have your intern manager and then you have usually two peers but sometimes more. Also do take advantage of your peers uh for two reasons. Um one reason is maybe you're asking too many questions. Your managers just can't deal with them all. Right? So, uh maybe have a chat group with, you know, uh your inter manager plus peers. Make sure you can ask questions in there. They can kind of like load balance between themselves, right? Um and number two is that when we look at intern performance, we actually we obviously primarily look at the feedback from the intern manager, but the peer feedback from the peers you have are two other critical pieces of input. Um and sometimes when there's insufficient amount of evidence of um you know the right behaviors and such then inter managers inter directors we need to go in do a lot of digging to to clarify that right but if your peers know you they know your project they know what you're doing how you're doing it um that makes everything much much easier um and they can uh vouch for you much better. You talked about the velocity and one immediate gut reaction is okay what if I work twice the hours to get it done and I think some people might hear that oh if you're if you're barely meeting expectations but you're working crazy hours then you know you might get penalized or something like is do you do you have any thoughts on on that? We do try to get a sense of just like how much someone is working. Like is this feasible in the long term? If someone's just on the line and we see that like they're pushing diffs at like 6:00 a.m. but also 3:00 a.m. like every day, right? Like that's a huge red flag that like this person might not be able to like sustain this for very long. Uh and I'd say it's primarily an indicator when they're just around that line. But the the other thing is that not just for for interns, right? But just like for for any employee, engineer, right? Like taking care of yourself is important, right? I truly believe that you need to take care of like mind and body to be a successful person. To me, working out is incredibly important. I I journal every day, right? I make sure that like I have my focus time in the morning where I can like do focus work uh instead of just like being stuck in meetings, right? And like these rituals are something that like ensures that I function effectively. And obviously I've had times where like um specifically actually between 5 to 6 um trying to solve that like very hairy bug. I was doing like 12 14 hour days like for a week and a half straight. That was tough, right? But like it was worth doing like a short sprint of like really hard work. Um but I I know I couldn't keep that up. I was skipping my workouts. I was having way too much coffee and I could just feel my mind every morning just like slowing down, right? So, of course, you can like put in more hours, but just try to be intentional about it to ensure that like you can't put in more hours the entirety of it. Um, but to reach a specific milestones at times um could be one way of achieving that. In your ambitious growth, you had points where you're sprinting, but you were not your steady state was never a ridiculous health sacrificing kind of grind. Um, what what is that peak steady state that you've you've learned you can maintain like maybe an hours per week? Uh, I probably average like 50 hours um a weekish. Um like I I'm a morning person. So um I wake up, I have my coffee, walk the dog, uh work out, and then you know I maybe start work. And then some days maybe that's like 7:30, 8:00. Um and maybe end up working till like 6:00 p.m. because I need to um have meetings with like um California. Right. Right. Right. Right. Um so some days are longer, some days are shorter. I also just like really enjoy what I do. um and like the team I work with. So I switched teams somewhat recently specifically because I was losing the energy I had on like that same amount of hours, right? Where um those same 50 hours starting to like really feel like a grind, right? Like and I just couldn't understand why, right? So I had to do quite a bit of self-reflection to understand why that might be. Yeah. It was simply because I was like losing the interest in that one area. And one of the great things about Meta is that huge company and they're also very flexible about internal mobility. So I was able to switch to to a new team and an infra team and um honestly it's been a lot of fun. Got a lot of my fire back and I just like feel like I the quality of work I'm able to produce is significantly different when um I have that interest in fire compared to like just chugging along. I see. No, that makes sense. So, it sounds like you're saying work life balance is um somewhat tied to your interest and motivation in the work. Like sounds like you could you could work 20 hours a week on something you hate and that could feel worse than 50 hours a week on something that you're really passionate about. I see. in my career when I was really grinding for promos and things I felt that I had work life balance even though I was working a lot of hours. Yeah. Cuz it's if you love it then it's not really I mean you that's cliche but you know it it does not feel like so much work. So you know ## Where most of his growth came from [01:07:50] for this last bit of the conversation I kind of just want to reflect on your career a bit and kind of ask you some higher level stuff looking back. So, you know, when it comes to the whole thing so far, where did most of the growth come from? Like, what were the things, let's say I'm trying to reverse engineer your career growth, what were the the factors that led to that growth? I mean, I think the overall word is like ownership, right? And then like there's a million things within. I think ownership can be in the small, right? like I ensure that this task gets done or it can be I own the success of this team right but if you start talking especially about like early career uh people right then like ownership means that you you ensure the success of your one thing right and to me I find that this actually requires a lot of curiosity and we have this saying at meta of like nothing at meta is someone else's problem the way that I interpret that right is that like if you find an issue right? That's like blocking you. You don't necessarily have to wait for the other team to tell you why you're getting blocked. Read the code. Like that's one of the great things about a monor repo. Just like read the code, read the diffs. Why did they add it? Like what's the the reasoning? Can we change it? Like come up with a a brief proposal, right? And like research your your questions or just like approach ahead of time um to be able to move forward. That kind of curiosity uh slash ownership slash um you know not accepting being blocked uh I think is really critical for that um fast growth especially early on. Now it's no longer just like that one piece of code. Maybe it's like um collaboration with a cross functional partner like why is that not working? Let's understand their intention, right? Like let's be empathetic. Like why is someone behaving a certain way? Like are they getting evaluated on on this one metric that you're regressing, right? Like trying to be kind and understand others. Um I think is also a really other important piece. Yeah. And it sounds like as your career grew that umbrella of ownership just kind of kept expanding, kept expanding. And I imagine it even continues further. or if you were like a IC8 you like I care about what these 300 people are doing and that it's successful. So yeah, it's interesting you say when I ask you that question the answer is kind of a non-technical behavior. It's you know of ownership. When you think about a successful engineer, do what percent of it I know it's kind of hard to quantify, but what percent of it is non-technical stuff and what percent of it is technical stuff that leads to kind of career growth? I think you can be incredibly successful with just a baseline level of technical skills. You need to be able to know how to get the task done, right? Um, but you can totally get to IC5 without like being able to be like the the true um I can solve any problem thrown my way kind of person, right? like if you can get your stuff done and like your cont overall contributions of like chatting with the designer uh pulling the data um you know uh collaborating with others like you don't need much more than that like baseline level of like I can ensure that like what is given to me can be executed and like done in a high enough quality way. I see. Okay. Okay. So, it sounds like technical skills needed up to a point but past that point diminishing returns and the non-technical skills are kind of what really differentiates and grows people quickly I would say. So, um with the one caveat of like there are some people are just like so technically talented that like that just like outweighs everything, right? So, like there are obviously the edge cases there, right? But to I do think that like soft skills is incredibly important for a fast career because people need to enjoy working with you for them to kind of give you those opportunities to grow to trust you. You've been at Meta your ## What keeps him at Meta [01:12:04] entire career at this point which in this industry is unusual. What is the thing that's kept you at Meta for so long? bit of a copout answer, but people is definitely a big part of it, right? Like I do really love the people at Meta. Um my manager obviously, right? U but also my my co-workers, right? And I think this was especially true actually um in my first team, right, where I joined as a second engineer. We ended up growing the team to like 16 people before we like split into two, right? And since I was a large part of uh recruiting there, honestly, like it felt like a bit of a family, right? like it was it was a really happy supportive environment. Um to be honest, a lot of people we hired were also like straight out of college. Like it was a very like young fun um thing, especially since I was just out of college, too, right? So, it was a really just like welcoming, happy experience. Obviously, I'm not no longer straight out of college, but still, I really enjoy my co-workers. I find that people are mostly empathetic with each others, right? Like people understand others reasons and we try to be kind to each other and people are just really good technically too, right? Um so people is definitely like one big part, right? Why I'm staying at Meta, right? U number two is that I find that the flexibility of Meta is also quite incredible, right? In terms of like internal mobility, I've been working in um California. Um so I worked in um Menlo Park to start which is the HQ during co was down in LA. I went back to SF you know did a year in um London um came back this time to New York. Um so just like that flexibility in terms of like global location has been really great but also like internal projects. Obviously my first team it was actually quite a bit of forced movement in terms of like what we focused on. But now like I mentioned I was losing my drive. the hour starting to feel like a real drag, a real slug and I figured, you know, like I need to change something up. I I did consider going elsewhere. Uh but I figured let's give Meta another shot, right, and like see what's up. And I joined this new team uh in the um ID server infra and it's been great. Like once again, people are great. Uh I'm learning so much. I can go incredibly deep technically, which is something that's I love nerding out about. a lot of those like check boxes as to like what makes me tick um just like keep appearing within meta. Um and thus I don't have like a strong drive to seek elsewhere. Uh which you know might change in the future. Um I find that there are some things you just can't um experience at meta but um I haven't reached a point uh yet. Yeah. No, that makes sense. There there was someone that I worked with who was exceptionally senior you know everything was going well at meta and I was thinking you know have you ever considered leaving and he said actually he considers leaving every year not not from a perspective I don't like it here but more of like a housekeeping of you know you consider it and if it turns out I am happiest where I am now that gives you even more confidence that this is the right place I'm doing the right thing and all that. So, okay. And then the last question, ## Advice to his younger self [01:15:20] the the question I want to ask is if you were to go back in time, you're talking to yourself, right? When you had graduated and joined Meta and you give yourself advice, what would that advice be? Be curious and like nothing else someone else's problem. Take ownership, right? And obviously when you're new, you got to keep in mind how much time you spend on each thing, right? Similar to like the intern, right? like ask a lot of questions early on like get that velocity right. But once you got that velocity right and that like baseline level of um productivity start asking these questions right like why was this done this way within the codes become a bit of like a archaeologist to understand like why certain decisions were made if it's blocking you don't just say oh it is this way therefore it will always be this way uh kind of like question those early decisions because especially at a big company like Meta there are layers and layers and layers of tech debt and just like overall decisions that may may no longer hold. There are a lot of like debt experiments lying around the codebase and like maybe you can just like clean that up that will make your things easier. Take ownership, be curious and um nothing else someone else's problem. Okay. Well, thanks for the interview. Is there anyone you wanted to shout out before we end? Yes, I promised Chris u that is covering my own call shift right now to give him a shout out. So, thank you Chris for covering my own call. Awesome. Thanks. so much for this this interview, Simon. Was really looking forward to it. Someone that had worked with you said you were, you know, one of their favorite people that you've they've ever worked with. So, thanks for for giving to the community. Appreciate it. Yeah. All right. Thank you very much, Ryan. Hey, thanks for watching the ## Outro [01:17:05] show. I don't sell anything or do sponsorships, but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interview. So, if anyone comes up who you think you really want to hear their career story, uh, let me know and I'll try to reach out to them and get them on the show. Thanks for listening as always and I'll see you next time.