Instagram Senior Staff Eng (IC7) On 3 Promos Through Redefining Expectations (Career Story)

22:31And 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 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. 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.

23:09I 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 infra or client infra space, as we call it. So it's not quite an infra level job. So it's not like 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 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.

23:48That means there's the right level of safeguards, type checking, tests, 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? In fact, quite high, the expectations. So I found this product infraspace to be an area that I find super interesting.

24:29And 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.

24:43Marius Schulz: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 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 and whatnot.

25:21One 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 back end 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 errors happening, right, when an error gets thrown, it's almost like a little grenade that detonates.

25:59And 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 blowing up the entire page and just showing, oops, something went wrong and taking down Instagram web? Probably not. You probably want to fence that. 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 what would happen. Yeah, this is the reliability effort.

26:30You 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 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.

27:08And you just harden the entire site against these errors, even if they're not happening today. 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 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 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 to try and classify these errors and say, okay, what is the primary information on a screen?

28:02What 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

28:30Marius Schulz:to six level impact if i'm understanding correctly that's where the leverage was in the 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, 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 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.

29:22We didn't find an error boundary that protects you from bad breakage. You probably might want to add one here. MARK MANDELSONIUSSKI - I see.

29:30Marius Schulz:And then in this case, the tool is doing useful work on your behalf, and it's helping you scale. And that's expected of IAC 6. MARK MANDELSONIUSSKI - 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, 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, like intrinsic motivation fit. Like it's exactly the problems you want to solve. Great team, great culture.

30:03Marius Schulz:And your performance showed 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 I'm just so curious about all the stories behind that. So 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 exciting. So you're paid to. 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. Right, right. But seriously, it's been a bit of a roller coaster in some way because it was an intense period of time.

30:41But 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.

31:17You know, we don't create these new family of apps as we call them, apps, almost ever. We try different things.

31:23Marius Schulz: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 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. 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.

31:57I 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 codename for the project because we have to have these unique file names. So you have to pick a codename that's unique.

32:36Ended 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 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, 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. I wish I had picked one that has slightly fewer characters in it. but here we are.

33:10Marius Schulz:You literally started threads from scratch. That'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 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.

33:50So at that point, I decided, okay, the cleanest separation to prevent any bleed over, any mix between the two was to just say, okay, 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.

34:23Marius Schulz: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 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.

35:01And 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 ThreadsWeb. 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.

35:37Hired an EM, hired a PM, had a full team together. 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 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:12Again, 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 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.

36:47Marius Schulz:That makes sense. I can imagine your performance review, you know, under the impact you had, just, you know, one line is basically like instrumental in, you know, threads, web, tech lead, you know, X number of people. That kind of speaks for itself. 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 ThreadsWeb 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.

37:25Marius Schulz: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 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.

38:01And 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 ThreadsWeb, for example, think about the initial launch, right? Like 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.

38:36We'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 set up correct? We really don't want to launch and then have of 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.

39:06I 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 ThreadsWeb, something looks really funky in the specific browser, that you respond to that quickly.

39:25Marius Schulz:MARK MANDELSKIANI It sounds like you were thinking, I own whatever happens for ThreadsWeb, and that led you to do all these things. FRANCESC CAMPOY Yeah, that's right. But maybe what we should also talk about is that while I was ultimately accountable for delivering ThreadsWeb, 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.

39:55I 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.

40:28That 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, 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 off in the ether. You need to be applying the right level of touch. 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 yourself that things are going well.

41:09I 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, 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.

41:46Yeah, 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 him, how to be a good TL that isn't like obnoxiously close and micromanaging every little thing. It's tough. Not easy.

42:02Marius Schulz:You know, I think if I asked 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 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.

42:39Yeah, 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. 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 for 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 a 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 like oh this looks like an IC7 diff.

43:30There'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, 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.

44:00Marius Schulz: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. 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 then 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? Is it like, let's do IC8?

44:34Marius Schulz: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 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.

45:13You simply do. You cannot be a successful senior engineer and just work on stuff that doesn't matter whatsoever. About IC8 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. um 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 uh 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 uh 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 so yeah we'll see what the future holds what about when you got promoted to IC6 was your first thought IC7 time no I it definitely wasn't that's what happened when I got my promotion to IC5 yeah I celebrated for three minutes and then felt like, okay, now we're getting ready for IC6 before dawn.

46:43Marius Schulz:You know, that's it. It definitely wasn't the case for seven. Seven promotions are quite difficult. I said this before, many engineers don't make it to that level, but 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 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.

47:19Obviously, 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. You have to deliver them. But if you don't have these opportunities because maybe they're just not around, then it is much harder.

47:32Marius Schulz:have the expectations of the highest levels ever scared you oh yeah absolutely absolutely because when i joined as um 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 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 IC7. And here we are today and things came very differently.

48:06And 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. There needs 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.

48:35Marius Schulz:You mentioned, maybe in jest, but 150 diffs in a week. And I'm kind of curious though, as a coding machine, what's your most insane output week that you can ever think of where you just did something ridiculous? Yeah, I think that was the Threads web year, right? That 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, it's like days on call, meetings, whatever. There's all of this other stuff, but like roughly that's what you're looking at, right?

49:20Again, I've had this conversation 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. 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 more.

49:49Marius Schulz: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, 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 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.

50:46And 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 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'd want to give myself is, this is plenty.

51:15Chill a little bit. It's fine. It's going to be fine.

51:19Marius Schulz: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. Would have, should have. 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. 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.

52:02They'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? Like we're not using Lambda calculus. We're using CSS. Yeah.

52:20Marius Schulz:So, well, you can relax now. You're ready to time. 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.