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

Episode Date: July 4, 2025

Simon Kindström is a Staff Software Eng (IC6) at Instagram who joined the company as a new grad and got promoted every year. He also achieved the highest ratings ("Redefines Expectations") twice which is almost unheard of. He shared stories about his high performance including what it's like to receive secret equity bonuses.In this episode, we discuss:• His promotions to Staff in 3 years• The story behind his "Redefines Expectations" ratings• What it's like to receive performance-based equity bonuses• His transition to management• Why he switched from management• Advice for his younger selfTimestamps:(00:00) Intro(02:34) Staff promotions in 3 years(10:32) “Redefines” expectations ratings(20:01) Redefining expectations without promotion?(29:55) Staff promotion story(41:00) Transitioning to and from management(54:50) Secret equity bonuses(58:14) The best interns(1:07:50) Where most of his growth came from(1:12:04) What keeps him at Meta(1:15:20) Advice to his younger self(1:17:05) OutroWhere to find Simon:• LinkedIn: https://www.linkedin.com/in/simonkindstrom/Where to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman

If I switched to management now, will I just become a mill manager? Then, like, I've stopped providing value. This is Simon. He grew from a new grad to a staff engineer at Meta in three years, earning the highest ratings twice. And RE stands for redefines expectations, which there's meets all. There's exceeds. There's greatly exceeding expectations.

And then there's redefines. 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 RISUs, 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, do you want to go back to I see?

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 three 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 he 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 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, specifically improving that experience. It's like a payments growth team. So the primary metric we were looking at is just revenue, right? Which was great because it's very easy to improve impact there.

We were doing a big migration in the ads payment space. We kind of became a bit more of a ads payment. PAYMINN's Infra team for a little bit to support the migration. People across the world use our apps very differently. For example, in Thailand, a lot of people purchase things on Messenger. They send bank slips back and forth to prove that the purchase has happened. So that was a big focus 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 it went back to product at some point. That's right. All the same manager. Correct. Yeah. Sounds good. Let's talk about the promo.

So three promos in three years, and this was including the promo block with COVID that we can talk about in a bit. You know, let's be super transparent of all the ratings and everything, if you're willing. The first promo from three to four, that was in one half and that was a GE rating, right? Correct. Yeah. I see. I mean, for that to happen, you basically needed to start immediately as an IC4 because you need at least six 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's custom.

I kind of already learned how to use fabricator, the internal task tool, etc. So they're probably shaved off at least four to eight weeks 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's 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 lent code at meta. I was able to move quite quickly and also even help

some of the other new joiners together with me, which immediately increased my, I guess, scope and impact right there. Yeah, I think a lot of really eager, ambitious, it's either interns or new hire, 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 they're working on the internal tools. It sounds like for you it actually was pretty effective. How did you find those early resources? The resources primarily was just trying to build stuff and react, to be honest, right? And also I spend a lot of time on hacker news 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. Because 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 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 one-to-one mapping, but they're pretty close. So if you're good with TypeScript, you would do very well with Flow and vice versa.

Just exploring and being aware of different technologies 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 was 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 GE promo in one half?

One thing that really set me up for success is that actually ended up joining a very new team. So I was the second engineer, which did mean that it 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 impact for projects, etc. I would say the rating 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 the behaviors of the next level. One big difference between IC3 and IC4 is taking ownership of kind of 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 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 seeking a lot of assistance from others, but the willingness and the kind of pushing that forward is the behavior that likely got me twice, eight forth. You mentioned that going to a new team was an asset, but 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 team? And how'd that play?

Where'd you get the mentorship from? How'd you grow in that sense? Yeah. Yeah. So when I joined Meta, I was planning on going into an infrared team, right? So I said I had done some research into React and stuff, and I thought 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 went through boot camp and you spoke to many different managers to see which team would you like to join.

I set up one meeting with Bala, the manager of the team I ended up joining. Bala was the first manager I spoke to, and he told me that, you know, Simon, we care about impact at META and was more impactful than revenue. So I ended up there, right? So 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. But because my manager, he was somewhat recently converted IC6 to manager as well.

