The Peterman Pod - Instagram Senior Staff Eng (IC7) On 3 Promos Through Redefining Expectations (Career Story)

Episode Date: December 8, 2025

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 - Intro00:55 - Choosing his specialty02:29 - Greatly exceeding expectations with no promo08:04 - Senior promo15:30 - Staff promo24:43 - Leverage and IC4/5/6 way of solving problems29:51 - Senior staff promo44:29 - Career planning past IC747:32 - Did IC7+ expectations scare him49:49 - Advice for his younger self52: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

And I knew for a fact with certainty that I never, ever wanted to consider IC7. And here we are. This is Marius Schultz. 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. There's an IC4, IC5, and IC6, and maybe even higher, way to go about almost any problem. He got another redefines expectations rating promo to IC7. The year that threads launched, I think I came up just under 2,000 diffs at the end of the year.

for a year. He also opened up about what held his career back. 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? Here's the full episode. You chose a specialty of being a front-end engineer. Well, it'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, These days might not remember what the world looked like back then. But 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 a very, very good CSS book. And since then, I've always wanted to work on the web, deliberately sought out jobs where I could work on the web. 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.

When we talk about your growth from IC4 to IC5, I see that you only killed it. I mean, you did an EEE. 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? 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 going to get it. I think at the end of the day, it came down to one expectations miss that at the end of the day blocked the promo. So I think this was seen as important enough so that the room felt like we wanted to wait another half. To see that point addressed was something around cross-functional collaboration at the time. I think 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 should go about getting your ideas prioritized.

I think it's totally fine to suggest things. It's fine to advocate for them vociferously, but at some point, you can't overdo it. There's a balance to be struck, and I think I was a little bit too intense there. 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 concrete, feedback from maybe a partner or something like that that said it was like a ding on your performance. 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 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 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 the cycle. And we can reattempt a promotion attempt, you know, next cycle. And that was the reason that I think I didn't get my five promo during that greatly exceeds half. Obviously, I hoped I was going to get it, as I'm sure everybody does. This one was a bit of a weird one because the next half where I was thinking, okay, now I'm going to 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 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. So as such a high performer, how did you feel, I mean, giving. a greatly and then no promo and then also the block too. 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 worked 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 think, you know, we should collaborate between engineering 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, yeah, it was frustrating. But at the end of the day, our careers are long. 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 PSC, that was recognized fully. So it all worked out in the end, maybe took a half longer than I initially had hoped. I lived that same experience as well. I was hoping for a promotion and then it got blah. But I think that that mindset is, uh, helpful and productive. Even, you know, COVID's 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 or whatever. 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. Right. You can think about what's the IC6 thing to do. and that will just give you a sense of progress still and something to achieve. And it's just all on paper, the promotion is not a big deal. Well, and I would argue you almost have to do this

or you really should be doing this because you can't be a defeatist and you can't take the stance that, oh, okay, well, I didn't get this promo now. So I'm going to 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. You know, you get promoted once you have for a sufficient period of time, demonstrate it next level behaviors, next level impact. 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? 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 levels, 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, 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. And for an IC4, I think that was going above and beyond what is expected at IC4. You know, you talk about these different granularities or these different sizes, these different scopes that you should be looking after. And 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 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 clearly was more than what was expected of before. We delivered all of this on an ambitious timeline, working through what was a weird environment. Again, it was the early pandemic. And then, you know, the summer of 2020, end of 2020. 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 work on these projects, right? It's not enough to write a lot of code and say it's done. And then you pull the trigger on launch day and you just cause a giant incident 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 ICSX project. There's usually ambiguity in some form that could be in the product space where it's not entirely clear what needs to happen or what 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 all that and stuff as well.

And yeah, I think at the end of the year when my case was being discussed, I think it must have been pretty clear that this wasn't an IC4 level performance. I can really only speculate. I don't know if this is how we look at what differentiates maybe, like, you know, like, 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 level's work, you're not meeting or probably not even exceeding expectations, you must be above that.

Right. Because it's so far outside of what's expected at IC4. 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 the IC4? Right. And it feels so weird to talk about this because I feel like I'm tuning my own horn here quite a lot.

But it's 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 laddering 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 and exceeds. And you can ladder your way up.

