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.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
00:55 - Choosing his specialty
02:29 - Greatly exceeding expectations with no promo
24:43 - Leverage and IC4/5/6 way of solving problems
44:29 - Career planning past IC7
47:32 - Did IC7+ expectations scare him
49:49 - Advice for his younger self
Transcript
00:00:55 — Choosing his specialty
Ryan:
[00:00:55] You chose a specialty of being a front-end engineer, right? What was the thinking behind that?
Marius:
[00:01:00] 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.
[00:01:14] 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 HTML basics. This generation these days might not remember what the world looked like back then.
[00:01:36] But we had HTML that was not what it is today. Nowhere near as powerful. But even then, I got hooked very quickly. I remember fondly asking for a CSS book for Christmas. My grandma had absolutely no idea what CSS is, but she gave me that little book, and I finished reading that on Christmas Eve before I even went to sleep.
[00:02:02] That was one of my moments where I really got hooked. It’s called “Little Boxes,” a very good CSS book. Since then, I’ve always wanted to work on the web, deliberately sought out jobs where I could work on the web. 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.
00:02:29 — Greatly exceeding expectations with no promo
Ryan:
[00:02:29] When we talk about your growth from IC4 to IC5, I see that you only killed it. I mean, you exceeded expectations, you greatly exceeded, and then you got promoted when you redefined expectations. I’m curious, why was there no promotion in the greatly exceeds case and what’s the story behind that?
Marius:
[00:02:53] 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 came down to one expectations miss that blocked the promo. So I think this was seen as important enough.
[00:03:12] So that the room felt like we wanted to wait another half to see that point addressed or something around cross-functional collaboration. At the time, 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.
[00:03:32] 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 was a little bit too intense there.
Ryan:
[00:03:49] 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 a ding on your performance essentially.
Marius:
[00:04:10] 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. You can land a lot of impact and you can do a lot of good work.
[00:04:30] But promotions, especially lagging promotions, are about behaviors. Are you already exhibiting all of the next level’s behaviors? If there’s a gap between what’s expected at the next level, that means you’re not ready for promotion in this cycle. We can retest a promotion attempt next cycle.
[00:04:48] That was the reason that I think I didn’t get my five promo during that great exceeds half. Obviously, I hoped I was gonna 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 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 early days of the pandemic. For reasons decided by people, we didn’t do any promos, so I also didn’t get my five promo until the end of 2020.
Ryan:
[00:05:25] So as such a high performer, how’d you feel? I mean, getting a great rating and then no promo, and then also the promo block for COVID too.
Marius:
[00:05:33] It can be frustrating. Just to be fully honest, of course it can be frustrating when you feel like you were so close to getting it. I have worked hard on addressing the feedback. I think I’ve really taken that to heart.
[00:05:44] I’ve gotten lots of positive peer feedback saying that it was a very clear change in behavior, much more the way that we think we should collaborate between engineering and other functions. You’ve addressed all these things. You kept delivering impact. So you did strictly more and addressed everything.
[00:06:01] 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? 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.
[00:06:19] 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, 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 I got my PSC, that was recognized fully, so it all worked out in the end. Maybe took it half longer than I initially had hoped.
Ryan:
[00:06:51] 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 helpful and productive. Even, you know, COVID is one thing, but people’s promotions 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.
[00:07:10] So if you’re an IC4 who’s obviously doing IC5 things, but your promotion gets blocked because of budgets or something out of your control, you can think about what’s the IC6 thing to do. That will just give you a sense of progress still and something to achieve. The promotion is not a big deal.
Marius:
[00:07:35] 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.
[00:07:51] IC5 and then only when they make me an IC5 will I do that? That’s not how lagging promotions work.
[00:07:58] You get promoted once you have for a sufficient period of time demonstrated next level behaviors, next level impact.
00:08:04 — Senior promo
Ryan:
[00:08:04] After the COVID half, you got the redefined expectations rating and the promo.
[00:08:08] I’m curious, like what is the story behind the thing you landed?
Marius:
[00:08:12] Yeah. At the highest level, it came down to me taking a leading role on a project that has been clearly classified as an IC six level project, as an IC four, 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, right up my alley, but it involved way more people than just myself. This was a project that had 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. For an IC four, I think that was going above and beyond what is expected at IC four. 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. I got recognized for this effort because 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. Again, it was the early pandemic, and then the summer of 2020, end of 2020, and we launched without any major issues. At the end of the day, all of that also still matters. You still need to demonstrate all of this operational excellence when you work on these projects. 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 cause a giant incident and break all the systems. You’re not gonna get a pat on the shoulder for that. There’s still release hygiene that needs to be observed, but it isn’t just engineering. 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 what needs to happen or what the target outcome looks like. There are people problems that you run into. You need to coordinate 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 stuff as well.
At the end of the year when my case was being discussed, it must have been pretty clear that this wasn’t an IC four level performance. I can really only speculate. I don’t know if this is how we look at what differentiates maybe like a “greatly exceeds” from a “redefines,” but there is something there about, okay, if you’re doing the next, next level’s work, you’re probably not even exceeding expectations; you must be above that. Because it’s so far outside of what’s expected at IC4.
Ryan:
[00:11:09] Yeah. I mean, intuitively that makes sense. If you were in IC4, doing IC5 stuff, definitely gonna be exceeding, but then what’s IC6? What if you did an IC7 project?
Marius:
[00:11:20] It feels weird to talk about this because I feel like I’m tooting my own horn here quite a lot.
[00:11:24] 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 and exceeds, right? 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 meet all expectations.
[00:11:43] But then on top of that, they did this and we think this now warrants an exceeds. You can ladder your way up and articulate why this rating is possibly justified so that other people can understand.
Ryan:
[00:11:55] You mentioned you were an IC4, trusted with the IC6 project. That’s kind of interesting to me.
[00:12:01] A lot of people, when you talk about a promo, 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. What’s the story behind you getting either assigned to that project or creating that scope?
Marius:
[00:12:21] My entire team catalog at the time was working on this really big priority that had come up quite suddenly in 2020. A lot of people changed what they worked on at the time. We have a healthy level spread in the team, engineers taking on level appropriate work.
[00:12:43] One of the senior engineers on the team was out on paternity leave at the time, so he left a gap that needed to be filled. 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 or even two levels higher than I was at the time.
[00:13:05] It was a bit of a domino effect where there was a vacuum that needed to be filled, and everybody took on n plus one work, if you will. This is how I ended up with this project. It’s not like managers sit in a room and roll dice to decide who gets the project.
[00:13:24] There’s a bit of luck involved in getting matched with the right opportunity, but I firmly believe that you can increase your luck surface area by doing the right things. If you position yourself as, in my case, a web person who wants to be the web platform lead in my area, and then there’s a big web project coming up, they’re certainly going to consider me. It doesn’t mean I’m automatically going to get it, but at least I’ll hopefully be in consideration unless it’s way above what I can handle.
Ryan:
[00:13:59] You had been greatly exceeding expectations before, so the manager, whoever’s in charge of figuring out how to staff that, looked around and gave it to you because of that
[00:14:13] Is that something that’s been true throughout your career? You’ve been quite ambitious?
Marius:
[00:14:29] Yeah, pretty much since the very beginning. I vividly still remember the day that I really got hooked.
[00:14:36] It was like something that clicked in my head when I was learning JavaScript and I understood if statements and loops deeply. Something in me just went, oh my God, I am going to be like a demigod. I can do whatever I want to do, and the machine is at my disposal and I control it.
[00:14:59] That was this feeling. As I mentioned before, I’ve always had this interest in the web because I think it’s a beautiful invention. This initially set of connected documents shares the world’s knowledge. 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.
[00:15:25] I just think there’s something philosophically beautiful about that.
00:15:30 — Staff promo
Ryan:
[00:15:30] After IC5, your career trajectory actually went even faster. When I look at it, if I were to plot 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.
[00:15:44] I’m curious about the story behind the IC6 promos. Another redefines expectations rating, which is even harder. I could redefine expectations as an IC3 right now, but doing it as an IC5, IC6, it’s starting to get a lot crazier. So what was the story behind the IC6 promo?
Marius:
[00:16:05] 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 and 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 was part of the reason that I got the IC6 promo that had a lot of time pressure behind it.
[00:16:31] I think we’re onto a little bit of a theme here where it was another web project with a very tight, aggressive timeline. 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. There are a few things that you can influence or change, a few variables, a few knobs, and what are those usually?
[00:17:04] 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. We couldn’t add time; it was a hard deadline. Adding people wasn’t an option because 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. 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 was a shadow of what it should be.
[00:17:55] You don’t want to lower the quality bar too much. Sometimes you have to make a concession or two, 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 with good performance, reliability, and design craft, and everything that goes into the quality bucket. We did that with this project, again, on this short timeline, delivered this project. I was rereading my feedback that I got for this half this morning to remind myself. The specific feedback for me was that there was a high amount of ambiguity and everybody at the time was super stretched.
[00:18:36] There was PM support, but not full-time, not as much as we needed. There were questions to be answered quickly because otherwise, we would’ve missed that timeline. I got a lot of credit for flexing into that product hybrid role, that product hybrid archetype I was mentioning. What that means specifically is you have this fog of war situation, if you’ve ever played Age of Empires. You start in the middle of the map and around you, there’s just the black void you need to explore. 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. Once that is decided, at some point it becomes a bit more operational. It becomes about how we sequence the work, how we measure success.
[00:19:30] When do we know that we’re done? What is good enough, what isn’t good enough? At the lowest level, it comes down to assigning work to people, fleshing 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.
Ryan:
[00:19:49] Coming off of such a high, you actually switched teams. I wouldn’t have expected a team switch when everything’s going so well. So what’s the story behind transitioning to IG Web right after that and why?
Marius:
[00:20:02] I think it comes down to changing directions or changing priorities.
[00:20:09] On my wider team, I realized over my first two and a half years at the company, almost four years at the company, that I really enjoyed working on these web projects and anything related to quality.
[00:20:27] I alluded to this earlier, but work like performance, reliability, delight, and craft when it comes to the design aspects of things 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.
[00:20:57] Right. I was pretty deliberately working towards being this web expert. That’s how I wanted to shape my career, right? Because there are many different directions you can go in. You can push to become a generalist, a specialist, or maybe explore management.
[00:21:14] But for me, I wanted to be a web subject matter expert and just build the best web tools that I know how to build. At the time, Jake, who I believe you’ve had on the podcast before, was hiring engineers onto the Instagram web team. I saw that vacancy and jumped onto it. I 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.
[00:21:47] 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. 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. I had conversations with the engineering hiring managers.
[00:22:08] I ended up joining the team and continued on that trajectory on Instagram web. 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, which was notifications. If you know the sidebar on Instagram web, there’s the notifications panel that slides out, showing who liked your posts and whatnot.
[00:22:32] I worked on that, basically fully rewrote that because that code hadn’t been touched in many years. A lot of the code was getting really old and out of sync with the native apps as well. I landed all sorts of changes there that were very gratifying to me.
[00:22:48] I worked on that and felt proud of the work I was doing. I was 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 I worked on Instagram web for about a year doing various quality-related things.
[00:23:09] I mentioned the notifications panel that I worked on, but this was the main product change that I landed. Most of my work was in the product infra or client infra space, as we call it. It’s not quite an infra level job, so it’s not like a true infra team’s ownership.
[00:23:29] Product infra sits in between product and infra, as the name suggests. A lot of it is about the architecture of the website, structuring the code so that everybody building on Instagram web can be productive, can iterate quickly, and can iterate with confidence.
[00:23:48] That means there’s the right level of safeguards, type checking tests, manual and automated, what have you. This is a space that I have always been interested in because it’s a very leveraged area to work in. The more senior you get, the more you need to look for these leveraged areas because it becomes quite hard to deliver strong IC5, strong IC6, or strong IC7 level product impact.
[00:24:07] What does an IC7 product impact even mean? The expectations are quite high. I found this product infra space to be an area that I find super interesting. Conversely, many engineers, especially the very product-focused ones, don’t find it that interesting and would much rather do the actual product work. But yeah, I’ve spent a lot of time improving our, our systems there.
00:24:43 — Leverage and IC4/5/6 way of solving problems
Ryan:
[00:24:43] So you mentioned leveraged. That’s a really interesting concept. Can you explain the idea of what you mean by leveraged?
Marius:
[00:24:51] Yeah. We talk about this a lot on our infra teams. 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 products or the right tools are in place to help with testing.
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. I’m not talking about the backend now; I’m talking specifically about the front end. In React, we have this concept called error boundaries, which you can imagine are like try-catch statements about specific pieces of the UI. You can basically fence a certain area of the UI and say if there’s any rendering errors happening in this area, render this fallback state when that happens.
The way I picture rendering errors happening is almost like a little grenade that detonates. 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.
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. 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.
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, right? 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 a day or two 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. I would say that 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 take on IC6 level complexity. 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 in a big note that we can share internally, teaching people about everything that I just said about how to open the developer tools and how to trigger an error in a random place.
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? 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? 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. Now you can see how we go from four level impact to five level impact to six level impacts.
Ryan:
[00:28:32] If I’m understanding correctly, that’s where the leverage was in the IC6 example, 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 fix them themselves. If you did that for a hundred engineers, then it’s just faster than you could have done it yourself.
Marius:
[00:28:56] 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 are other things you can do. To complete this example, you can think of adding lint rules to the JIRA 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, “Hey, you’re doing something. We didn’t find an error boundary that protects you from bad breakage. You probably want to add one here.”
Ryan:
[00:29:30] In this case, the tool is doing useful work on your behalf and it’s helping you scale. That’s expected of IC6.
Marius:
[00:29:36] Right. 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. Now that we’ve talked about reliability, I can start focusing on performance next or something like that.
00:29:51 — Senior staff promo
Ryan:
[00:29:51] Going back to your career story, it sounds like you came onto IG Web super great, like intrinsic motivation fit. It’s exactly the problems you want to solve. Great team, great culture. Your performance showed as well; you were greatly exceeding even with the team switch, which usually causes some thrash. I saw that you started to work on Threads, and I’m just so curious about all the stories behind that. How did you start working on Threads? What’s the story there?
Marius:
[00:30:21] Threads has been such an amazing journey. Honestly, I’m not paid to say that. It’s just genuinely been one of the most exciting.
Ryan:
[00:30:29] You’re paid to—
Marius:
[00:30:32] haha well, I’m paid to work on it, but I’m not paid to sit on this podcast and tell everybody how great it was.
[00:30:36] But seriously, it’s been a bit of a rollercoaster because it was an intense period of time. I look back at the time that I spent on Threads with the other engineers, and I think collectively this is, up until this point, at least the best work we have done in our careers. I don’t say this to try and brag about it; it’s just been such a unique environment to see a zero to one app launch and to be there from, in my case, almost the very beginning. I got involved a few weeks after the project had gotten kicked off, so 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. We don’t create this new family of apps, as we call them, almost ever. We try different things.
[00:31:23] How’d you get recruited to the Threads team? It was my manager reaching out to me and suggesting that 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.
[00:31:39] I was interested and wanted to hear what this is all about. I 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 for Threads. 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.
[00:32:16] It’s again, not something that you usually get to do. It even feels a little bit weird. We have this big repository that has most of our web code internally, and I sat down and thought of a code name for the project because we have to have these unique file names. I ended up picking the same one that they had picked on the native apps side. Then I went right click new folder and typed in that code name. Started from there. That’s just a very rare thing to be doing. I’m honestly very happy and glad that I got to see it from the very early days. I got to make some of these 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 slightly fewer characters in it, but here we are.
Ryan:
[00:33:10] You literally started Threads from scratch. That’s such an unusual project.
Marius:
[00:33:16] It’s very unusual and it’s not something that was clear from the very beginning.
[00:33:19] 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 I was just starting to render something, just get the first component to show up successfully on screen.
[00:33:41] 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. So 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.
[00:34:01] 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 gonna be different as a surface from Instagram web. So it’s not like we added a tab to Instagram web. At some point when, for example, Reels got added, we just added one tab, but that’s still on Instagram web.
[00:34:20] This was a different surface entirely.
Ryan:
[00:34:24] 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?
Marius:
[00:34:44] Yeah. Ironically, you would think that as you get more senior, higher up, or at least maybe 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.
[00:35:04] There isn’t as much of a template of what a successful IC7 looks like versus a successful C4. That’s pretty well-defined in comparison. Ironically, for me, this was the easiest self-review that I ever submitted. The work wasn’t easy at all. It was an intense year. It was a lot of stuff going on.
[00:35:22] We had this tumultuous launch and everything that came out of it, and it didn’t stop with me, right? 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.
[00:35:37] 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 an embed on a different website. We actually built a logged in client. So you go to, at the time, threads.net, these days, threads.com, you go to threads.com, you click login.
[00:36:00] You sign in and you see your feed, your notifications, 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.
[00:36:18] 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. Coding under time pressure. We’re onto something here. It’s basically the third time this happened.
[00:36:37] 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.
Ryan:
[00:36:47] That makes sense. I can imagine your performance review under the impact you had. Just one line is basically like instrumental in Threads, web tech, lead, led X number of people and that kind of speaks for itself.
Marius:
[00:37:04] 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 it’s clear that Threads Web didn’t happen 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.
Ryan:
[00:37:25] 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.
Marius:
[00:37:34] It’s difficult. In general, I think this is not an easy problem to solve because you want to have clear ownership. I really do believe in strong ownership.
[00:37:44] Meaning if I take on a problem space or if I take on a product or a launch or a feature, I need to own that outcome as an engineer. I need to make sure that this is going to be successful. There are many things that could happen to make the project not be successful, and you want to get ahead of those.
[00:38:07] For example, think about the initial launch of Threads Web. What are the possible failure modes in which launch day becomes a cloudy event and everything that can possibly go wrong does? What are those? 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. Have them help us verify that everything is set up correctly.
[00:38:41] We’re talking on the web, so we’re setting up an entirely new domain. We’re not setting up a new subdomain like threads.facebook.com or threads.instagram.com. Is that set up correctly? We really don’t want to launch and then have DNS issues or something like that. I think there are 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.
[00:38:58] There’s always a class of issues that you cannot predict. You have your known unknowns and then come the unknown unknowns that you don’t even know about. At that point, it becomes about operational excellence and 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, “Hey, on Threads Web, something looks really funky in a specific browser,” you can respond quickly.
Ryan:
[00:39:25] Sounds like you are thinking like I own whatever happens for Threads Web, and that led you to do all these things.
Marius:
[00:39:32] Yeah, that’s right. But maybe what we should also talk about is that while I was ultimately accountable for delivering Thread’s Web, because I was the directly responsible individual, the DRI that we always talk about, it didn’t mean that I had to do it all by myself.
[00:39:45] That would’ve been impossible. Right. So this is when you get into being a senior engineer who works with other engineers. Even as a coding machine, 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.
[00:40:02] So you just divide and conquer. The problem is Thread’s Web overall, I’m on the hook for making sure that this lands well, but then we had other senior engineers on the team who owned meaty pieces of the product and they are accountable for delivering that part. But the way that Meta thinks about these, from what I’m understanding, is that even though they might be somebody who owns part of the problem, that doesn’t absolve me as the overall DRI. I’m still on the hook.
[00:40:28] That still needs to work. And I don’t just get to then say, oh, but that wasn’t my sub problem. I only own the other two thirds. This one third isn’t on me. 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, a really good TL who isn’t micromanaging, but who isn’t often in the ether.
[00:40:55] You need to be applying the right level of touch, give people freedom to grow because everybody wants to do well for themselves. 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 is a driving teacher. Like somebody who gives you driving lessons early on, you are driving, but they have a second steering wheel and their hands are 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.
[00:41:29] And then over time, as you become a better driver, as you become more senior, 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.
[00:41:46] 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 obnoxiously close and micromanaging every little thing. It’s tough.
Ryan:
[00:42:03] I think if I asked that question to someone who’s a junior engineer vs someone like yourself, we would see a dichotomy because I think you talk about ownership and 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 gotta hoard your scope, or you gotta be the first one there.
[00:42:29] 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 a critical piece and everyone can work together.
Marius:
[00:42:40] Yeah, 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.
[00:42:49] You don’t want to give something to somebody that’s way outside of their comfort zone and completely above what they can do. 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 gonna set up this person and this project for failure.
[00:43:06] At the same time, you don’t want to give scope to somebody for which they’re 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. If you pull up my latest 10 diffs from yesterday or something like that and you audit them.
[00:43:25] I doubt you would look at every single one of those diffs and say, “Ooh, this looks like an IC7 diff.” There’s some maddening technical complexity in here, but that’s not the point. Sometimes the point is, okay, we have this big problem. I need to get this solved within the next two weeks to unblock the next work stream.
[00:43:40] I’m just gonna 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. 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.
[00:44:14] Usually always different teams, but at some point different orgs. The further away the teams are from each other organizationally, the harder the coordination becomes. Sometimes what’s needed is just, look, we know what we need. We need it tomorrow. How do we do it?
00:44:29 — Career planning past IC7
Ryan:
[00:44:29] What does the future career planning look like?
[00:44:31] Are you prioritizing other things? Let me find a new, interesting problem to solve.
Marius:
[00:44:40] It’s an interesting question and I genuinely don’t have an answer today. I don’t know. We’ll see how it goes. I know that the way I’m operating right now and the work I’m doing is extremely exciting to me.
[00:44:54] I actually recently switched teams from Threads Web to this big Instagram server backend project team that Jake is driving. Listen to his podcast episode if you want to learn more about that; it is a big priority for Instagram. As I was alluding to in the very beginning, you need to work on something that’s impactful.
[00:45:13] You 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.
[00:45:33] 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. This is super exciting to me. Also a little bit scary, right? 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 IC, the coding of it all.
[00:46:00] That’s the highly technical nature of it, all those hairy problems, the demigod feeling I was describing before, when I just feel like I can see the matrix, I’m like Tron and I can see everything. By the way, secret recommendation, secret tip, 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.
Ryan:
[00:46:35] What about when you got promoted to IC6? Was your first thought IC7 time?
Marius:
[00:46:36] 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. IC7 promotions are quite difficult. You said this before, many engineers don’t make it to that level, but there are many reasons for that. There needs to also be a business need for somebody with that level of seniority.
[00:47:00] 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. In my case, I think Threads Web was a great opportunity that came at the right time for me. The criteria matched. 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. 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.
00:47:32 — Did IC7+ expectations scare him
Ryan:
[00:47:32] Have the expectations of the highest levels ever scared you?
Marius:
[00:47:36] Oh yeah. Absolutely. Because when I joined as an IC4, I was thinking that I would 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.
[00:47:50] I was kind of apprehensive about IC6. I had seen IC6s around me and I wasn’t sure that this was the intensity I was looking for. I was a little scared, and I knew for a fact that I never wanted to consider IC7. And here we are today.
[00:48:05] Things came very differently. When I got to IC6, I had this conversation with my partner and I said, 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. Right now I’m genuinely not pushing for it because
[00:48:26] it’s not an easy jump to make. That needs to be the right position for it. 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.
Ryan:
[00:48:35] You mentioned maybe in jest, but 150 diffs in a week. I’m kind of curious though, as a coding machine, what’s your most insane
[00:48:48] output week that you can ever think of where you just did something ridiculous.
Marius:
[00:48:53] Yeah, I think that was the Threads web year. That’s when Threads launched. I came up just under 2000 diffs at the end of the year.
Ryan:
[00:49:02] So, 365 days in a year minus a hundred for weekends or something.
[00:49:10] 200. Yeah. That’s insane. That’s like 10 diffs a day.
Marius:
[00:49:14] Ish. Yeah. I mean, there’s PTO, sick days, on-call maintenance, whatever. There’s all of this other stuff, but roughly that’s what you’re looking at. I’ve had those conversations with so many people over the years.
[00:49:25] Obviously, you can game the system if you want to. Yeah. So at best, this metric is directionally interesting.
Ryan:
[00:49:32] Yeah.
Marius:
[00:49:32] There’s 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 timeframe.
[00:49:41] There’s no difference. It’s just that somebody tends to commit 20% smaller diffs and hence ends up with more.
00:49:49 — Advice for his younger self
Ryan:
[00:49:49] If you had the opportunity to talk to yourself when you had entered the industry, knowing what you know now, what advice would you give yourself?
Marius:
[00:49:57] 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 ambitious, especially early on. I think I still am to a degree, but now I think it’s all way healthier than it was in the past.
[00:50:16] I talked a lot on this podcast about my love for the web and development, software development in general and different technologies, and I was pretty intense about it at the 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.
[00:50:32] Come what may, 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 almost full-time, but not quite. I was hanging out with friends. I had a very time-consuming hobby at the time. Come what may, if I came home at midnight, I’d spend like two hours until 2:00 AM and write a blog post if I hadn’t written one for the week.
[00:50:51] 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 twenties and you’re so hungry to go for it. I think it’s worked out well for me. Because of all of this, I think some recruiter at the time reached out to me because I had published all of the stuff.
[00:51:10] So I don’t regret any of it. But I think the advice I’d wanna give myself is, chill a little bit. It’s fine. It’s gonna be fine.
Ryan:
[00:51:19] 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.
Marius:
[00:51:26] The wing of the butterfly.
[00:51:27] I don’t know. Maybe. Yeah. It’s, 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.
[00:51:47] There were a lot of things that needed to be shuffled around to fit everything together, but I learned a lot along the way. I 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 university lectures, which are way more theoretical and partially outdated.
[00:52:02] They’re great for the computer science 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.
[00:52:18] We’re using CSS.
Ryan:
[00:52:20] Well, you can relax now that you hit IC7. Thanks so much for sharing your story with us.