So he had that deep technical knowledge still. 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 in meta, such as like running experiments. So my first half at meta, I ran 20 experiments. And we were a pretty small org within payments and not really like used to run experiments. Right. So the entire org ran 50 and I ran 20 of those. So kind of 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 Madda, I had decided for myself, I want to be IC5 within three years. So I guess I overachieve there. Yeah. But that was kind of my goal. Okay. So as I chatted with the different managers, I told him this. i was like hey i would like to get to icc5 in three years right i know it's ambitious yeah 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 yeah yeah so i think he actually did that exact same path similar to to me in terms 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 percent i I credit a lot of my success and growth to Bala. 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 COVID half, which may or may not have blocked a promo.

And 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 redefines expectations, which for reference. 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 redefines.

I remember when I first heard redefines, I think that is the coolest one. 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. So the first half, you got an RE rating as an IC4. Not only is that impressive because it's an RE rating, but you had just gotten promoted. So it's almost like you leapfrogged IC4 almost.

You were doing like IC5, IC6 stuff maybe immediately. What drove that RE rating that first one? There's one primary thing that drove it, which is impact, right? Of course. Ratings overall, especially at early levels, is primarily about how much impact you can achieve. Yeah. So our second half in the team, we've actually recruited a few people, which I was a big part of recruiting them and onboarding them, 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 that we had to increase the revenue of metaphor, right?

The project I drove and worked on overachieved even that half goal. That had a very heavy lean as to why the redefines. Right, right. Makes sense. Yeah, we just care a lot about impact that meta. And I guess my manager was right when he lured me to the team saying that, you know, we didn't care about revenue. Right. Did you know that that project was going to exceed the team goal by multiple, like at the beginning when it was.

So we did not know, right? We did have a great data scientist. We also really enjoyed working with. And he had, you know, a hunch that it might be impactful. Yeah. Right. But I think it's, it was partly also how. how I went about it, right?

Where many of these projects initially didn't pan out, right? They were neutral. But then by showing grit and once again, taking ownership and really like ensuring that when something didn't have the expected outcome, then you in to understand why didn't it, right? Like why didn't this work? So I can take two different examples here. Where we had one project where when an advertiser fails a payment, right?

We obviously let them know. We asked them, hey, you fail the payment. If you want to keep running ads, please pay us. But that experience was not very obvious to advertisers. 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, it was completely neutral. And we just couldn't understand why.

But we went in, we dug into it, worked together with data scientists, to figure out why. We're able to update the targeting, work with the designer, improve it, and it became about 20% of my impact that have. Same thing with another project, together with this really great DS that we had. This was the majority of my impact that have. 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 DS. I looked deeply in the code to 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. And as a result, actually, 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. He left peer feedback saying that Simon's one of the favorite engineers I've worked with. And that to me is still a feedback that I hold dear.

Just because that to me show that my behaviors of truly taking the end-to-end ownership is important, not just to my success, but also to others' 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 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 are just kind of like, oh, this is my future, I'm just, you know, bringing it because someone told me to bring it, it looks okay they would stop there but the the really great i sees would continue to dig and say

why is this neutral and at least have an 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 either an interesting learning for NG excellence, something where it's like, oh, this is a class of problems that's gonna hurt the team, something like that. Or it's impact because it is a fix there,

like in your case, and it leads to, you know, really outsized winds. So that makes a lot of sense. We had recruited, I think another five people at this point, right? I think the team had grown from like the two, three, we were at the very start to eight, right? And I took a big part in,

the recruitment of these people, but then also the onboarding. 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 payments org, we didn't really have that expertise either. I actually stretched myself and started reviewing code on all these other platforms. So I was reviewing code on Android, on iOS, on the main meta backend, which is HACC, as well as JavaScript. So I was really stretching myself in the NJX lens and the people. And I got a lot of positive feedback in how I do Diff reviews that they actually help people grow.

Probably not much on the Android iOS side, but specifically in like the JavaScript side, I ensure that as I leave DiffRew comments, I not only uplevel the code base, but also the people. And it took me a few halves to find the right balance there where I got feedback. that, hey, Simon, you're being a little overbearing in your diff reviews, right? But primarily I got a lot of feedback that what Simon tells me these diff reviews makes me a better engineer and like can helps me contribute more to the team. Right, right. 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 had no idea what to expect. I was a pretty fresh, blue-eyed person from Sweden coming into Silicon Valley. I didn't really know what RSUs were when I joined. I just looked at the salary. I was like, yeah, that looks good. I had no idea that RISU was going to become a major part of compensation. For my first half, when I got my promo, right, my manager actually just told me,