and you can articulate why this rating is possibly justified so that other people can understand. You mentioned you were an 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.

Right. What's the story behind you getting either assigned to that project, or creating that scope? 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 we have a healthy level spread in the team, engineers taking on level appropriate work. But 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 a project that ended up coming to me had to fill that spot. He was one level or even two levels higher than me at the time than 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 a dice. And that's, 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, on my team or whatever the scope was at the time. And then there's a big web project coming up. 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. You had been greatly exceeding expectations before. So the manager, whoever is in charge of figuring out how to staff that, they looked around and, I mean, web, subject matter expert, greatly exceeding, hungry to take on more. Okay, let's give up to that guy.

And, I mean, it worked out. You crushed it, so it seems like it was good. Very hungry. Is that something that's been true throughout your career? You've been quite ambitious or? 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 demi-god. I can do whatever I want to do. And the machine is at my disposal, and I control it. That was like this feeling. And then, as I mentioned before, I've always had this interest in the web,

just because I feel like it's, 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. After you got front to IC5, your career directory actually went even faster.

Like, when I look at it, if I would applaud it, it would be like a little bit of a hockey stick. You were at IC4 for a while, written good ratings, and then you jumped and you jumped and you jumped. I'm curious about the story behind the IC6 promo, another redefines expectations rating, which is even harder. Like, you know, I could redefine expectations as an IC3 right now, you know, doing it as IC5, I6, it's starting to get a lot crazier. So what was the story behind the IC6 promo? It always comes down in some way, shape, or form to the impact that you land.

Impact can come in many different forms. It depends on the team you're on. It depends on the type of work that you do. But at the end of the day, you have to have delivered a lot of impact. As an IC5, I was working on a project, which I think was part of the reason that I got the 6 promo, that had a lot of time pressure behind it. I think we're onto 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. 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. That was a hard deadline. Adding people wasn't an option because we already had everybody was already allocated to a high priority area. 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 should, ship, we ship with the 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. And I think the specific call out there was actually rereading 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 was PM support, product manager support, but not full-time, not as much as 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 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. that's just like the black void. You need to go explore.

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, OK, how do we sequence the work? 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 assigning work to people, flashing out these work streams, and then taking off the product hybrid head, putting on the coding machine hat, putting on headphones, and going to town. Coming off of such a high, you actually switch teams. I wouldn't expect it like a team switch whenever things going so well. So what's a story behind transitioning to IG Web right after that and why?

I think it comes down to changing directions, I guess, or changing priorities, rather. On my wider team, I had realized over my first, what was it at that point, two, two and a half years at the company, no, longer, 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 worked like performance, liability, delight and craft when it comes to the design aspects of things. And that didn't fully align with the priorities that were coming in at the time. Web just wasn't part of the big priority. 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.

I was kind of pretty deliberately working towards being this web expert. That's how I wanted to shape my career, right? Because there's many different directions you can go in. You 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,

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 lo 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. And 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. So at the time we were doing work on many different services 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 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 the code was just getting really, really old and out of sync with the native apps as well. And landed all sorts of changes there that were very, very gratifying to me, if you all.

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. They wanted somebody 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 main product change that I landed. Most of my work actually was in the product info, or client infraspace, as we call it. So it's not quite. an infra level job. So it's not like a true infrared teams ownership. But product info 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 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 is an IC7 product impact? quite high the expectations. So I found this product infraspace 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 actual product work, if you will. But yeah, I've spent a lot of time improving our systems there. So you mentioned Leveraged. I think that's a really interesting concept. Can you explain the idea of what you mean by Leveraged? Yeah.

We talk about this a lot on our infer 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 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 product or the right tools are in place to help with testing, whatnot. One specific thing 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 backhand now. I'm talking specifically about the front end. 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 error is 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 super important for the page, are you really happy 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. So 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 to feel out what would happen. Yeah, this is the reliability effort. You can 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 close. 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, 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, right? That 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 spend some time writing everything down, everything that I'm telling you right now. I spend some time writing that down in a big note that we can share internally, teaching people about everything that I just said about like, here's how you're always. 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 node can now apply this to their own products that have nothing to do at all with it with Instagram Web. And now you can see how we go from four level impact to five level impact to six level impact. 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. Right. And it's scaled. 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. Just to complete this example, you can think of adding lint rules to your code base 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. 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 IAC6. 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. Going back to your career story, it sounds like you came onto IG Web, super great intrinsic motivation fit. Like you, it's exactly the problems you want to solve. Great team, great culture. And your performance showed us as well.

