Pod Insights The Peterman Pod Instagram Senior Staff Eng (IC7) On 3 Promos Through Redefining Expectations (Career Story) About this episode Marius Schulz grew to a Senior Staff Engineer (IC7) at Instagram by redefining expectations three times (once for each promotion). We talked through each promotion and how he did it. There were also interesting learnings from when his promotion got blocked once even though he greatly exceeded expectations.
𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:
• Transcript: https://www.developing.dev/p/instagram-senior-staff-eng-ic7-on
• YouTube: https://youtu.be/OXJHfb_lZII
• Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835
𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:
00:00 - Intro
00:55 - Choosing his specialty
02:29 - Greatly exceeding expectations with no promo
08:04 - Senior promo
15:30 - Staff promo
24:43 - Leverage and IC4/5/6 way of solving problems
29:51 - Senior staff promo
44:29 - Career planning past IC7
47:32 - Did IC7+ expectations scare him
49:49 - Advice for his younger self
52:29 - Outro
𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗠𝗮𝗿𝗶𝘂𝘀:
• LinkedIn: https://www.linkedin.com/in/mariusschulz/
• X/Twitter: https://x.com/mariusschulz/
• Threads: https://www.threads.com/@marius.schulz
• Personal Website: https://mariusschulz.com/
𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:
• 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
• TikTok: https://www.tiktok.com/@ryanlpeterman
Transcript 10,565 words · 2 speakers
Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
0:00 Speaker 00 And I knew for a fact with certainty that I never ever wanted to consider IC7. And here we are.
0:05 Ryan Peterman? This is Marius Schulz. He grew to a senior staff engineer or IC7 at Meta by redefining expectations three times. And he shared everything he learned along the way.
0:15 Speaker 00 There's an IC4, IC5, and IC6, and maybe even higher, way to go about almost any problem. You got another redefines expectations rating, promo to IC7. The year that Red's launched, I think I came up just under 2,000 TIFs at the end of the year. For a year.
0:32 Ryan Peterman? He also opened up about what held his career back.
0:35 Speaker 00 Why was there no promotion in the greatly exceeds case? I think at the end of the day, it came down to one expectations miss that blocked the promo. Have the expectations of the highest levels ever scared you?
0:49 Ryan Peterman? Here's the full episode.
0:55 Speaker 00 You chose a specialty of like being a front-end engineer, like, well, what's the thinking there? I have this burning passion for the web, as corny as that sounds. I don't know where it comes from. I just know that I've always had it. And most people who've worked with me have probably seen that, yeah, working with me over the years. I've always been a fan of web development. I've always enjoyed doing it. And I've been doing it for a long time at this point. I started getting into web development in school, I believe it was in ninth grade, when we started learning, you know, HTML basics. And this generation, these days, might not remember what the world looked like back then.
1:36 Speaker 00 But, you know, we had HTML that was not what it is today, nowhere near as powerful. But even then, I got hooked very, very quickly. And I just, anecdotally, I remember fondly asking for a CSS book for Christmas. My grandma had absolutely no idea what in the world CSS is. But she gave me that little book. And I finished reading that on Christmas Eve before I even went to sleep. That was one of my moments where I really got hooked. Little Boxes, it's called, very, very good CSS book. And since then, I've always wanted to work on the web. Deliberately sought out, you know, jobs where I could work on the web.
2:18 Speaker 00 And yeah, I worked at a small agency in Munich while I was studying computer science and worked as a software engineer, again, doing web work, building web applications for our clients.
2:29 Ryan Peterman? When we talk about your growth from IC4 to IC5, I see that you you only killed it. I mean, you did EE, so you exceeded expectations. You greatly exceeded, you greatly exceeded. And then you got promoted when you redefined expectations. I'm curious, like, why was there no promotion in the greatly exceeds case? And what's the story behind that?
2:53 Speaker 00 Yeah, I think this is something that I've spent a lot of time thinking about back then when I didn't get the promo in the half that I hoped I was gonna get it. I think at the end of the day, it came down to to one expectations miss that at the end of the day blocked the promo. So I think this was seen as as important enough so that the room felt like we wanted to wait another another half. To see that point addressed was something around cross-functional collaboration at the time. I think I was a I was a little too pushy and too forward and maybe a little bit too insistent with some of my ideas that I felt like this burning conviction was something we should be doing. But this is not how you how you should go about getting your ideas prioritized. I think it's it's totally fine to suggest things.
3:38 Speaker 00 It's fine to advocate for them vociferously, but at some point, you can't overdo it, you know, there's a there's a balance to be struck. And I think I I was a little bit too intense there.
3:49 Ryan Peterman? You were greatly exceeding because you were landing all this stuff and you were a machine in terms of the impact you were having on the projects. But you're saying there was some concrete feedback from maybe a partner or something like that that said it was like a ding on your your performance.
4:08 Speaker 00 Essentially, yeah. And if you think about it, the two are not contradictory because, as you know, as a manager, ratings are about the impact that you have delivered. So you look back at the half, the six-month period, like it was back then before we we went to annual performance cycles. You look at those six months and you determine what impact you've landed. And you can land a lot of impact and you can do a lot of good work. But promotions, especially lagging promotions, are about behaviors. Are you already exhibiting all of the next level's behaviors? And if there's a gap between what's expected at next level, well, that means you're not ready for a promotion in this cycle and we can re-attempt a promotion attempt, you know? Next cycle.
4:48 Speaker 00 And that was the reason that I think I didn't get my my five promo during that that greatly exceeds half. Obviously, I hoped I was gonna get it, as I'm sure everybody does. It was a it was a bit of a weird one, because the next half where I was thinking, okay, now now I'm gonna get it, was the COVID half. And during the COVID half, the company as a whole did not promote anyone. Because it was a weird environment. It was the the early days of the pandemic. Yeah, for reasons decided by people and, you know, I wasn't part of these conversations. We didn't do any promos, so I also didn't get my five promo until the end of 2020.
5:25 Ryan Peterman? So as such a high performer, how'd you feel, I mean, getting a great lead and then no promo? And then also the block too?
5:33 Speaker 00 I mean, it can be frustrating, right? Just to be fully honest, of course, it can be frustrating. When you feel like you were so close to getting it, you have or I have worked hard on addressing the feedback. I think I've really taken that to heart. And I've gotten lots and lots of positive peer feedback, saying that it was a very clear change in behavior, much more the way that we we think, you know, we should collaborate between engineering and and other functions. And you've addressed all these things. You kept delivering impact. So you did strictly more and addressed everything. And then comes this company-wide unconditional blocker? That's decided, I don't know, like 11 levels above my pay grade? What do you want to do? You know, um, yeah, it was it was frustrating. But at the end of the day, our careers are long.
6:15 Speaker 00 So this one half difference really doesn't make a big difference. I think the one thing I did tell myself, though, is that even though I didn't get this promotion at the time, although I really wanted it, that I didn't want that to inhibit my learning or my growth as an engineer. So even though I still wasn't an IC5 by the end of the first half in 2020, I was taking on work that was clearly above the IC4 level. And at the end of the year, when we when I got my my PSC, that was recognized fully. So it all worked out in the end. Maybe took a half longer than I initially had hoped.
6:50 Ryan Peterman? I lived that same experience as well. I was hoping for a promotion and then it got blocked. But I think that that mindset is helpful and productive. Even, you know, COVID is one thing, but people's promos get blocked for a variety of reasons. But there's no reason on paper why you can't think about the future or your growth.
7:12 Speaker 00 Exactly.
7:12 Ryan Peterman? So if you're an IC4 who's obviously doing IC5 things, but you know, your promotion gets blocked because of, let's say, budgets or something out of your control.
7:22 Speaker 00 Right.
7:23 Ryan Peterman? You can think about what's the IC6 thing to do. And that will just give you a sense of progress still and like something to achieve. And it's just all on paper. The promotion is not a big deal.
7:35 Speaker 00 Well, and I would argue you almost have to do this or you really should be doing this. Because you can't be defeatist and you can't take the stance that, oh, okay, well, I didn't get this promo now, so I'm gonna just be an IC4 then and no longer exhibit the behaviors that I need to demonstrate at IC5. And then only when they make me an IC5 will I do that. That's not how lagging promotions work.
7:57 Ryan Peterman? Right.
7:58 Speaker 00 You know, you get promoted once you have, for a sufficient period of time, demonstrated next level behaviors, next level impact.
8:04 Ryan Peterman? After the COVID half, you got the redefines expectations rating and the promo. I'm curious, like, what is the story behind the thing you landed?
8:12 Speaker 00 Yeah, I think at the highest level, it came down to me taking on or taking a leading role on a project that has been clearly classified as an IC6 level project as an IC4 and landing that work successfully. So in a way, that is not even the next level's expectations and next level scope, but that was the next, next level that we were looking at. It was a really big web project that was very front-end heavy, so right up my alley, if you will. But it involved way more people than just myself. This was a project that had, I don't know, like more than 10 people, more than 10 engineers contributing to it and then other partners, like product managers and designers and all the other roles that you find in product teams usually.
8:53 Speaker 00 And for an IC4, I think that was, that was going above and beyond what is expected at IC4. These different granularities or these different sizes, these different scopes that you should be looking after. And you you gradually work your way up from a task level to maybe a small project level, a larger project level, something influencing the org, influencing the an entire system, the company, the industry. So you work your way up from like three to eight. Yeah, I got recognized for this effort because it it clearly was more than what was expected of a four. We delivered all of this on an ambitious timeline, working through what was a weird environment.
9:33 Speaker 00 Again, it was the early pandemic and then, you know, the summer of twenty twenty, end of twenty twenty. And we launched without any major issues. So at the end of the day, all of that also still matters. So you still need to demonstrate all of this operational excellence when you when you work on these projects, right? It's not enough to write a lot of code and say it's done. And then you you pull the trigger on launch day and you just cause a giant incident and and break all the systems. You're not going to get a pat on the shoulder for that. So there's still release hygiene that needs to be observed. But it isn't just engineering, and I want to be really clear about this. It isn't just engineering when you talk about an IC six project. There's usually ambiguity in some form that could be in the product space where it's not entirely clear
10:18 Speaker 00 what needs to happen or what the the target outcome looks like. There's people problems that you run into. You need to coordinate, you know, five, ten, fifteen, however many people contributing. Somebody needs to hold that show together and divide work streams, make sure everything's on track, run the weekly operational meeting, report sideways and upwards and and all that that stuff as well. And yeah, I think at the end of the the year when my case was being discussed, I think it must have been pretty clear that this wasn't an IC four level performance. I can I can really only speculate. I don't know if this is how we look at what differentiates maybe like an exceeds from a greatly exceeds or greatly exceeds from a redefines. But there is something there about, okay, if you're doing the next next levels work,
10:59 Speaker 00 you're not meeting or probably not even exceeding expectations, you must be above that.
11:04 Ryan Peterman? Right.
11:04 Speaker 00 Because it's so far outside of what's what's expected at at IC four.
11:09 Ryan Peterman? Yeah, I mean intuitively that makes sense because if you were in IC4 doing IC5 stuff, definitely going to be exceeding, but then what's IC6? What if you did IC7 for a project?
11:19 Speaker 00 Right, IC4. And it feels a weird to talk about this because I feel like I'm tooting my own horn here quite a lot, but it's, I'm not trying to do that. I think it's more about here's what's expected and then if you really go above and beyond, this is what gets you to an exceeds. I think we call that ladder-ing in these calibration conversations where you can clearly explain, okay, this is the work that this engineer did to get to their meets all, but then on top of that, they did this and we think this now warrants an exceeds. And you can ladder your way up and you can articulate why this rating is possibly justified so that other people can understand.
11:55 Ryan Peterman? You mentioned you were in IC4 trusted with the IC6 project. That's kind of interesting to me because a lot of people, you know, when you talk about a promo and part of it is delivering on something that is deserving of a promo, but the other big part is getting the opportunity to do something that's worthy of a promo.
12:14 Speaker 00 Right.
12:15 Ryan Peterman? What's the story behind you getting either assigned to that project or creating that scope?
12:20 Speaker 00 Yeah, it's a great question. My entire team catalog at the time was working on this really, really big priority that had come up, I want to say quite suddenly in 2020. And a lot of people changed what they worked on at the time. And you know, we have a healthy level spread in the team. Engineers taking on level appropriate work. But one, one of the senior engineers on the team was out on paternity leave at the time. So he in a way left a gap that needed to be filled. So the engineer who would have probably been trusted with the project that ended up coming to me had to fill that spot and he was one level or even two levels higher than me at the time.
13:04 Speaker 00 Then I was, in a way, it was a bit of a domino effect, where there was a bit of a vacuum that needed to be filled. And everybody, in a way, took on N plus one work, if you will. And this is how I ended up with this project. Obviously, it's not like managers sit in a room and then they roll the dice. And that's, you know, whoever gets the project, this is not how it works. Obviously, there's a bit of luck that's always involved in getting matched with the right opportunity. But I firmly believe that you can increase your luck surface area, so to speak, by doing the right things. So if you position yourself as, in my case, a web person who wants to be the web platform lead in my area, you know, on my team, or whatever the scope was at the time. And then there's a big web project coming up.
13:49 Speaker 00 Well, okay, they're certainly going to consider me. Doesn't mean I'm automatically going to get it, but at least I'll hopefully be in consideration, unless it's like way above what I can handle.
13:59 Ryan Peterman? You had been greatly exceeding expectations before. So, you know, the manager, whoever's in charge of figuring out how to staff that, they looked around and, I mean, web, you know, subject matter expert, greatly exceeding, hungry to take on more. Okay, let's give it to that guy. And, I mean, it worked out, you crushed it, so.
14:21 Speaker 00 Very hungry. Very hungry.
14:24 Ryan Peterman? Is that something that's been true throughout your career? You've been quite ambitious, or?
14:29 Speaker 00 Yeah, pretty much since the very beginning. At some point, when I, I think I vividly still remember the day that I really got hooked. I think it was like something that clicked in my head when I was learning JavaScript and I understood if statements and loops deeply, properly. Something in me just went like, oh my God, I am going to be like a demigod. I can do whatever I want to do. The machine is at my disposal and I I control it. There was like this this feeling.
15:01 Ryan Peterman? Right.
15:01 Speaker 00 And then, as I mentioned before, I've always had this interest in the web, just because I feel like it's. I I look at it and I think it's a beautiful invention, you know, this initially, this set of connected documents that shares the world's knowledge, you know, you carry around this mobile supercomputer in your pocket and all you have to do is pull up Wikipedia and you have this incredible source of information available with these beautiful blue links that you can click to go to the next page. And I just think there's something philosophically beautiful about that.
15:29 Ryan Peterman? After you got from the IC five, your career trajectory actually went even faster. Like, when I look, if I were to plot it, it'd be like a little bit of a hockey stick. You were at IC four for a while, written good ratings, and then you you jumped, and you jumped, and you jumped. I'm curious about the story behind the IC six promo, it's another redefines expectations rating, which is even harder, like, you know, I could redefine expectations as an IC three right now. You know, doing it as a IC five, IC six, it's starting to get a lot crazier. So what was the story behind the IC six promo?
16:05 Speaker 00 It always comes down in some way, shape or form to the impact that you land. Impact can come in many different forms, depends on the team you're on, it depends on the type of work that you do. Right. But at the end of the day, you have to have delivered a lot of impact. As an IC five, I was working on a project, which I think was part of the part of the reason that I got the the six promo, that had a lot of, again, time pressure behind it. I think we're we're on to a little bit of a theme here, where it was, again, another web project with a very tight, very aggressive timeline. And in this specific case, there was a hard deadline, because this project was part of a bigger investment area, part of a bigger puzzle, and had that piece not landed, other pieces couldn't have landed either.
16:51 Speaker 00 That impact could not have materialized. So there's a lot of pressure, because you need to really deliver that, come what may. There are a few things that you can influence, or a few things that you can change, a few variables, a few knobs. And what are those usually, right? Like, what do you do when there's a project that needs to get done quickly? You can add more people to it, and sometimes that does speed up the project to a degree, not always. You can try and cut scope, so you just try and do less. You can lower the quality bar and be happy with something that's less high quality, scrappier, not as well done. Or you can give yourself more time. Usually you can't do all of the above, right? We couldn't add time. It was a hard deadline. Adding people wasn't an option because we already had, everybody was already allocated to a high priority area.
17:36 Speaker 00 I had a handful of other people working with me on this, but this was it. So at this point, you're trying to manage carefully and tastefully scope and quality. And you don't want to reduce whatever you're delivering to just this absolutely minimum MVP that has, you know, it was like a shadow of what it should be. And you don't want to lower the quality bar too much. I mean, sometimes you have to make a concession or two, right? But I personally always try to keep the quality bar very high. I would much rather cut back a bit of scope, but make sure that whatever we do ship, we ship well. Performance, reliability and design craft and everything that goes into the quality bucket. And we did that with this project, again, on this short timeline, delivered this project.
18:21 Speaker 00 And I think the specific call out there was actually rereading my, um, my feedback that I got for this half this morning, just to remind myself. The specific feedback for me there was that there was a high amount of ambiguity and everybody at the time was super stretched. So there wasn't, uh, there was PM support, product manager support, but not full time, not as much as we, we needed it. And there were questions to be answered and questions to be answered quickly because otherwise for sure, we would have missed that timeline. So I got a lot of credit for flexing into that product hybrid role, that product hybrid archetype I was mentioning. And, um, what that means specifically is you have this fog of war situation. If you've ever played Age of Empires, you know, you start in the middle of the map and around you, there's just like the black void. You need to go explore.
19:07 Speaker 00 And we had that fog of war. We needed to figure out what we wanted to do. What needed to get done, scope that out clearly, get alignment with product management, engineering management, make sure that other people are bought in and are happy about that. And then, once that is decided, at some point, it becomes a bit more operational. And then it becomes about, okay, how do we sequence the work? How do we, how do we measure success? So when do we know that we're done? What is good enough, what isn't good enough? And then, at the lowest level, it comes down to, you know, assigning work to people, flashing out these work streams, and then taking off the product hybrid hat, putting on the coding machine hat, putting on headphones, and going to town.
19:49 Ryan Peterman? Coming off of such a high, you, you actually switched teams. I wouldn't have expected like a team switch when everything's going so well. So why, what's the story behind transitioning to IG Web right after that and why?
20:02 Speaker 00 I think it comes down to changing, changing directions, I guess, or changing priorities, rather, on my wider team. I had realized over, over my first, what was it at that point? Two, two and a half years at the company? No, it's longer, almost, almost four years at the company. That I really enjoyed working on these web projects and that I really enjoyed working on anything related to quality. I alluded to this earlier, but work like performance, liability, delight and craft when it comes to the design aspects of things. And it didn't, that didn't fully align with the priorities that were coming in at the time. Web just wasn't part of the, the big priority.
20:44 Speaker 00 We were shifting and looking at other things in my wider team. So it didn't feel like this was the environment I should place myself in if I wanted to further pursue a career in that direction, right? I was kind of, yeah, pretty deliberately working towards being this web expert. That's how I wanted to, to shape my, my career, right? Because there's many different directions you can go in. You can, can push to become a generalist, you can push to become a specialist, you can, at some point, want to become a TL, an Uber TL, maybe explore management. But for me, it was, I want to be a web subject matter expert and just build the best web tools that I know how to build. And at the time, Jake, actually, who I believe you've had on the podcast before,
21:28 Speaker 00 was hiring engineers onto the Instagram web team. And I saw that vacancy and jumped onto it. Met him over VC, talked about the team, talked about what work was coming up on Instagram web. And low and behold, it was fully aligned with all of the things I just mentioned. They had just done a big migration project, changed tech stacks in a way. And there was a lot of quality work falling out of that. And I had expertise in this area. I loved the web. And Instagram is a great org to work in. So I felt like this is almost too good to be true. Had the conversations with the engineering hiring managers. But yeah, ended up joining the team and kind of continued on that trajectory on Instagram web.
22:13 Speaker 00 So at the time, we were doing work on many different surfaces on Instagram web. I picked one when I joined that wasn't taken yet at the time, which was notifications. So if you know the sidebar that you have on Instagram web, there's the notifications panel. That slides out, that shows your, you know, who liked your posts and whatnot. And I worked on that, basically fully rewrote that. Because that code hadn't been touched in many years, hadn't evolved in a lot of, a lot of the code was just getting really, really old and out of sync with the native apps as well. And landed all sorts of, of changes there that were very, very gratifying to me, if you will. I worked on that and I felt so proud of the work I was doing. I was so happy that this was what the team wanted.
22:55 Speaker 00 They wanted somebody who, who cared a lot about UI craft. Design craft is valued a lot in Instagram. And yeah, then worked on Instagram web for, I want to say about a year, doing various quality related things. I mentioned the notifications panel that I worked on. But this was, I think, the, the main product change that I landed. Most of my work actually was in the product infra or client infra space, as we call it. So it's not quite an infra level job. So it's not like, you know, a true infra team's ownership. But product infra sits in between product and infra, as the name suggests. So it's basically, a lot of it is when you think about Instagram web, basically what is the
23:38 Speaker 00 architecture of the website that we use to structure the code so that everybody who's building on Instagram web can be productive, can iterate quickly, can iterate with confidence. That means there's the right level of safeguards, type checking, tests, right, manual and automated, what have you. And this is a space that I have always been interested in because it's a very leveraged area to work in. And I also think the more senior you get, the more you need to look for these leveraged areas that you can work in. Because at some point, it becomes, even if you're a coding machine, it becomes quite hard to deliver strong IC5, strong IC6, strong IC7 level product impact. Because what does that even mean? Like, what
24:19 Speaker 00 is, what is an, you know, an IC7 product impact? Quite high, the expectations. So I found this product infra space to be an area that I find super interesting. And conversely, there's many engineers, especially the very product focused ones, who don't find it that interesting, who would much rather do the, the actual product work, if you will. But yeah, I've spent a lot of time improving our, our systems there.
24:43 Ryan Peterman? So you mentioned leveraged. I think that's a really interesting concept. Can you explain the, the idea of what you mean by leveraged?
24:51 Speaker 00 Yeah. We talk about this a lot on our infra teams, I think, when we talk about the pit of success. What is the right set of defaults or the right architecture that you can put in place? So that somebody who is, you know, bright and well intentioned, but maybe doesn't have expertise in this area yet, or maybe doesn't have a lot of experience working on the surface, comes in and hopefully just does the right thing. Because the framework encourages the right way of building products, or the right tools are in place to help with testing, whatnot. One specific thing that, that I did early on when I joined the Instagram web team was To test the reliability of the site, specifically on the front end. So I'm not talking about the backend now. I'm talking specifically about the front end.
25:34 Speaker 00 So in React, we have this concept called error boundaries, which you can imagine are like try catch statements about specific pieces of the UI. So you can basically fence a certain area of the UI. And you can say if there's any rendering errors happening in this area, render this fallback state when that happens. And the way I picture rendering errors happening, when an error gets thrown, it's almost like a little grenade that detonates. And now the question is, how aggressive is the blast radius? How big is the blast radius? When there's a little rendering error somewhere on the side, in some area that isn't like super important for the page, are you really happy like blowing up the entire page and just showing like, oops, something went wrong and taking down Instagram web? Probably not. You probably want to fence that.
26:18 Speaker 00 So I went in and had a lot of fun just opening the developer tools, clicking around different areas. And we can trigger these errors in any component we like just to feel out like what would happen. Yeah, this is the reliability effort. You can like argue that this is maybe more like IC4, IC5 level work at this point. But as one of my previous managers said to me, usually there's an IC4, IC5 and IC6, and maybe even higher way to go about almost any problem. And in this case, you can obviously just add one error boundary in one place and call it done. At that point, you're probably doing more IC4 style work. Or you can do this work systematically, where you audit the entire site. You do this in all places. You solve the problem comprehensively.
27:03 Speaker 00 You dedicate, I don't know, like a day or two or something like that to it. Maybe bring in one or two additional people. And you just harden the entire site against these errors, even if they're not happening today. That I say, I would say is more the IC5 level expectation. But then you want to push that further because when you're IC6. You can either be a successful IC6 as a coding machine by just doing an ungodly amount of IC5 work, or you do IC6 level complexity, you take on IC6 level complexity. And you can probably tell, I have a lot of opinions on this topic. I think this is very important to build reliable user interfaces. I spent some time writing everything down, everything that I'm telling you right now, I spent some time writing that down in a big note that we can share internally, teaching people about everything that I just said,
27:47 Speaker 00 about like, here's how you open the developer tools, and here's how you trigger an error in a random place. And then I also took some time to try and classify these errors and say, okay, what is the primary information on a screen, what is secondary, and what is tertiary? And what do you want to do in each case? So how do you want to handle a primary piece of information missing because of an error, a secondary piece of information missing, and a tertiary one missing? And I think that way you can have a lot of impact through setting direction. And suddenly, me spending this time helps the entire company. Anybody reading this note can now apply this to their own products that have nothing to do at all with Instagram Web. And now you can see how we go from four-level impact to five-level impact to six-level impact.
28:31 Ryan Peterman? If I'm understanding correctly, that's where the leverage was in the IC6 example, was that you empowered others to do useful work on your behalf. They can go on and either prevent those issues from coming up in the future, or fixing them themselves. And if you did that for 100 engineers, then it's just faster than you could have done it yourself.
28:56 Speaker 00 Right, and it's scaled, right? I cannot possibly be expected to know all of the web products in the company and go in myself and work on a product that doesn't even fall in my org. But there's other things you can do. And just to complete this example, you can think of adding lint rules to your codebase, so that if you have a specific anti-pattern that you can identify, you can tell engineers right in their IDE before they even submit their diff, tell them right in the editor, like, hey, you're doing something. We didn't find an error boundary that protects you from bad breakage. You probably might want to add one here.
29:29 Ryan Peterman? I see. So then in this case, the tool is doing useful work on your behalf, and it's helping you scale, and that's expected of IC6.
29:36 Speaker 00 Right. And then I would say this problem is solved sufficiently well that I don't need to keep dedicating my time to it. I can move on to the next thing. And maybe now that we've talked about reliability, right, I can start focusing on performance next. Or something like that.
29:51 Ryan Peterman? Going back to your career story, it sounds like you came on to IG Web. Super great, like intrinsic motivation fit. Like you, it's exactly the problems you want to solve. Great team, great culture. And your performance showed as well. You were greatly exceeding even with the team switch, which you know, usually causes some thrash. And then I saw that you started to work on Threads Web. And you know, I'm just so curious about all the stories behind that. So, hey, how did you start working on Threads? So it's a story there.
30:21 Speaker 00 Threads Web has been such an amazing journey, honestly. I'm not paid to say that. It's just genuinely been one of the most exciting.
30:29 Ryan Peterman? So you're paid to?
30:30 Speaker 00 Well, I'm paid to work on it, but I'm not paid to sit on the podcast and tell everybody how great it was.
30:35 Ryan Peterman? Right, right.
30:37 Speaker 00 But seriously, it's been a bit of a roller coaster in some way because it was an intense period of time. But I look back at the time that I spent on Threads Web with the other engineers working, working on Threads Web. And I think collectively, this is up until this point at least, the best work we have done in, in our careers. And again, I don't say this to try and brag about it. It's just, it's been such a unique environment to see a zero to one app launch, to be there from, in my case, almost the very beginning. I got involved a few weeks after the project had gotten kicked off. It was all very secretive internally at the time. It's just something that you don't get to do statistically when you join a company like Meta. You know, we don't create these new family of apps, as we call them, apps almost ever.
31:22 Speaker 00 We try different things, we create new products over the years.
31:25 Ryan Peterman? How'd you get recruited to the Threads team?
31:27 Speaker 00 It was my manager reaching out to me and suggesting that, hey, there's this kind of hush, hush project going on. A small group of people is trying something. I don't know a whole lot about it, but I'm happy to connect you if you're interested. I was interested, at least wanted to hear what this is all about. Got connected to the, the hiring manager on Threads, who ended up being my, my manager when I fully joined afterwards. And we talked about what was required. Initially, the scope was quite small that we thought about for Web, for Threads Web. I later helped grow that into more scope. Initially, it was all. All relatively confined, relatively small, I would say. But yeah, I got involved and got started working as the only engineer on it for the first six to eight weeks.
32:12 Speaker 00 So almost the first two months I was by myself, working on web. And it's again, not something that you usually get to do. Because it even feels a little bit weird, you know? We have this big repository that has most of our web code internally. And I sat down and I thought of a code name for the project because we have to have these unique file names. So you have to pick a code name that's unique. Ended up picking the same one that they had picked on the native apps side. And then I went right click, new folder, and typed in that code name and started from there. And that's just a very, very rare thing to be doing. And I'm honestly, I'm very happy and very glad that I got to see it from the very early days.
32:54 Speaker 00 And I got to make some of these, you know, big decisions. In hindsight, I kind of wish I had picked a different, shorter code name. I have typed that name, I don't know, tens of thousands of times now. Wish I had picked one that has like fewer characters in it, but here we are.
33:10 Ryan Peterman? You literally started Threads from scratch. It's such an unusual project.
33:16 Speaker 00 It's very unusual and it's not something that was clear from the very beginning. Again, it is one of those direction setting decisions that you have to make at some point. But you wanted to make that decision well reasoned. You really want to be sure that this is the way you want to be going. Initially, when we were just, I say we, at that point, it was just me. Initially, when I was just starting to render, you know, something, just get the first component to show up successfully on screen. I actually started in the Instagram web code base. And I just applied a little bit of CSS to hide everything that was on screen. But it was clear that this wasn't the way to go for Threads, right? So at that point, I decided, okay, the cleanest separation to prevent any like bleed over, any mix between the two was to just say, okay, let's just create a different folder.
34:01 Speaker 00 Let's create different components. Let's just make it a different surface, if you will. We didn't know the final product name at the time. We didn't know the final domain, but we knew it was going to be different as a surface from Instagram web. So it's not like we added a tab to Instagram web. You know, at some point when, for example, reels got added, we just added one tab, but that's still on Instagram web. This was a different service entirely.
34:24 Ryan Peterman? You know, I saw that year you got, which is even the most impressive thing. You got another redefines expectations rating promo to IC7. I imagine a large part of that was because of how successful Threads was. And, you know, you were an instrumental part of that. Is that the story behind the IC7 promo there?
34:44 Speaker 00 Yeah, ironically, you would think that as you get more senior, as you get higher up, or at least maybe, maybe I, I thought that beforehand. You'd think that the writing your self-review for the performance cycle, the annual performance cycle would become harder because you have to justify your work in a different way. And maybe it is less clear cut. There isn't as much a template of what a successful IC7 looks like versus a successful IC4. That's pretty well defined in comparison. Ironically, for me, this was, I think, the easiest self-review that I ever submitted. The work wasn't easy at all. It was an intense year. There was a lot of stuff going on. We had this tumultuous launch and everything that came out of it. And it didn't, it didn't stop with me, right? Like, I wasn't the only one building Threads web.
35:29 Speaker 00 I was the, the first engineer on it, but then a few weeks in, we brought in a handful of other engineers and at some point we staffed a, a small team around it. Hired an EM, hired a PM, had a, a full team together, right? We also didn't stop at a logged out web client. So we didn't just have a logged out service where you can share a post or look at a profile or do like an embed on a different website. But we actually built a logged in client. So you go to, you know, at the time, threads.net. These days, threads.com. You go to threads.net, you click login, you sign in and you see your feed and you see your notifications and you have settings and you can search and you can post. So we had to build a logged in client. And at the end of the day, it was a relatively easy story to tell.
36:13 Speaker 00 Again, the work wasn't easy, but the story was basically, okay, we're doing Threads. Threads needs web. I came in, laid the groundwork, created these like foundational structures, hired the team, ran the team as, as the TL, put out a lot of code myself during this time. So again, coding machining, under time pressure, we're on web, we're, we're onto something here.
36:35 Speaker 00 Basically, the third time, right, this happened. But it all worked and we launched without major issues. The product was well received and that made for a pretty easy to tell story in the performance cycle.
36:47 Ryan Peterman? That makes sense. I can imagine your performance review, you know, under the impact you had, just, you know, one line says basically like instrumental in, you know, threads web tech lead led, you know, X number of people, that kind of speaks for itself.
37:03 Speaker 00 Right. And if that can be clearly attributed to you as an engineer, so if your management chain and other senior engineers who are sitting in these conversations are convinced that, yeah, it's clear that threads web didn't happen, you know, like irrespective of me or despite me, but because I got involved, I think if you can create that linkage and if that attribution is clear, you will, you will get recognized for delivering this impact.
37:25 Ryan Peterman? I think that that's something that people talk about sometimes, like how do you get that attribution, especially when there's a lot of other people working in the area?
37:34 Speaker 00 It's, it's difficult in general. I think this is not an easy problem to solve because you want to, you want to have clear ownership in general. I really do believe in strong ownership, meaning if I take on a problem space or if I take on a product or a launch or a feature or whatever size you have, and I am the owner of that feature, product, whatever, I need to own that outcome as an engineer. So I need to make sure, come what may, that this is going to be successful. And I think there's, there's many things that you can think through that could happen to make the project not be successful and you want to go ahead and get ahead of those. Talk about threads web, for example, think about the initial launch, right? Like what, what are the possible failure modes in which launch day just becomes a
38:19 Speaker 00 clowny event and everything that can possibly go is wrong, goes wrong. What are those? And then you try to work backwards from them and you try to prevent them. Is there any questions around the infrastructure, maybe? Okay, uh, let's talk to the right infrastructure people and. Have them help us verify that everything is set up correctly. Right, we're talking on the web, so suddenly, oh, we're setting up an entirely new domain. We're not setting up a new subdomain, we're not doing threads.facebook.com or threads instagram.com, threads.net. So is that setup correct? We really don't want to launch and then have DNS issues or something like that. And you can go on like this, I think there's a lot more failure modes you can come up with, and I would always recommend trying to get ahead of those as much as you can. There is always a class of issues that you cannot predict.
39:01 Speaker 00 So you have your known unknowns and then come the unknown unknowns that you don't even know you don't know about. I think at that point, it becomes about operational excellence, release hygiene. You want to have error reporting that works, you want to do a lot of QA and really test your product, make sure it's working fine. You want to have feedback channels, so when people tell you like, hey, on Threads web, something looks really funky in the specific browser, that you respond to that quickly.
39:25 Ryan Peterman? Sounds like you are thinking like, I own whatever happens for Threads web, and that led you to do all these things.
39:32 Speaker 00 Yeah, that's right, but maybe what we should also talk about is that while I was ultimately accountable for delivering Threads web, because I was the directly responsible individual, you know, the DRI that we always talk about, it didn't mean that I had to do it all by myself, that would have been impossible. So this is when you get into being a senior engineer who works with other engineers. Even as a coding machine, like, obviously, you need to work with other people, I couldn't have done this by myself in any way. And at that point, you think a bit about recursive accountability, if you will, so you just divide and conquer the problem. Because Threads web overall, I am on the hook for making sure that this lines well, but then we had other senior engineers on the team who owned meaty pieces of the product. And then they are accountable for delivering that part.
40:15 Speaker 00 But the way that Meta thinks about these, from what I'm understanding, is that even though there might be somebody who owns part of the problem, that doesn't absolve me as the overall DRI from, you know, I'm still on the hook, that still needs to work. And I don't just get to then say like, oh, but that wasn't my sub problem, I only own the other two thirds. This one third isn't on me, blame this, no, that's not how it works. So you need to find a way, and this, I think, is almost a bit of an art form. As much as it is a learned skill, how you can effectively work with people, just be a great teammate, really good TL, who isn't micromanaging, but who isn't often the ether. Like you need to be applying the right level of touch.
40:58 Speaker 00 Give people freedom to grow because everybody has, wants to do well for themselves as well. They have career aspirations, but you do also need to convince yourselves, yourself that things are going well. I don't know who said this to me years ago, but the metaphor that I heard for this or the analogy is a driving teacher, like somebody who gives you driving lessons early on. You are driving, but they have a second steering wheel and they have their hands like right next to that. So the moment you're about to slip, that's when they intervene and they stop you from killing the two of you in traffic. And then over time, as you become a better driver, as you know more, like as you become more senior, so to speak, you gradually back off. And then there's a trust relationship that's, it's building up this way,
41:39 Speaker 00 where over time you know that you have your, your trusted lieutenants, if you will, who, who you can blindly rely on. Yeah, I, I think this is something that every engineer who gets to, I would say like five, but definitely six plus, needs to think about. How to influence engineers around them, how to be a good TL that isn't like obnoxiously close and, and micromanagement, micromanaging every little thing. It's tough. Not easy.
42:03 Ryan Peterman? Yeah, I think if I ask that question to someone who's a junior engineer or someone like yourself, we would see a dichotomy because I think you talk about ownership and, you know, assuring that others are successful and scaling yourself. And I think if I ask someone who's, uh, right at the beginning of their career, they might propose some solutions on you gotta hoard your scope or you gotta be the first one there or you gotta put your name on it. And actually it shouldn't matter how it gets done, just that it gets done and you play, you know, critical piece and everyone can work together.
42:40 Speaker 00 Yeah, I mean, that's the ideal, right? When everything is set up and structured well, you have the right owners in the right places at reasonable levels, right? You don't want to give something to somebody that's way outside of their comfort zone and just completely above what they can do today. A little bit of a stretch is fine, usually encouraged, that's how you grow. But if you give something that's like three levels above what they can handle, then you're going to set up this person and this project up for failure. At the same time, you don't want to give scope to somebody for which they're just vastly overqualified. But I do believe that, especially as a coding machine, not every single diff that you land in isolation has, you know, level-appropriate complexity. So if you pull up my latest 10 diffs from yesterday or something like that and you
43:24 Speaker 00 audit them, I doubt you would look at every single one of those diffs and say, like, "Ooh, this, this looks like an IC7 diff." There's like some maddening technical complexity in here. But that's not the point. Sometimes the point is like, okay, we have this big problem. I need to get this solved within the next two weeks to unblock the next work stream. I'm just going to lean into my strengths for a week, sit down, crank out 150 diffs and get this thing landed. I'm exaggerating slightly, but at the end of the day, you will have landed real impact because you're preventing another project from derailing or from going off the timeline. Was every diff Shakespeare? No, probably not.
43:58 Ryan Peterman? So it's a skill in your toolbox?
44:00 Speaker 00 Yeah, exactly. And I think Jake talked about this as well, if I remember correctly, while, while he was on the podcast and, and said something similar. You know, sometimes what's needed is taking an Uber TL role where you hold together these big work streams that involve usually always different teams, but at some point different orgs. You know, and the further away the teams are from each other organizationally, the harder the coordination becomes. And sometimes what's needed is just, look, we know what we need, we need it tomorrow. How do we, how do we do it?
44:29 Ryan Peterman? What does the future career planning look like? Like, are you, is it like, let's do IC8s? Or, you know, are you prioritizing other things? Like, let me find a new interesting problem to solve?
44:40 Speaker 00 It's an interesting question, and I genuinely don't have an answer today. I don't know. Well, we'll see how it goes. I know that the way that I'm operating right now and the work that I'm doing right now is extremely exciting to me. I actually recently switched teams from Threads Web to this big Instagram server.
45:00 Speaker 00 Back end project team that Jake is driving. So listen to his podcast episode if you want to learn more about that. That is a big priority for Instagram. So as I was alluding to in the very beginning, you need to work on something that's impactful. You simply do. You cannot be a successful senior engineer and just work on stuff that doesn't matter whatsoever. About ICA specifically, I don't know. Maybe this is something that I'll want to explore at some point. It's not something I'm pushing for actively right now. But I think there's obviously growth to be had as an engineer to get more familiar with different systems. I'm actually going a little bit outside of my my front end comfort zone now. And I'm becoming more of a full stack engineer or working towards that. And this is super exciting to me, also a little bit scary.
45:44 Speaker 00 So trying to to walk that balance as well. There's always the the engineering management track that I am not personally considering for myself because I get so much enjoyment out of the the work life as an IC. The coding of it all, that's the highly, highly technical nature of it all, those hairy problems. You know, the the demigod feeling I was describing before, when I just feel like I can see the matrix. You know, I'm I'm like Tron and I can see can see everything. By the way, secret recommendation, secret tip. The Tron Legacy soundtrack is one of the best soundtracks if you want to really put on your headphones, get dialed in and and get coding.
46:24 Speaker 00 So yeah, we'll we'll see what the future holds. What about when you got promoted to IC six? Was your first thought IC seven time? No, I it definitely wasn't. That's what happened when I got my promotion to IC five. Yeah. I celebrated for three minutes and then felt like, OK, now we're we're getting ready for for IC six before dawn. You know, that's that's it.
46:46 Speaker 00 It definitely wasn't the case for seven. Seven promotions are quite difficult. You said this before, many engineers don't make it to that level. But that that has there's many reasons for that. You know, there needs to also be a business need for somebody with that level of seniority. So if there's no business need, basically like an IC seven shaped hole that can only be plugged by an IC seven shaped puzzle piece, you're going to have a harder time making a case for a successful. So I see seven promotion, right? And in my case, I think threads web was was a great opportunity that came at the right time for me. The criteria matched, right? Obviously, you still have to always deliver these. I'm not trying to downplay any of these difficulties like these projects come up. But that doesn't guarantee a promo, right? You have to deliver them.
47:27 Speaker 00 But if you don't have these opportunities, because maybe they're just not around, then it is much harder.
47:32 Ryan Peterman? Have the expectations of the highest levels ever scared you?
47:37 Speaker 00 Oh, yeah, absolutely. Absolutely. Because when I joined as an IC four, I was thinking that, OK, I will have to eventually get promoted to IC five. That is the company policy, right? You need to eventually make it to IC five, which is where you can then stop if you choose. And then I was kind of apprehensive about IC six. Because I had seen IC sixes around me and I wasn't sure that this was the intensity I was I was looking for. I was just like scared a little bit. And I knew for a fact with certainty that I never ever wanted to consider IC seven. And here we are today, and things came very differently. And when I got to to IC six, I had this conversation with my partner and I said, OK, maybe, maybe at some point I might look at what it would take to get an IC seven promotion and what that would look like. But for a fact, I never want to even think about IC eight.
48:22 Speaker 00 Well, see, right now, I'm genuinely not pushing for it because it's not an easy jump to make. There needs to be the right position for it. And because I get so much satisfaction out of the the type of work that I currently do, I wouldn't want to to give up too much of it.
48:35 Ryan Peterman? You mentioned maybe in jest, but 150 dips in a week. And I'm kind of curious, though, like, you know, as a coding machine, what's your your most insane output week that you can ever think of where you just you did something ridiculous?
48:53 Speaker 00 Yeah, I think that was the the threads web year, right? That's what was the year that threads launched. I think I I came up just under 2000 dips at the end of the year.
49:00 Ryan Peterman? For a year. So, you know, three hundred and sixty five days in a year minus a hundred for weekends or something, two hundred. Yeah, that's that's insane. That's like ten deaths a day.
49:14 Speaker 00 Ish. Yeah, I mean, there's PTO, sick days, on call, meetings, whatever. There's all of this other stuff, but like roughly, that's what you're what you're looking at, right? And this is, again, I've had these conversations with so many, so many people over the years. Obviously, you can game the system if you want to game the system. So at best, this metric is directionally interesting.
49:32 Ryan Peterman? Yeah.
49:32 Speaker 00 Right? There's, in my mind, no difference whatsoever between somebody putting up three hundred deaths and somebody putting up four hundred deaths in a given half or in a given year or whatever time frame. There's no difference. It's just like, somebody tends to commit like twenty percent smaller deaths and hence ends up with with more.
49:49 Ryan Peterman? If you had the opportunity to talk to yourself right when you had entered the industry, knowing what you know now, what advice would you give yourself?
49:57 Speaker 00 I'd probably try and tell myself that things are gonna be fine. You're already on a good track. Don't put even more pressure on yourself than you already are. I was very, very ambitious, especially early on. I think I still am to a degree, but now I think it's all way more, you know, way healthier than it was in the past. You know, I talked a lot on this podcast about my love for for the web and development, software development in general and different technologies. And I was pretty intense about it at a time. I set this rule for myself for years that I would post one blog post every single week. And I stuck to that for quite a long time. And come what may, you know, I was trying to juggle my university life, I was doing my bachelor's, I was doing my masters, I was working at this agency for, you know, not quite full time, but almost, I was
50:41 Speaker 00 hanging out with friends. I had a very time consuming hobby at the time. And come what may, if I came home at midnight, I'd spend like two hours until 2am and write a blog post if I hadn't written one for the week. And that is a level of intensity that I no longer practice because I feel like that is not healthy anymore. I think it's fine when you're, you know, in your early twenties and you're so hungry to go for it. And I think it's worked out well for me. I think because of all of this, I think some recruiter at the time reached out to me because I had published all of the stuff. So I don't regret any of it. But I think the advice I'd want to give myself is, this is plenty. Chill a little bit. It's it's fine. It's gonna be fine.
51:19 Ryan Peterman? Well, what's interesting though is if you didn't do that, you probably wouldn't be in the position you're in now, though.
51:24 Speaker 00 Would've should've, it's the wing flap of the butterfly. I don't know, maybe, yeah. I don't regret doing any of it. It was the right thing for me. I never hated doing it. You know, it's not like I set up this draconian regimen for myself that I was being crushed under. It wasn't that. But it was a bit of Tetris playing with my calendar. There was a lot of things that needed to be shuffled around to fit everything together. But I learned a lot along the way. Got a lot of practical expertise from working at this agency and just having years and years of web development experience alongside all of the uni lectures, which are way more theoretical and partially outdated. They're great for the CS fundamentals, you know, when you talk about computer science topics and data structures and algorithms and know your time complexity and whatnot,
52:09 Speaker 00 operating systems, databases, what have you, math, lots of math. But that isn't what I use on a daily basis, right? Like, we're not using lambda calculus, we're using CSS.
52:19 Ryan Peterman? Yeah.
52:20 Speaker 00 So.
52:21 Ryan Peterman? Well, you can relax now. It's IC7. So, yeah, thanks so much for sharing your story with us.
52:28 Speaker 00 Yeah, thanks for having me time.
52:29 Ryan Peterman? Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior ICs, there's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them.
Previous Robinhood SWE Turned $1B+ Founder on Non-Linear Careers, Being Jaded About Promos, Startup Learnings Next Boris Cherny (Creator of Claude Code) On How His Career Grew Page updated October 31, 2026 · transcript and summary are machine-generated