hey, meet me down in the lobby. I had no idea what to expect. Like we hadn't had our PC chat. Yeah, right? But we met in the lobby. We took an Uber to a restaurant and it turns out that he actually has this routine of whenever one of his reports get a promo, he takes them out to dinner. So I sat there not knowing what to expect at all. I guess at that point it started to suspect a little, right?

But can I come to the second half for the RE? I really had no idea. Like I didn't know what the expectations were really. I knew I was doing well, but not. not how well. That's one thing I miss after COVID happens is no, there wasn't a lot of in-person stuff. I remember before that my manager would come with like an envelope and like paper and you go.

And when you got the RE where you, what was the reaction? I mean, I was definitely happy, right? 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. Yeah, yeah. We're 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. Yeah. 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 it's like, okay, maybe it's not so hard, right? So, our users are really special, actually. So you mentioned no promo.

How is that possible? The absolute highest rating that almost no one gets that 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 four to five. Because I find that oftentimes in the four to five, especially since we do have that time limits to it at meta, where five is a terminal level that you need to reach within 33 months. Is it?

Something like that. Yeah. Where promos and ratings are correlated, but there's not a one-to-one 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, the expectation is that you can drive your projects forward, right? That's kind of it. But as a five, you need to take more ownership of other people.

I was starting to touch on that a little bit, right, in terms of onboarding others, but I wasn't responsible for their success or the success of their projects. My behaviors didn't align with those of IC5 because I didn't take that larger responsibility in 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. I would be too.

Yeah. 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 in the next half, that was the COVID half, right? Correct. Yeah. So during that half, right, there was kind of like a star, I guess. You could get like an annotation in your performance review, right, that said like the first half of COVID, you were significantly above, which is practically equating to a GE rating. Right.

Because we didn't do any official ratings. We didn't do any promos that half, which 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 I said if I would have been on track for that. second half promo, especially knowing that I, you know, he didn't truly say that I got the annotation, right? But like, he was hinting at it. So I knew that I was doing really well. Yeah, yeah. Right. So a little bit sour on that. Obviously, our careers are long, right? So like one half isn't a big deal. But since that half was 33% of my career, right? Like,

it felt like a big loss at the time. Okay, then let's talk about the next half because you got another RE. So what happened there? 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 rating somewhat from the previous one. So it's possible. It would have been a GE, but I was probably pretty close to the line regardless. I see, I see. And you're saying 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. Yeah, yeah, yeah. But I think I was probably on the border if I would have gotten it otherwise. So I got the RE. My third half, or third half is IC4 plus the IC4 to IC5 promo. Right. And I think the important thing here is that my behaviors actually started to change. So the team, like I mentioned at the start, we were kind of pivoting between different responsibilities, right?

Now we've switched from being a bit more of an Infra team back onto product and we took on a new product space. We ended up splitting the team into two virtual teams or two teams and I took responsibility of one half of it. So for four people plus me or three people plus me, I was now responsible for going from idea, completely unscoped space to completed projects. And that was the first for me. 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. We're now no longer responsible for my own output and my own success. I'm not responsible for the project success and the people within it.

Right. And in the end, the project wasn't actually as successful, but we dealt with it really well in terms of how we behaved. We ended up having a bunch of leadership escalations up to director level, you know, with IC8s and stuff. You know, me being an IC4 at the time, I was getting a lot of credit for that communication. Why did your manager or whoever trust you as an IC4 to lead a pod of engineers? And I imagine not all those engineers were just new grads or something. So there was some identifying of you to lead that.

a little bit earlier than maybe your experience. Why do you think that is? I think as a engineer, they're kind of like two primary themes to me, where I am just good technically, right, in terms of like the diff reviews, etc. Right. We're like I just really love tech. 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 any hairy technical issues, I can help solve them, actually regardless of platform oftentimes. And number two, I love people, right? Like I really enjoy working with people, growing people, ensuring that people are successful. Obviously, when I get responsibility kind of leading this pod, right,