You're greatly exceeding, even with the team switch, which usually causes some thrash. And then I saw that you, started to work on Threadsweb. And, you know, I'm just so curious about all the stories behind that. So, hey, how did you start working on Threads? What's the story there? Threadsweb has been such an amazing journey, honestly. I'm not paid to say that. It's just genuinely been one of the most excited. 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. But seriously, it's been a bit of a

rollercosta in some way because it was an intense period of time, but I look back at the time that I spent on Threadsweb with the other engineers working working on Threadsweb. And I think collectively, this is up until this point at least the best work we have done 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.

We try different things. We create new products over the years. How'd you get recruited to the Threads team? 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 as 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. I at least wanted to hear what this is all about. Got connected to the hiring manager on Threads, who ended up being 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 Threadsweb. I later helped grow that into more scope. Initially, it was 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. 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. I ended up picking the same one that they 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 honestly, I'm very happy and very glad

that I got to see it from the very early days. And I got to make some of these big decisions. Hind said, 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. I wish I had picked one that has a few characters in it, but here we are. You literally started threads from scratch. It's such an unusual project. 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 want 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 something, just get the first component to show up successfully on screen, I actually started in the Instagram web codebase. 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. So at that point, I decided, OK, the cleanest separation to prevent any like bleed over, any mix between the two was to just say, OK, let's just create a different folder. 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 surface entirely. You know, I saw that year you got, which is even the most impressive thing, you got another redefines expectations rating, promo to ICSI. 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? Yeah.

Ironically, you would think that as you get more senior, as you get higher up, or at least maybe I thought that beforehand, you'd think that the writing yourself 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 stop with me. I wasn't the only one building threads web. I was 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 small team around it.

Hired an EM, hired a PM, had 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 surface 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. 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 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 onto something here. It's 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. That makes sense.

I can imagine your performance review, you know, under the impact you had, just, you know, one lines is basically like instrumental in, you know, threads web, tech lead, you know, X number of people. And that kind of speaks for so. Right. And if that can be clearly attributed to you as an engineer, so if your management chain and other senior engineers who were 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 get recognized for delivering this impact. I think that that's something that people talk about sometimes. How do you get that attribution, especially when there's a lot of other people working in the area? It's difficult in general. I think this is not an easy problem to solve because 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 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.

What are the possible failure modes in which launch day just becomes a clowny event and everything that can possibly go as 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, let's talk to the right infrastructure people and have them help us verify that everything is set up correctly. 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, you know, threads.com or threads.com Instagram.com. Dreds.net.

So is that setup, correct? We really don't want to launch and then have, you know, 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's always a class of issues that you cannot predict. 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 problems. make sure it's working fine. We 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.

Sounds like you are thinking, like I own, you know, whatever happens for threads web, and that led you to do all these things. 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 my 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. This threads web overall, I am on the hook for making sure that this lands well.

But then we had other senior engineers on the team who own meaty pieces of the product. And then they are accountable for delivering. that part. 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 It's 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 off in the ether. You need to be applying the right level of touch. Give people freedom to grow because everybody wants to do well for themselves as well. They have career aspirations, but you do also need to convince 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, 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, as you become more senior, so to speak, you gradually back off. And then there's a trust relationship that's building up this way. where over time you know that you have your trusted lieutenants, if you will, who you can blindly rely on.

Yeah, I think this is something that every engineer who gets to, I would say, five but definitely six plus needs to think about. How to influence engineers around him, how to be a good TL that isn't like obnoxiously close and micromanagement, micromanaging every little thing. It's tough. Yeah. Yeah. I think if I ask that question to someone who's a junior engineer or someone like yourself,

we would see it the cut of me 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, you're right at the beginning of their career, they might propose some solutions on you got to hoard your scope or you got to be the first one there or you got to 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.