I am responsible for the outcome of the product, the projects. 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 of kind of helping others improve. And I believe that that was one of the big reasons why Bala was willing to kind of give me this responsibility. And I had been doing some sprint planning for a couple people before. Once again, I wasn't really responsible for their success or the project success, but I was responsible for prioritization of projects with them. 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? A couple people I was talking about career, right? But some of them was more just like high-level stuff ensuring that they're happy and they are growing on maybe the axes that they're lacking in rather than like how to get to the next level kind of thing. Right, right. Like I spot a gap and I help them fill it kind of thing. But I was mentoring about, I think, four people that have. Yeah, yeah. I think one IC3 and like three IC fours. Yeah. I remember I was an IC4 at the time. Right, right, right. 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. That's a lot. Yeah. So I was an intern manager. And my intern struggled a lot at the start actually. So one of my proudest moments actually ensuring that they got that return offer. Yeah. Because they were really struggling and kind of getting them through that, that finish line. How did you turn that around? So if I remember correctly, it was like a React project or a hack project, one or the other, right? And it was just some of the fundamentals that took longer to understand and really grok than, you know,

anticipated. Sometimes you often just need to get people over that hump and then after that they're totally fine. And I think at meta that hump can sometimes be quite high. I often see interns struggling quite a bit setting up our internal data model with ends. That can be a very big hump sometimes. It was very generous with my time. And I think that's 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 activity yes um because 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 is worth it sometimes. Yeah, yeah. But at least that way, my conscience is clear throughout, because I do care a lot about each person's success. The turnaround case, that is very impactful, taking someone, because 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 bandwidth. Yes, yes. 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

because it was eating into our dinner and like dates time, right? So, yeah. Okay, so you got the IC5 promo, double RE, and everything was kind of, you know, it all made sense. You're leading a pod. And then the last thing is, you know, growing from five to six. You did that very quickly, two halves. Kind of want to dig in. I think this one's more interesting too because the behaviors change even more.

than four to five or three to four. So, yeah, maybe you can tell me the story about the promo from five to six and we can't dig in. So it took me two halves. And if we look at just like some of the behavior issues that I had kind of like Aske up promoted to five and kind of looking forward as like what was missing for six, right? is that while I was responsible for others, I had like fully groked at, 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, et cetera.

So I was still operating a lot on like a trust model and just like hoping that everything works out. So that was a big gap in general. So kind of like as I went from five to six, and my two halves. Yeah. From four to five, I started leading one pod. My first half as a five, I started leading two pods.

Given more responsibility, I'm now leading two pods with seven people in total. So the scope is increasing for me as a result, 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 larger amount of people. as we're doing sprint planning now, previously I did it. Now instead I, you know, assign pod leads that do it for me, right? Or like for the team. Where I am involved, guiding, coaching, but I let others take that, which is another beautiful thing because now they are growing in return, right? Now they're successful and they can make it towards 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, whether it be recruiting onto the team, right, where, you know, we were still meeting with a lot of boot campers to keep growing the team. I was a different time at Meta for sure. And I can no longer do all this by myself. Right, right? Where I get a people within the team, it's like, hey, we need to coach more people. So I coach them in like how we do outreach, how we track the progress of each candidate. And then I might still do the hardest thing, which might be like that first cell call, right? Like really get them hooked.

But then I have the others kind of like take responsibility of the candidate moving forward. So unlocking that skill was a very kind of like step change for me. But still this first half, I didn't really know. how to keep others accountable for that success where things were still slipping and I didn't uncover it until way too late 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 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 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 a feedback that I received, which was scaling myself.

And it 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. 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 figure out what happened and how we can fix it ASAP.

Yeah, yeah. And that was, I'd say, pretty systematic, systematic from the time I kind of like just got to five up until kind of like my, or like at the half I got from four to five, right? Like this was a problem. My second half is a five. This was a problem. And then kind of like towards the end of my five to six journeys kind of like when that really clicked. Yeah, yeah. Because I, my second half as a five, 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. And we did. We exceeded those goals. But at the same time, we spun up a separate project, which ended up including 13 people.

So I was kind of like tealing both of these at the same time. So that really stress tested my ability to scale myself. Yeah. 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 pro one 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 roadmap of this project, right, ensuring that like we have clear milestones. Same thing with the other team where, you know, we have set the goals.

We have hypotheses for how we might hit those goals and then coaching the people to move in that direction. At the same time, you need to show that you are a skilled engineer, right? And I did this through a couple different ways. One was continued diff reviews. Throughout my career, I've always valued diff reviews, specifically high quality diff reviews. 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. Because I find that there's a strong correlation between the amount of words you write and the quality that you give in those diff reviews.

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 all the different parts of the code base and how they fit together. And you can really, you can catch issues early, right? For example, I was reviewing Android iOS server, which meant that when I saw that the Android engineer implemented something this way, the iOS engineer

implemented this way, the server engineer was trying to do it a third way. It's like, hey, guys, let's figure out, like, what's the one unified way of doing it? Right. So Differy use was one very high leverage activity in terms of technical contributions. And number two, on the big project that we had, we were getting really close to the milestone, but we were really struggling to kind of get it over that line, right? It was a payments product that crossed between IG to META's main backend stack onto the payments backend, which is in C++.

onto a third-party payments partner, right? 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 ID servers backend, onto the meta-main backend onto the C++. And I had like breakpoints all over these code bases, right?

It would just show that like I was able, able to work at a very wide span, but also just like very detailed and go deep and solve the hairiest problems that we had. You were able to hand off things, but maybe not assure their success. What was the one thing that you switched in that half where that really made the big difference and closed that gap? My manager 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 assume that this person would get it done and I hoped they would. 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 sprint meeting or something where 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. Because I find that that to be incredibly helpful where a project might be on track, right? But that project might be 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, project level you might be missing that there's someone on the team struggling 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 gonna 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 exactly stay on top of it I think in my 4 to 5 journey as I'm trying to scale myself through others I got feedback like hey Simon like take a step back I like 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 a 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 you might not even be able to review all the code anymore right you you need to trust that the other people in your team can support the different projects but you still verify through

them just maybe not micromanage exactly i'm curious after you got promoted to six because your your trajectory was so rocket shift right did you what what were you thinking in terms of career planning because 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 achieve the goal? I want, it's time for a personal life or something like that. Yeah. I mean, I was definitely, you know, hungry for more, right? And I guess I still am in some ways. Yes. But I also recognize that like in some ways it's a bit of a crossroads, right?

We're like now there's the option of management. And I guess we'll get to this. I did choose the manager route for a little bit, but I struggled a lot with that decision. My identity was definitely part of being a good engineer, right? And I was so worried about losing that. Five, ten years down the line, if I switch to management now, would I just become a middle manager that have lost all their technical abilities? And I've stopped providing value and I'm just, you know, existing, right? That was a huge concern of mine, to be honest.

Right. So in the end, I did choose the management route, but ended up switching back to IC. Yeah. So, I mean, I had a very similar exact thinking because I love 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. 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 he moved with him. Correct. Yeah. So he sounds like a great manager, so it seems worth it. Truly. Yeah. So, you know, I'm now in London. We're working together.

We're starting up a new team. So 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. because the team was seven, eight people. My manager was getting too many direct reports. And because I knew that I had my manager support and that he's been coaching me so well throughout my entire career

and I find him to be an extraordinary manager. 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 now might be the time to do it. Right, right. Having a good manager may be the best gift that someone could have

if they're very ambitious in career and wanting to grow. And you are, we're very lucky and fortunate to have such a wonderful manager. What are the things that made him special as a manager? He cared, right? He cared about people. He cared about projects. by impact. He knew the company, right?

He, I mean, by now he's been here 10 years, a bit more. So when I joined, he had probably been in the company like four-ish years. So he knew the process, you know, he knew everything, right? And he himself had had such a rocket ship trajectory within the company that he, I think, really understood what I wanted to achieve. I think the other thing that really made him stand out as an engineering manager is that he was probably more of a product person, really, which is funny because he actually just a few months back switched to a PM within

meta, right? So he was really able to set the roadmap of the team at a really great level of detail, upwards communication, downwards communication, which then let the engineers in the team once we were ready to, I guess, you know, as he had coached us, to really run with us. on the engineering front and then he kept coaching us on the product management and like data and growth front 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 from what you're trying to say, it makes such a huge difference. 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 if people are struggling to communicate clearly in spoken word. 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 why? What was the learning? What did meta or the team or the org gain from this? And I think that's one big gap 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