Yeah, I mean, that's the ideal. 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 encourage that 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 level appropriate complexity. So if you pull up the latest 10 diffs from yesterday or something like that and you audit them, I doubt you would look at every single one of those diffs and say, oh, 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 the soft 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, just 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. So it's a skill in your toolbox. Yeah, exactly. And I think Jake talked about this as well. If I remember correctly while he was on the podcast and said something similar.

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. 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 do it? What does the future career planning look like? Like, are you, is it like, let's do ICAIDS? or are you prioritizing other things?

Like, let me find a new interesting problem to solve. 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 Threadsweb

to this big Instagram server, backend project team that Jake is driving. So listen to his... 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 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. So trying to walk that balance as well. There's always the engineering management track that I am not personally considering for myself because I get so much enjoyment out of the work life as an I see, the coding of it all. It's the highly, highly technical nature of it all, those hairy problems. You know, the demi-god feeling I was describing before when I just feel like I can see the Matrix. You know, I'm like Tron and I 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 get coding. So yeah, we'll see what the future holds. What about when you got promoted to IC6? Was your first thought IC7 time? No, it definitely wasn't. That's what happened when I got my promotion to IC5.

I celebrated for three minutes and then felt like, okay, now we're getting ready for IC6 before dawn. You know, that's it. 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 there's many reasons for that.

There needs to also be a business need for somebody with that level of seniorities. So if there's no business need, basically like an IC7 shaped hole that can only be plugged by an IC7-shaped puzzle piece, you're going to have a harder time making a case for a successful IC7 promotion. And in my case, I think Threadsweb 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. These projects come up, but that doesn't guarantee a promo, right?

You have to deliver them. But if you don't have these opportunities, because maybe they're just not around, and it is much harder. Have the expectations of the highest levels ever scared you? Oh, yeah, absolutely, absolutely. Because when I joined as an IC4, I was thinking that, okay, I will have to eventually get promoted to IC5 because that is the company policy, right? You need to eventually make it to IC5, which is where you can then stop if you choose.

And I was kind of apprehensive about IC6 because I had seen IC6s around me and I wasn't sure that this was the intensity I was looking for. I was just scared a little bit. And I knew for a fact with certainty that I never ever wanted to consider IC7. And here we are. Today and things came very differently. And when I got to IC6, I had this conversation with my partner and I said, okay, maybe, maybe at some point I might look at what it would take to get an IC7 promotion and what that would look like. But for a fact, I never want to even think about IC8.

We'll see, right now I'm genuinely not pushing for it because it's not an easy jump to make. They need to be the right position for it. And because I get so much satisfaction out of the type of work that I currently do, I wouldn't want to give up too much of it. You mentioned maybe in Jess, but 150 diffs in a week. And I'm kind of curious, though, like, you know, as a coding machine, what's your most insane output week that you can ever think of where you just, you did something ridiculous?

Yeah, I think that was the Threads web year. That's what was the year that Threads launched. I think I came up just under 2,000 diffs at the end of the year. For a year. So, you know, 365 days in a year minus 100 for weekends or something. 200. Yeah, that's insane. That's like 10 diffs a day.

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 looking at, right? And this is, again, I've had those conversations with 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 yeah right there's in my mind no difference whatsoever between somebody putting up 300 diffs and somebody putting up 400 diffs 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 20%

smaller diffs and hence ends up with with more right 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? I'd probably try and tell myself that things are going to 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, way healthier than it was in the past. I talked a lot on this podcast about my love for the web and 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 master's, I was working at this agency for, you know, not quite full-time, but almost I was 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 2 a.m. 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 in your early 20s 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 want to give myself is this is plenty. Chill a little bit. It's fine. It's going to be fine. Well, what's interesting, though, is if you didn't do that, you probably wouldn't be in position you're in now though. Would have should have.

You know, it's the wingflab of the butterfly. I don't know, maybe. Yeah. 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, I set up this draconian regimen for myself that I,

that I was, you know, 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. Operating systems databases, what have you.

Math, lots of math. But that isn't what I use on a daily basis, right? We're not using Lambda calculus. Using CSS. Yeah. So, well, you can relax now. It's IC7. So, yeah, thanks so much for sharing your story with us.

Yeah, thanks for having me. 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.