100, very simply. And, you know, over time, too. It's referenced again. Later, people look back on it. It's 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 five 10 seconds most make it incredibly parsable at a glance yes right the tlDR right make sure it's truly a tlDR yeah if possible include numbers right like people understand the numbers much better than you know written words truly that's like the most important thing and that should be so But in workplace, we kind of like, you know, fold the posts together, right, when they're too long. Yeah.

So ensure that TLDR is truly above the fold so that it's right there. Oh, you're talking about the Seymour. Exactly. Yeah, okay. Yeah. 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, consider the audience. Or try to write the post in different sections, target different audiences. 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 the outcome and the why and maybe the next steps. So I often do, you know, like the flashy title, TLDR with some numbers, you know, set the context and then kind of like the impact and the 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 attract the fellow nerds, right? Like get the other people that are like really interested in like the how, not just the why. 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 all this stuff of, you know, I went 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. And all of that, I mean, that only matters to maybe your one or two collaborators that knows all those details. And that happens in meetings as well. Someone's giving an update. And it's just all this stuff that, I mean, it matters, but just not to the people that are listening. What's the high level?

Is it on track or not? What was the number movement? Why should they care in like two lines? Yeah. 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 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. And to be honest, it was one of the feedback I got from the people I was managing. It's like, Simon, step away from the technical ability. 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 a 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 you've been to TL, you're now the manager, you see a gap and you're like, ooh, I really want to fill that gap.

I was really struggling there, to be honest. I got feedback on it. I don't think I fully, truly corrected in the end before I. before I ended up switching. I had some really bad luck, actually, in my manager transition. My immediate manager that had been with for such a long time ended up in an accident and had to be out of work

for like three, four months. Oh, wow. So no immediate support network there. My skip manager was on Pat leave, right? So no support there. 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. Oh, God. Okay. And this director had come back from long-term sick leave as well. So weren't like fully up to date and all that had happened. Yeah. So that was tough, right? I was given this, where I moved 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. Yeah. And I think I over promised, right? I was like, you know, maybe we can make this happen. 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. Right, right.

We do that. But then for the other person, it was hard to really slot that in, to, like, get two people from five to six at the same time and the same team of, like, eight people. Right. It's a really tough thing to do. I think it overpromised there a little bit, which is definitely a learning. A favorite transition to management again. And for,

reasons we also had to leave London and yeah ridiculous exactly so with all that there was just too much going on a lot of just like heartache and leaving London and supporting team at the same time so I got burned out a little bit as a manager just decided to move back into I see 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, 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. Just like, all right, I tried it. Incredibly poor timing. Let me just like take a break from it for a bit. Go back to what I know. Just like get back

into the previous groove. And, you know, I'm totally open to management. Yeah, yeah. Not yet, though. I think I want another three to five years. I actually think that I see six is a great level of metal. Right. Specifically when it comes to like 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 inch work, spend a lot of time like mentoring and coaching others. And that like mentoring and coaching becomes a bit more of a bonus, right, in terms of like my performance evaluation. Right, right, right. Compared to my 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.

So I find that as an I see that enjoys people stuff, actually have way more flexibility in how I apply that people. people stuff. As a manager, you take on responsibility for everyone and it's an unconditional support. As an IC, you kind of pick your project, you're creating scope as IC6. So you kind of create scope that you want to work on and you are helping the people you want to help. I mean, not fully. There's still some stuff where you need to take responsibility. But there is a lot more optionality. That makes a lot of sense. And you got burned out not specifically because of management, but the circumstances around it was just really tough. I think I probably would have stuck with it if the circumstances had been better. I might have still switched back to IC. 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, I think you had mentioned that you received DE once or twice throughout your journey and DE stands for discretionary equity I think it's called AE in some cases to like additional equity what what is that how does it work maybe you could tell us about your experience yeah additional equity is when a director chooses to give you more R's use right more stock options this happened twice in my career first time around was in my five to six promo where I got I got a random 15 minutes calendar slot on my calendar one day.

I, with the director, I show up. He's there and he's like, Simon, do you know why we have this meeting? I have no idea. He's like, oh, no. And he told me, you know, like, hey, yeah, like, we decided to give you discretionary equity, which, you know, I had heard about because I'd been the company for like three years now, but once again, I was pretty, like, naive and new. and like I didn't really know what to expect.

Yeah, yeah. Sometimes you go into kind of like the internal compensation group where like people post about their success. And it's a huge selection bias about who posts in there. Right. It's usually the people that get great ratings that get A.E. So obviously I'd seen a bunch of those posts. I was like, okay, like, all right, great.

That happens, right? Yeah, yeah. So, like, I was incredibly humbled, right? And like, it felt really good. But I didn't really understand it really. Yeah, right. But I guess I, you know, I got in great ratings throughout. And since I started as an IC3, I assume that maybe they were worried about some attrition,

given that my stock options when I started, probably quite a bit lower compared to what it would be for an IC6. I see. So that first DE was, it wasn't game changing. It just kind of gave you maybe a little bit more than market. Is that right? Yeah, I believe so. 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.

That was actually similar with the second AE that I got a year later. So I've been IC6 for a year. I guess I just transitioned to management. And I ended up getting my second AE. I believe it's primarily due to the success of the team I took over. So I moved to London, right? I took over part of the team. We shipped a product in a much faster timeline.

then anticipated, right? And it was a company priority, as so many things are at the company. But we executed well and we got it done, right? So I think that the success of that and the behaviors I showed were a large part is why I got that second AE. And I'd 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 15-minute, no agenda meeting.

from some senior director you never talked to. What did you think when you saw that on your calendar? I don't even know, man. Like, it's, I honestly had no idea what to expect. I was a little sweaty going in. I was like, all right, what's going to happen here? Yeah, yeah. Turns out it was a good one.

Yeah, yeah. Yeah, I have a friend who, you know, this is happening here, and he's like, I think I'm going to get fired. It's like you never get a meeting like that. So you mentioned 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 80, 20 tips that 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 the interns, right? So I was an intern to start. And honestly, I didn't do very well. I think it was very close to not getting an offer. Luckily, I'm here today because I did get the offer. But I think that I, didn't do that well and I think maybe we'll cover that but then I was an intern twice first time around I had an intern that like I mentioned went from kind of meets most expectations to actually meeting and getting a return offer sick and and that at the same time I was a peer intern to four interns the second time around I had an intern rock star intern right we had a couple new hire IC3s at

the same time and my intern was coaching the IC3s wow yeah How's that? He was just so good at JavaScript, so good at React. Yeah. He blew through everything and was like coaching the others and like, this is how you do it. What university? He was over in Mexico. Okay.

Yeah, it's interesting. And I asked, by the way, because I had a lot of interns as well. And I noticed the ones that come from Waterloo were just like. The Waterloo ones are great. They came in and they're like an icy forum. I'm like, you know how to do everything already. Yeah. Then I had two summer, or I guess,

one winter and one summer that 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 project plan. And then you do three check-ins with the intern managers. You do a three-week check-in, making sure that the interns ramping up all right. You do the midpoint checking to make sure are things on track for the project. And then the final check-in where, you know, ahead of the final review. So it's on to your question of like what are some of the the things that stand out between really solid interns maybe interns 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 like a fail by itself. Obviously, there are safeguards to see, like, was the project just, like, completely miscoped, right? But hopefully throughout the process, that's been, like, corrected already. 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, right. Like it's the most valuable time that you have because the expectation of you are practically zero. So you can ask people however much you want. And this is something that I kept repeating to interns I had as well as like I see three'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 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 it will really help your velocity and another thing here is that the intern program meta is set up that you have your interim manager and then you have usually two peers but

sometimes more also do take advantage of your peers for two reasons one reason is maybe you're asking too many questions your managers just can't deal with them all right so maybe you have a chat group with you know your interim manager plus peers make sure you can ask questions in there they can kind of like load balance between themselves right 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. And sometimes when there's insufficient amount of evidence of, you know, the right behaviors and such, then intern managers, intern directors, we need to go in, do a lot of digging 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 that makes everything much, much easier, and they can vouch for you much better. You've 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 barely meeting expectations, but you're working crazy hours, then, you know, you might get penalized or something. Do you have any thoughts 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 6am but also 3 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. And I'd say it's primarily an indicator when they're just around that line. But the other thing is that not just for interns, right, but just like 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 journal every day, right? I make sure that like I have my focus time in the morning where I can like do focus work instead of just like being stuck in meetings. And like these rituals are something that like ensures that I function effectively. And obviously I've had times where like specifically actually between five to six, 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. But 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.

But to reach a specific milestones at times could be one way of achieving that. In your ambitious growth, you had points where you're sprinting, but you knew your steady state was. was never a ridiculous health sacrificing kind of grind. What is that peak steady state that you've learned you can maintain, like maybe an hour's per week? I probably average like 50 hours a week-ish. Like, I'm a morning person, so I wake up, I have my coffee, walk the dog, work out, and then I maybe start work.

And then some days, maybe that's like 7.30, 8 o'clock. And maybe I end up working to like 6 p.m. because I need to have meetings with like California. Right, right, right. So some days are longer, some days are shorter. I also just like really enjoy what I do 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 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's a huge company and they're also very flexible about internal mobility so I was able to switch to a new team and an infra team and 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 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 somewhat

tied to your interest and motivation in the work. Like it 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. 100%. I see. Yeah. 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.

Because if you love it, then it's not really. I mean, that's cliche, but, you know, it does not feel like so much work. So, you know, 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 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 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 mono repo. Just like read the code, read the divs, why did they add it? Like what's the reasoning?

Can we change it? Like come up with a brief proposal, right? And like research your questions or just like approach ahead of time to be able to move forward. That kind of curiosity slash ownership slash, you know, not accepting. being blocked 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 it's 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. I imagine it even continues further. If you were like ICA, I care about what these 300 people are doing and that it's successful. 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,

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? But you can totally get to IC5 without like being able to be like the, the, the true, I can solve any problem throw in my way kind of person. Yeah, yeah. Like, if you can get your stuff done and, like, your overall contributions of, like,

chatting with the designer, pulling the data, you know, 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. So it sounds like technical skills. need it 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 yeah so like there are obviously the edge case is 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 entire career at this point, which in this industry is unusual. What is the thing that's kept you at META for so long? A bit of a cop-out answer, but people is definitely a big part of it, right? Like I do really love the people at META, my manager, obviously, right?

but also my coworkers, right? And I think this was especially true, actually, in my first team, right? Where I joined the second engineer. We ended up growing the team to like 16 people before we split into two, right? And since I was a large part of recruiting there, honestly, like it felt like a bit of a family, right? Like it was a really happy, supportive environment. To be honest, a lot of people who hired were also like straight out of college. Like it was a very young, fun thing, especially since I was just a really happy,

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 coworkers. 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. People are just really good technically too. Right. So people is definitely like one big part, right, why I'm staying at Meta. Right. 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 California. So I worked in Menlo Park to start, which is the HQ.

During COVID, it was down in LA. I went back to SF, you know, did a year in London, came back this time to New York. So just like that flexibility in terms of like global location has been really great. Right. But also like internal projects. Obviously, my first team was actually quite a bit of forced movement in terms of what to be focused on. But now, like I mentioned, I was losing my drive. The hour is starting to feel like a real drag, a real slug.

And I figured, you know, like, I need to change something up. I did consider going elsewhere, but I figured, let's give meta another shot, right? And I'm like, see what's up. And I joined this new team in the IG server infraspace. And it's been great. Like, once again, people are great. I'm learning so much. I can go incredibly deep technically, which is something that I love nerding out about.

A lot of those checkboxes as to like what makes me tick just like keep appearing within meta. And thus I don't have like a strong drive to seek elsewhere. Which, you know, might change in the future. I find that there are some things you just can't experience at meta. But I haven't reached a point yet. Yeah, that makes sense. There was someone that I worked. with who was exceptionally senior you know everything was going well and meta and I was thinking 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 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 productivity, start asking these questions, right? Like, why was this done this way within the codes? Become a bit of like an 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. Kind of like question those earlier decisions because especially at a big company like

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 dead experiments lying around the code base and like maybe you can just like clean that up that would make your things easier take ownership be curious and nothing else's problem okay well thanks for the interview is there anyone you wanted to shout out before we end yes I promised Chris that is covering my on-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 interview, Simon. I was really looking forward to it. Someone that had worked with you said you were one of their favorite people that they've ever worked with.

So thanks for giving to the community. Appreciate it. Yeah. All right. Thank you very much, Ryan. Hey, thanks for watching the 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 interviews. So if anyone comes up who you think you really want to hear their career story, 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.