Boris Cherny (Creator of Claude Code) On How His Career Grew

22:08Boris Cherny:And if you're just mashing that button, what can happen is that the responses come in out of order, and you might end up with a different state than what was in the UI. And so I wrote a system to kind of queue up mutations. so it was like consistency at the cost of reliability and this was kind of the right trade-off at the time and everyone ended up using this and this is how I met like Joe Savona and a bunch of the relay team that was working on the data stores and it was just really fun and this is something that since then and before then and you know whenever I work with engineers I just love when people go a layer deeper and you know just try to figure out like what's going on and like just because you're a product engineer doesn't mean you can't build infra.

22:47Boris Cherny:Just because you're an infra engineer doesn't mean you can't go talk to users. Just be curious about these other parts of the stack. Definitely. And in your agency and getting ahead of Comet or this big JavaScript rewrite, you mentioned in your writing that getting ahead of that actually gave you a lot more control and also dibs on opportunities. So when you talk about opportunities there, is this what you're kind of talking about? Like building these fundamental pieces of prod infra that are impactful for everyone that's going to take on the new platform. Yeah, yeah, that's an example of it. And then maybe, you know, like a different kind of example is Comet was a lot higher quality than the thing that came before because, you know, it's like a single page web app.

23:29Boris Cherny:So it can just feel a lot more polished. But we hadn't yet figured out like what exactly quality means on the product side. And so I wrote a bunch of notes trying to define that and then did a bunch of tech talks trying to just like teach people on other teams, like here's what we learned about quality. and just kind of like setting up the conversation about that. You mentioned a big headcount ask for, I guess, this migration to comment. You know, I feel like I'd be curious what that would look like in today with these new tools like Cloud Code, Codex, etc. I'd be curious, like knowing what you know now about Cloud Code and let's say you were in charge of doing that same scoping for that same job, how many engineers do you think it'd take to do that 12 engineer job yeah so I think overall to move Facebook group so it started with 12 engineers but I think at the end it was maybe like 20 or 30 engineers or something for about two years so it turned out to be a pretty big project I think nowadays it would be maybe I don't know like five engineers for six months something something like that so fourth of the fourth of the time and like more than a third or less than a third of the engineers as well.

24:42Boris Cherny:Yeah. Yeah. Cause you just like, everyone would just have a bunch of quads running in parallel and, you know, just like let it cook for a couple hours and then it comes back with a PR and then you give it like puppeteer or something. So it can kind of see the UI and, and adjust. And I think that's pretty much all it would be. And then I, you know, nowadays the world we're in is so different from a coding point of view because the models are moving so quickly that, you know, if you ask me this question in three months or six months, my answer will be totally different. In six months, the answer might be, this is actually one engineer.

25:13Boris Cherny:It's just moving so quickly now, it's really hard to do these estimates or to predict how they're going to change in the future. At this point in your career, you had mentioned something, maybe it was tongue in cheek, I'm not sure. You said, this was when I learned to always present three options in VP reviews, since 80 % of the time, they'll just pick the middle option. and then it says your VP picked the middle option in parentheses. What's the thinking behind that? Yeah, this is very much tongue in cheek, but maybe this is actually kind of true at meta at the time. I think decision makers that are far away from the work want to know that you did the due diligence of finding the right options and the right trade-offs and that you did the work, but they also want to contribute somehow to the decision.

26:02Boris Cherny:So, you know, the middle option is kind of the easy way to do that. It's a little tongue in cheek because I think not all leaders are like this. A lot of leaders will do the work themselves. They trust their teams more or less. There's sort of there's so many different ways to operate. But at the time, I remember we had like a pretty non-technical leader. And this was kind of the way to help her make decisions. I think at this point in your career, you had the most proximity you've had to senior management. it's you said you're reporting to a senior director at some point and you're involved in a lot of huge scoping conversations i'm curious what's the downstream effects of reporting to someone so senior like that yeah i think it kind of depends on the engineer and it depends on the company um so for example like you know now i'm at anthropic and i think at anthropic it doesn't matter um it doesn't it doesn't matter which level you report to there's some of the most senior people at the company report to line managers.

26:58Boris Cherny:A lot of the line managers are like XCTOs and things like this. So it actually doesn't matter. So I think this is kind of like a meta, it's a very meta specific cultural observation. I think there's sort of like two things going on. So one is you want at meta, you needed, as an engineer, you always needed to find scope. Some of this you can find yourself, and then some of it your manager helps you find, or your tech leader, the people you surround yourself with. And the PSE process is like grueling, like famously grueling at Meta. And so you just have to constantly talk about your impact and like scope is like the biggest contributor to that.

27:36Boris Cherny:Like if you have enough scope and you execute it well, that's impact, that's the formula. I think the other part was at Meta, no one had titles. So even the most senior engineers, their title is software engineer, which I actually really love. and um you know like bell labs had this with like member of technical staff and this is true at anthropic too but we actually go even further here everyone's title is member of technical staff it doesn't even matter if you're an engineer or a pm or a designer it's all the same title um and i actually really love it because back to this point of working outside your lane and doing stuff that just should be done and you know like are just good things to do regardless of what you are personally expected to do.

28:19Boris Cherny:I think this kind of culture just sets that up. I mean, I see a lot of the benefits of the no titles. I could also see a case though, where, and maybe this is only true for big companies, where you reach out to someone across the company and you say, hey, I'd like to, I don't know, do this collaboration. And if your title said director or whatever, it kind of is like a shortcut for them to understand how seriously to take you or how to interact with you like if you're a designer or some other role so i mean now anthropics got a bit bigger at this point do you see uh any of that i mean people probably all know you so maybe you don't see it as much yeah i think i think this is definitely the downside i think that upside outweighs it which is you have to earn trust and i think this is true like you know regardless of what company you're at, you got to earn it.

29:12Boris Cherny:And just because you did a cool thing before, it doesn't mean that you have, you should deserve respect. Well, everyone deserves respect. It doesn't mean that you should deserve authority at a new company in a new setting. So I think even for people coming in with manager titles, you kind of have to earn it. And in some ways, having a manager title makes it a little bit harder to earn this kind of trust. So as an IC, you got to do it either way. And I think just the lack of titles makes it a little easier. At this point in your career, you were kind of like becoming more and more of a tech lead or uber tech lead and I think you had a few stories where you scoped out work for hundreds of engineers and just thinking about how do you do that if there's so much to scope and you know you're one person how do you go about doing such massive scoping requests for leadership yeah this was a totally insane time so I worked a lot with Tina Schutman, who's, she's now a Microsoft, but she was my manager at the time.

30:08Boris Cherny:And then Yifei, who's my manager after. And there was a lot more investment going into Facebook groups at the time. So I think the org was maybe 150 or 200 people when I joined. And by the time I left to Instagram, I think it was like 600 or 800 people, something like that. So there's this feeling from Zuck that Facebook apps should be all about communities. And he just wanted us to go like faster and faster to make that a reality. And, you know, as an executive, your kind of biggest way to do that is to put the right people in charge of decisions and then to give them resources. And so like in, you know, in the case of meta, it's just engineers.

30:46Boris Cherny:You don't need like GPUs for this. You need like engineers to do stuff. And so we pitched this project to Zuck and it was called Communities as the New Organizations. That was like the internal name. And he ran with just like a bunch of headcount to go towards this. And so we just had to figure out what these people will do. and you know for him i i get it it's like if the thing is important you got to put a bunch of people on it in hindsight what i would have done differently is i i would have put way less people on it because what matters is like solving people's problems and building awesome product and this actually has to kind of be bottoms up and you kind of want to like slowly dial this up as you find product market fit for new product lines you can't just do it all at once and uh yeah we just had to like scope out all the stuff like there were weeks where i had to you know do like a scoping doc for like okay we're gonna put 30 engineers on this here's like three technical options we're gonna pick this one next project we're gonna put 20 engineers on this here's three options we're gonna pick this one next project we're gonna do and just like doing this like over and over again just to have like you know some some sort of confidence that this thing isn't totally crazy we did some baseline technical scoping roughly matching the number of engineers to the project and there's actually some pretty fun stuff like i remember we were trying to merge Facebook groups and pages at some point, like in the data model side.

32:01Boris Cherny:And this was this like very gnarly migration. It would have been, you know, to fully do it, this is like many years and like probably hundreds of engineers to fully do it. Because you have to do it across like the data model, the product layer, integrity systems, ad systems. There's just all sorts of stuff that has to get merged. And at the time, Yosef Karver, he just joined, I think he came from either profile or events, like a different org that joined forces with groups to make this happen and he was working on it but he was kind of struggling with a with a decision at the time and i think he was even more senior than i was but he just like wasn't making the decision on the data model and so i just took a bunch of people and i was like all right all the tech leads across the entire org we're gonna spend the next like three hours on this day and we're gonna do this like essentially like game where we get to do architecture and so i split everyone up into two teams i think it was like blue team and green team or i forget what these were and we gave everyone this problem of how do you merge these data models?

32:57Boris Cherny:Here are the requirements. And then everyone had three hours in a whiteboard and they had to come up with a design. And what was cool is that going into it, we had no idea how we would do this because it just seemed too crazy of a problem. But going out of it, we had two designs that were 80 % the same. And so it was really obvious what we could execute on. And then the 20 % where the differences were, it was very obvious where the risk was. And so we could kind of front load a little bit of that risk with a little bit of technical spikes. But also we can just start execution right away because we knew exactly what we had to do.

33:29Yeah, that was really interesting when I saw that. It was like a technical design competition with all the senior engineers and you just put people in separate rooms to come up with. I've never heard anything like that. When you proposed that idea for this design competition within the org, were people excited about it or was it like kind of a crazy idea?

33:51Boris Cherny:Yeah, it was sort of crazy. I mean, with this sort of thing, you just have to kind of do it. So I just kind of told everyone, hey, we're doing this. And then I just put it on everyone's calendar. And it just seems fun. You know, it's like as an engineer, you would want to do it. But I think this is the sort of thing where like sometimes you need consensus and sometimes you just have to act. And in this case, because the path wasn't clear, it was important to act. But at the same time, I didn't know how to proceed. So we had to kind of get everyone together to build consensus. And so I think it's like as a leader, you're kind of always juggling these kind of two things.

34:20After that experience, just giving, being given hundreds of engineers and scoping things out, do you have any tips for someone who's like a tech lead who's needs to do quick, you know, scoping, anything that worked well for you?

34:33Boris Cherny:I think the biggest thing, I think the biggest failure mode that I've seen is people just taking too long and getting too into the weeds. There's always an infinite number of details. Just start with a high level. You know, most technical scoping you can do within like 30 minutes, very, very roughly. And if you don't know the systems like nowadays you would just use quad code run in the code base and just ask it to like you know like what are all the systems involved they can actually just do this for you and this is another just totally insane change you know i when i was doing this stuff i never would have expected that ai could do this for me now um but now it does in the past i think that would have been my biggest advice though is uh just time box it spend maybe 30 minutes maybe like couple hours max if you have to like dig through code and stuff.

35:19Boris Cherny:Definitely reach out to experts and just make a list of experts. Talk to all of them. Run the design by them. Don't just ask them for input. Give them a straw man because then they can actually like give you feedback on it. And it's something to go off of. Continuing with your career story, I think the thing that got you promoted to senior staff or IC7 was public groups on Facebook. So I'm curious like the story behind your involvement in that and you know anything interesting that happened at that point yeah so public groups was one of these projects that came out of this uh this coping for um you know like making facebook groups more about communities there's this like one very narrow change that we wanted to make that seems so simple on the surface but it was so complex under it and it's just funny like explaining this to anyone that wasn't there they're like wait this is like a one-line change and i'm like no it's not it's like it was very difficult to pull it off and so the change was in order to participate in a public Facebook group you no longer have to join first so you're saying um you can just view like you have read access for all all groups essentially or public groups read access for all groups and for some groups even comment access so you can comment without joining first interesting and this is a thing you know it feels like a one-line change and actually was a one-line change but there's all these downstream implications that are so tricky.

36:36Boris Cherny:So one is, you know, in the data model, there's essentially a field in the database that was like group member. And we had this like really intense technical debate about like, these people that are commenting in a group, are they group members? And the model also changed where before to join a Facebook group, an admin had to approve you. So there's kind of a vote of confidence that you can be in this group. And then after we switched to this model where to join a public Facebook group, you just essentially press follow. And we actually went back and forth, should it be join or follow? What's the right verb to describe this?

37:08Boris Cherny:But it was essentially follow because there's no reciprocal action. If you follow a group, are you a member? Should you be stored in that same part of the database? And we just went back and forth on this for a while. And I remember at the time, there was this really senior engineer, Bob. He was kind of the most senior engineer in the org at the time. And he felt very strongly that it should not be the same thing. And he kind of pushed us pretty hard, even though it would be a ton of engineering work to migrate stuff to make it a different thing. And so we did this work because he was actually one of the early engineers on Facebook group.

37:40Boris Cherny:So he knew it really well. And he felt pretty strongly. There's a bunch of these other downstream changes around moderation and different new admin tooling that admins would need to handle the influx of spam and things like this. And I remember at the time thinking, if anyone can make a comment, the comments are just going to be filled up with spam. and I had a hard time kind of convincing people of this. And so at some point I built this like Monte Carlo, like visualization of how this would work. And it was just like this, like really simple kind of like scratch pad of, you know, like a comment comes in, there's a certain probability of it being good or bad.

38:13Boris Cherny:And then like what actually happens to comments. And I think that actually did a pretty good job of convincing the integrity teams to jump in and help with this. And so at the time the pages integrity team jumped in and they helped with a comment ranking because kind of ranking spam comments lower was the main technical mechanism to make it so people don't see these comments. So there's a bunch of these like pretty gnarly downstream implications of letting people participate. There's also this data model migration that we're doing. And so to do all this, we had to staff a big team to kind of make this happen.

38:44Boris Cherny:And so we hired a new director, Yamin, who hired a bunch of engineers. There's a bunch of internal transfers. So some of the most senior engineers from the org, like there was like Henry Long, Joe Cheetham. There's like a few other engineers and they were all working on this. And I was the same level as them. I was like a, you know, an IC6 at the time. And so were they. And I remember just feeling this kind of imposter syndrome of having to kind of direct them and kind of point them at work, knowing kind of in my mind that we're the same level. Even though levels are hidden, you kind of, you know, you know, through like rumors and stuff, who's what, you know, in hindsight, I think this was sort of like misplaced imposter syndrome.

39:25Boris Cherny:because levels don't matter at all. This is my current view. And, you know, some people that are very junior can shoot way higher than that and just give you amazing results. Some people that are very senior can give you terrible results. And so the level actually doesn't matter that much. But at the time, I remember just like really thinking about this and it was just kind of hard to step into this role. And eventually I did it. And it's funny, eventually the thing that got me the promo to IC7 was reversing this decision that Bob did because he wanted to do this big migration and we did it. And it was just like, dude, it was so much work.

40:01Boris Cherny:It was like six months or a year of work or something, just migrating just hundreds and hundreds and hundreds of call sites to do this correctly. And then technically I felt like actually what we did is we essentially just added an if else at every single one of these call sites. In the process, we audited all the call sites. We kind of knew that it was safe, but we didn't actually change the logic. And so So actually what we've learned is that, yes, member is the right field to model both followers and group members. This was the right decision. And so I pushed the same engineer that did this to then undo it.

40:33Boris Cherny:It was the right thing to push this engineer because it showed maturity on his part that he said yes and was able to do it. He also had the most context technically so he could do the best. and i think for bob it made he he felt better about me as a technical leader because he knew that i was wishing i was willing to pull back to push back on um decisions that even senior folks make um and in the end this was the right thing so we reversed the migration it also took a long time to do it but in the end it made it so everyone building on this infra could do it and everyone wasn't always constantly bumping into this like should i use this field or or this field yeah i'm curious about that part because you had a strong technical disagreement with bob or senior tl um but the outcome at the end is actually it seems like it strengthened the relationship he was a champion for you in your your promotion so i'm curious how would you recommend going about like strong technical disagreement in a way that doesn't hurt the relationship?

41:37Boris Cherny:I think the biggest thing is you have to earn it. Yeah, you just have to earn trust. And it could be as simple as you know, like what I did at the beginning, which is just disagreeing and committing, and showing that I'm willing to do that. And I'm willing to just execute. If someone else thinks it's a good idea, and I kind of look up to them. But also, you have to kind of show that you have good technical judgment. But you can't really do that until you're in trust. So take the time to get that trust first. And then on the imposter syndrome, leading those engineers that were also very strong.

42:09Do you have any advice for overcoming imposter syndrome?

42:12Boris Cherny:Yeah, just don't overthink it. You know, no one really knows what they're doing. You know, at any level, no one really knows. We're all just trying to figure it out. It's easier said than done. Was there like an aha moment where you realized, actually, maybe I do got this or this isn't that big of a deal? You know, I don't think so, really. There wasn't a single moment. And it just, it kind of goes away over time. And I think at every level, it doesn't matter what level you're at, you should always feel a little bit of imposter syndrome. Because if you don't, then you're not pushing yourself hard enough.

42:43At this point in your career, you were like more and more of a tech lead and therefore you were writing less and less code. And you mentioned that, you know, at Meta especially, there's cases where other functions are understaffed and you view that as an opportunity for engineers. So to be more product minded and maybe help out with the PM opportunities. I'm curious, when would you say that you should go that direction as opposed to escalating and say, hey, we need more PM support and trying to write more code instead?

43:20Boris Cherny:Yeah, you have to understand the tradeoffs. I think this is the thing that I think a lot of people don't really get when they push for stuff or you know i think a very common failure mode is an engineer will push for an idea and then get gets frustrated when no one else buys into it or wants to fund it or the organization just like doesn't listen or their leader doesn't listen but what you have to do is understand the trade-offs and whoever it is that you're trying to convince think of it from their point of view what do they care about what are the projects they're working on what is this trade-off against if they do this thing are are they going to see their work as a as a success so i i think i think that's really important and for some orgs that sometimes they might not have pms because it might just not be a very sexy project and so it might be really hard to hire and maybe the leader is already feeling that pain maybe for some orgs uh they are trying to hire pms but there's actually just much much more important things those pms should go to for other orgs they might they might actually have like too many PMs.

44:21Boris Cherny:And so actually, if you ask, that's the right thing to do. Because they could just take a PM off a less important project and put on your project because it's more important. So I think it's really important to kind of be situationally aware, understand the context you're in and understand how your decision makers think about it. At this point, and this is kind of the end of that part one of your story, you credit a lot of your success to, again, the side quests and like having these side projects or a running list of, you call them 20 % time ideas. And I'm curious, do you have any tips on how to find opportunities for engineers?

44:58Boris Cherny:Yeah, I think at some point there was probably, I forget the exact numbers, but there was probably like 50, 100 engineers or something like this that were just like working on these like side quests that I like scoped out and like spun out of various points. And so pretty much like every week I'll think of like some project, you know, just like on a run or something, or maybe like while I'm coding, I think of some idea. I'll just do some basic validation. And then I'll just ping an engineer that I know and be like, yo, are you interested in this? And then I'll connect them with a couple other engineers that might be interested.

45:24Boris Cherny:And this kind of added up very quickly. I think that for me, one way that I really think about my work is how can I do less of it? And as an engineer, our superpower to do this is automation. The most tedious stuff you can automate. And this is something that's like really hard actually for other fields. But for us, it's this incredible thing that we can do. And it's something a lot of engineers don't really do for whatever reason. But we should all be doing it all the time. It's so important. It's leverage. It's like free leverage. And so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue or something, I literally had a spreadsheet where I would tally up that issue.

46:07Boris Cherny:And I posted kind of the link to that pull request. And then I would do this for every code review. And then when I commented about the same kind of thing more than a few times, I would just write a lint rule for it to just automate that. So this is kind of an example of leverage. So and at some point I automated most of my code reviews because like I just had, you know, like a flock of lint rules that were just like doing all this work for me. And I think this is actually kind of similar because all these side quests, it was improving prod infra and dev infra. And these are things that slowed me down in my day to day coding.

46:37Boris Cherny:And this is why when I was doing less coding, this was actually very dangerous because as an engineer, you need to be anchored to reality. You need that intuition. And if you're not in the code anymore, then you lose it very quickly. It's a very dangerous place to be in. And so for me, when I was in the code a lot, there was all these really cool ideas that came out of it. And it was leveraged not just for me, but for the whole eng team. Because, again, of this principle that if you have a problem, probably other people have it too. And, you know, I did like YC back in the day. And in YC, they teach you that first you build for yourself.

47:08Boris Cherny:You have to build like awesome stuff. You have to build stuff people love. But if you're trying to find a market to build for, you start by building for yourself. And that's a pretty good indicator. Other people probably have that same problem. Yeah, there was a quote that you wrote. I thought it was really good. You said, better engineering is the easiest way to grow your network and gain influence as an engineer. So I could totally see you had like your scope of influence was so much further than just the code you're writing because you're passing people all these great ideas and you know overseeing them it's the the leverage is really insane absolutely yeah and and it's also just like an example of being contextually uh was it situationally aware um because you know i met at the time engineers were evaluated in the performance cycle uh we looked at project impacts people do you remember the direction direction and eng excellence and eng excellence yeah and And the eng excellence is a thing that a lot of engineers struggled with.

48:05Boris Cherny:And so I was one of the people that came along and was like, hey, if you want to do eng excellence, here's a project. And people are already incentivized to do it, so they see it as an opportunity. And I think this is just like, I don't know, I think it was a chance for me to kind of hone my skills about working with people. Where you never, ever want to tell anyone what to do in any context. In a personal context, in a work context, everyone hates being told what to do. But if you understand what a person wants, then you can go to the right person with a right opportunity and they see it as an opportunity.

48:36Boris Cherny:And this just always works better for everyone. When I think about these 20 % time ideas, I mean, there's the top of funnel finding the ideas and then there's actually executing on them, getting someone to do it or whether it's yourself or someone else. The thing I'm interested in is the top of funnel. How do you source so many ideas as an engineer for these side quests that are impactful? Just common sense. I don't know. Maybe spidey sense. I don't know the right word. Like how so? What's a concrete example? Yeah, a really concrete example is, I think wind rules are a good one. Maybe another one is there were all these cases where we had SEVs because Facebook groups were not being tested with very large sets of Ahsoks.

49:29Boris Cherny:And so like, for example, and Ahsok kind of like, this is kind of like a Facebook way of saying like, you know, rows in a database. So you could imagine like a Facebook group with like 10 million members. Like no one's ever tested this. There's no like unit test for this. You only see it in production. And when I looked across the org, I started seeing similar cases of this. There's, for example, like if you have a profile with like 20 million followers, a lot of stuff breaks, but obviously like no one tests this in an automated way just because it's kind of annoying to write a unit test with this much data.

49:57Boris Cherny:And so there's a bunch of instances of this. And then I pitched an engineer to build a way to write unit tests for large data sets. So, you know, like a really big object, like a group with a lot of members, a profile with a lot of followers, an event with a lot of attendees. And I think this infra still exists. And it's, you know, prevents a lot of issues. And this is something where you can scope it. And then he brought in a bunch of other engineers to do the work and help him out with it. So I guess just think about the problems that you actually hit day to day. Got it. Okay. So think about the problems.

50:28And if you're experiencing that problem repeatedly, then it's time for automation. And that's like a great, better engineering project.

50:36Boris Cherny:Yeah, exactly. Exactly. Like if you hit the same problem, like two or three times, you should probably kind of look around and see if other people are hitting that project, hitting that problem too. The last leg of your career at Meta, this is where you got the e8 promo i know that um you moved orgs so you did all of your growth in facebook groups and then you moved to instagram i'm curious uh what's the story behind you moving orgs to instagram at the time um i was dating my wife and i were still uh dating and she was living in berkeley i was living in sf and at some point she's like i found my dream job and I was like sweet awesome and then she was like we're gonna have to move and I was like okay great we've been dating like three months at the time and uh we were kind of deciding why should we like keep dating and um and so she was like yeah we we would have to we'd have to move if you want to like keep dating and I was like yeah okay I do let's let's do it and then so the job ended up being in like rural Japan like it was sort of like middle of nowhere and I was trying to figure out like how do I do it because I really like the work that I was doing and so first I talked to like Facebook groups leadership and tried to set up like a Japan office out there for for Facebook groups that didn't really work for you know a bunch of kind of organizational rules then I tried to do this with the VR org and it was actually working but then the person that was sponsoring it left to go to I think like YouTube or something and then at the time Will Bailey reached out and he was in the Instagram Tokyo office he was part of this like landing team for for Instagram and he was like hey I kind of want to grow this office do you want to be part of that and I was like yeah let's let's do it and I didn't know anything I I didn't even have Instagram installed at the time I'd never used it in my life and um I so I I said yes and then I immediately downloaded Instagram and then like I moved like I think like the next week or something um so pretty much or or actually you know i think it was like a few weeks that i had in the u.s but i moved out pretty quickly and i actually really fell in love with the instagram culture it was very different than facebook culture a big emphasis on building awesome products on on shipping stuff that people don't use on thinking about things not just from a data point of view but also from a human point of view and an experience point of view and you can see this in the app and in the craft that goes into it.

53:03Boris Cherny:It's just completely different engineering and product and design cultures between the two companies. So I learned so much being on that team. And that was such a fun journey. You mentioned the unship part. What is that? Unshipping is the idea that if you just add features to an app, it's cool for some small percent of users, but it's actually bad for most users that don't use the feature. And so you can think of an app where you only add features to it and over time the features accumulate and they add up and you know if every feature is used by like 10 percent of people the average user sees a bunch of features that they don't use and so it seems cluttered and confusing and when they open the app they don't know what to do and uh you know like with software fundamentally the screen is a limited size that's the limited real estate uh there it's a limited resource that all the different features are competing for and so by adding a feature that's taking the opportunity away from a different feature the person could have used.

54:03Boris Cherny:And so unshipping is the idea that you have to meet some sort of usage bar. And if a feature doesn't meet that bar, then we just delete the feature. And a small percent of users are going to be pissed. But it's actually great for the majority of users. And on average, it's really great for everyone. At this point in your career, I mean, you didn't just move orgs. You moved across the world to work at Instagram. and I think when you're such a senior tech lead with a lot of credibility in your existing org, it's much easier to get things done or at least influence others because they say, oh, I know Boris and I know his past work.

54:40But I'm curious, how did you build up credibility at Instagram when you were so far away from everyone else?

54:50Boris Cherny:I think a lot of the credit early on, this goes to Nam, Nam Nguyen. He's still the VP of Avenge at Instagram. and Jeff Huang, who was my director at the time, but now he's a VP. And, you know, Will, I think there was a lot of connections made by these people. So, you know, for example, Neum was like, hey, you really like doing, you know, working on code quality and like tech tech reduction, you know, which we call, you know, better engineering at Meta. And he kind of connected me with the people working on it. And this was like Lucas Camera and Gabe and a bunch of this, a bunch of these other folks that were working on this stuff.

55:28Boris Cherny:So those connections were really useful. And then I think a lot of it was I just had to earn the trust again. And honestly, this is a healthy thing to do. And I think this is one of the really awesome things about meta engineering culture, that there are not titles. And so you kind of have to constantly re-earn your trust. And even if I was a great engineer in the past, I may not have been a great engineer at Instagram. And if I wasn't, then I don't deserve influence. I don't deserve to have a really loud voice that people listen to. So I had to earn it along with everyone else. And so my first few weeks, I spent a lot of time like meeting people, mapping out the org, mapping out goals, writing a lot of code so I can get to know the code base.

56:09Boris Cherny:But then in Japan, it was totally different because, you know, like 4 p.m. Tokyo time was like or it was like 9 a.m. Tokyo time was like 7 p.m. New York time. There was just like no time zone over. It was rough. Yeah. But it was also great because I think in the few years before I was doing so many meetings and docs and all this stuff, I just wasn't coding. So I just started to feel pretty unhappy because like as an engineer, we code. That's what we do. Like that's the reason we picked this job is like for me, like when I write code, I have an emotional relationship with the code. And it's something that I think about when I'm really deep in a problem.

56:46Boris Cherny:I dream about it. So it's just so important for me to code. And when I wasn't doing this for years, it was sort of rough. And I think I was starting to burn out of it. And so actually, it was a gift to be in this time zone where I literally couldn't do meetings because people weren't awake or didn't want to do 9 p.m. meetings just to talk. So I didn't do any more one-on-ones. And this is actually still something I don't do. So I still don't do any standing one-on-ones. And I just could spend a lot of time coding. And what I realized is I was one of a few engineers at Instagram at the time that was coding this much.

57:20Boris Cherny:And, you know, people code, but people don't code that much because there's all the stuff that fills up your time. There's meetings and, you know, docs and all these other obligations. And I was able to do a lot of stuff that I think everyone else wanted to do, but just didn't have time. And this was kind of a superpower in that org. And pretty early on, Nam connected me with Joe Pamer, who's still a good friend and mentor. and he's at Google now. And we just started talking about like, at the time the code base was written in Python and it was sort of rough for a lot of different reasons. And really the code base should have been moved over to Hack, which is the main Facebook monolith.

58:06Boris Cherny:And this is where all the language support is. There's so much infra. HHVM is just this absolutely phenomenal web serving stack. There's nothing else like it in terms of like efficiency. If you're using GraphQL, you absolutely have to use it because it's just so optimized for this stuff. And Instagram just wasn't using any of this and engineering was suffering. Like in the really early days, you know, like when like Mikey was at Instagram, really basic decisions were, the basic principle for decisions was do the simple thing that works. And this worked really well, but then at some point it stopped working.

58:37Boris Cherny:Once you get to like a thousand engineers, 2000 engineers working the code base and, you know, many, many years of tech tech and products built on top of each other, you kind of have to do, you have to make slightly different decisions than you would have made at the start. And so even if Python was absolutely the right decision at the beginning, it was not the right decision by the time I was there. And this was painfully obvious as an engineer. And I think a lot of other people saw this, but what stopped them was just the amount of work it would have taken to move this stuff over. And so I just started like scoping this and kind of figuring out what it would take.

59:08Boris Cherny:And so I started by finding the people that would disagree the most. And there's a bunch of these like infra old timers that just thought this was like a terrible idea. and would never work. And so I went to talk to them first. I like food in New York and, you know, we got a bunch of beer and just got to know them as people before we even talked about the technical problem. You have to build trust. So I had to kind of get to know them as people. And this was so valuable. And this is still a lot of my friends today. And after building this trust, I also learned there was a bunch of other people that actually did want to do this and were kind of afraid to say it.

59:40Boris Cherny:And so these people came out of the woodwork too. And eventually we started scoping this and this project kind of spun out and it's actually still going today. And there's, you know, many engineers working on it. But it's funny because at Facebook, I think this kind of problem rarely happens because the org is so engineering driven. At Instagram, there were many problems of the shape because the org is very product driven. So there isn't just a lot of time for those engineering driven initiatives. This project at some point, I mean, you got it off the ground, kind of this bottoms up initiative.

1:00:09And then at some point it became high pry enough where it needed that in-person support of someone that wasn't in Japan. And I understand that Jake Bullam is someone that you helped onto the project. And he kind of took more of a lead role, but location-based and close to everyone else. So he can help shepherd it along. I'm curious your thoughts on that point of delegation. Like, when do you decide when to delegate something so big? And when do you decide, oh, I need to still be around? and how do you navigate that trade-off?

1:00:43Boris Cherny:Jake is amazing. We're friends. Every time I go to Seattle, we hang out and he's just one of the best engineers I know. So it was obvious that he would be a good owner for this. The same rules of delegation apply as always. So you never delegate the thing you don't wanna do. That's kind of the most important rule. You always delegate the thing you do wanna do and that you know well because then you can monitor the progress and make sure it's going well. And there's this really great book, High Output Management by Andy Grove. He was an old Intel CEO. And it's just like the most boring sounding book ever, but it's just like the best.

1:01:18Boris Cherny:And this is one of the pieces of advice is delegate the thing that you like to do so then you can monitor progress. And so, yeah, it's kind of the same thing. You kind of delegate a little bit, you check in, the more trust you have, the less you have to check in. And with Jake, he's so good technically and so proactive. There was just very little I had to do. It was very much on track from the start. And so I think this coupled with some other work, large migration to kind of GraphQL or modernize some of Instagram data model ended up getting you promoted to this principal level before you left Meta.

1:01:51What was the story behind the promotion or anything that you might share?

1:01:56Boris Cherny:That promotion, I think in a one-on-one that I had with Will, my manager, he was like, hey, like, I think you should like, we should put you up for IC8. And I was like, cool. and that's pretty much it i hadn't really thought about it yeah it's not something i really asked for um i think will was just like does a great job of recognizing people and kind of advocating for his team and he felt that i was ready and yeah that was that at any point in your journey because it sounds like you were impact and impact only and growing and your leverage and your credibility everything was growing and then the promos were this lagging thing where they just oh, they kept happening as a byproduct.

1:02:35I'm curious, though, to structure your thinking about how to get more leverage or kind of have more impact. Did you ever think about the levels? Or would you say that it's not good to think about like, oh, what's the next level? More think in terms of just, I don't know, leverage or impact or something else?

1:02:56Boris Cherny:You have to think about what levels are for, right? Levels exist so that the company can communicate to an engineer what it is they expect the engineer to do. It also exists so that there's some accountability. So for example, in performance reviews, the engineer at a particular level, you can compare them to another engineer at that same level. And also sometimes on the finance side, different engineers or, you know, the PID costs a different amount. So you can kind of think about what kind of portfolio you want. So, you know, levels, it kind of exists for company reasons and not for engineering reasons.

1:03:26Boris Cherny:And for me, it's just never the way that I thought about any of this. Like the thing that I like to do is work on interesting projects. I like to figure out the problems and solve them. I like to just make the things that people use delightful, like the products that they use delightful. This is what really motivates me. So for me, this was just never really the way I thought about it. And I don't know, like my first week at Facebook, I was like an IC4 and I had like all these ideas for stuff that we should build. And so I just started writing like product briefs and then i remember i went to like the vp of like connectivity and like pitched him some idea and he just didn't understand it at all and thought it was terrible and then like that didn't work and then i had another idea for messenger and like i went and like pitched that and like they also like didn't do it but then they actually did end up building it a couple years later this particular idea so yeah for me it's just like you know what are what are the cool ideas and like how can i help and who else is interested in this stuff and how can we build build cool stuff you left meta to go to anthropic and i'm very curious what was your thinking about going to anthropic i remember using chat gpt for the first time when it came out this was uh you know this was like year years ago and i remember i was i was in japan i was the only engineer in my town i was the only person that spoke english in my town and there's just no one that i could talk to about tech stuff and i remember every every morning i read hacker news and I remember using ChatGPT and I was just like blown away by the product and just this feeling that it gave me of just nowadays we take it for granted but you know LMs are just magic it's just this absolutely incredible technology and I think now my view of it has shifted it's like to me it's LMs are this kind of alien life form that we get to nurture and we get to bring into existence it's not just a technology.

1:05:16Boris Cherny:And I'm also a really big reader. I read a lot of sci-fi. That's kind of my big genre. And so at the time I was like, oh my God, I have to work on this stuff. And what are the labs that are working on it? So I went to talk to friends working at various labs. And I feel like when I came to Anthropic, I remember my first lunch, this was with Ben Mann, who's one of the founders here. And we were sitting at lunch with him and a bunch of other people and i mentioned this like weird like sci-fi book that i like uh it was i think it was like by greg egan or something it's like hard sci-fi author and i've literally never met anyone that's read this book and at the table i kind of gave an anecdote from it and everyone around the table was like oh yeah yeah that book was good but like what about this other book and so it was just like this group of people of these like intense sci-fi nerds these people that think so deeply about these same problems I care about.

1:06:07Boris Cherny:And I think the other part for me was how you're reading a lot of sci-fi, you kind of get a sense of, you know, in a very speculative way, how this thing can play out. AI is just so transformative to society. I think it's hitting engineering first, and it's going to hit every part of society. It's going to affect everything. And we're seeing the very first waves of this right now. And I think I just, you know, like I read enough that I kind of knew the bad ways that this can play out and there can be so many ways this thing goes wrong and so for me anthropic was just the obvious choice because i wanted to be at a place where in the tiniest way i can make sure this thing goes well which is as an engineer this is all i can do um and it's funny i think like before i joined i sort of took safety seriously like you know it's like a thing that can happen and you know at meta it was always seen as this kind of tax where integrity teams and you know and so on they kind of like they get you to do stuff but it's not really the thing anyone's really excited to do because it's not the product and so this was kind of my view of safety before but at the same time i kind of speculatively knew that it could be kind of a very different thing and now being at anthropic i know it's completely different and i see every model that comes out and kind of the new risks that come with it and how as a company, we put our money where our mouth is, you know, in terms of like how much compute goes to safety research and alignment research, in terms of like how many people work on this.

1:07:31Boris Cherny:We've held up model releases in the past, because we did not know that they were safe. And so we had to make sure that they're safe before. And I think also like with Opus 4, the risks just went way up. Like if the model can design, you know, like bioviruses and can do these things that are like really really dangerous and it's not just like you know like the baseline risk is something like election manipulation this is something that you know like at meadow was a really big deal this is sort of a risk for kind of a low-level model as the models get more dangerous the risks get higher and very quickly you get into this territory where people can use the model to build things that are actually dangerous for humanity like not not just like you know like uh you know politics in a country but like literally the existence of humanity um and these this is not sci-fi this is a real risk today that we actively have to fight and so for me just like getting to be a part of this and getting to contribute a little bit this this is just what put me over what about when you joined when you think about the engineering cultures that you came from compared to anthropic were there any really jarring differences yeah i would say the two things one is still being a startup there's a lot of common sense and it's funny i think this is something every big company loses.

1:08:46Boris Cherny:And it's sort of this thing you have to fight. Because over time, the decision makers get more distant from the impact of their decision, whether it's the product or the people or whatever. So you have to come up with all sorts of processes to bring them closer and to improve the quality of decision making. But still being at a startup, everyone just has common sense and generally just does the right thing. So I don't have to spend a lot of time convincing people to do stuff. If we should just do something, it's obvious and everyone just does it. I think the second thing is, for me personally, something that I learned over time motivates me the most is mission.

1:09:20Boris Cherny:It's so important. And it's the thing that keeps me going to work every day, excited to go to work every day. It's the thing that makes me code on the weekends because I want to do it, not because there's a deadline. And so I felt this a lot, actually, in Facebook groups. It was very mission-oriented. And for a long time, Jen Dolsky was the VP, and she used to be the CEO of change.org. And so she ran all the Facebook groups, like a nonprofit, she had like a theory of change. And this theory about how you want to connect people to like minded people to form communities. And it was just so motivating to work on that.

1:09:52Boris Cherny:And I feel like at Instagram, you know, maybe because of the geographic distance, or maybe something else, I just never quite felt that same mission. But I feel like at Anthropik, I feel that so strongly. And that's probably the most exciting thing for me. I know that you know you're credited as the creator of CloudCode and I think you've you've told that story in many places but I'm kind of curious I was talking with a friend about what the environment was like when CloudCode came and there were actually a lot of competing existing tools that hooked into the model and I'm curious what is it that was different about CloudCode that kind of won out and just caught like wildfire internally?

1:10:35Boris Cherny:At the time, coding looked very different. If you thought about AI coding, people thought about like autocomplete. That was essentially it. I think there was like some very early agents, but it was kind of a secondary thing next to the autocomplete. And oftentimes it was used for Q &A. It wasn't really used for coding. And so when people thought about AI for coding, it was just a completely different product that you imagined. You know, it was like tab to autocomplete. And I thought that's what it was. And I thought that was kind of the state of it. And then Ben, who was my manager at the time, he pushed me to think a little bit bigger.

1:11:14Boris Cherny:And he, I think, really internalized because he was there from the beginning of Anthropic. And he was at other labs before. And so I think he really understood the scaling laws kind of internally about how quickly the models are improving. And so he actually pushed me really hard to be like, don't build for the model of today, build for the model six months from now. And so honestly, for a long time, quad code was not a great product. And even when it was used internally, I used it for maybe like 10 % of my code or something like this. You know, I use it sometimes, but it really just can't do most things because the model is not capable enough.

1:11:47Boris Cherny:And then at some point we released Sonnet and Opus 4, and I think this was maybe March of this year. And the product just worked. and we saw this in kind of the usage data and I saw this in my own coding. I started to be able to use it for probably like half of my code. And this was totally borne out because this was actually like literally six months after starting the project. This was the timeline. And at this point, most of quad code is written using quad code. I think it's like 80 or 90%. If you look at teams at Anthropic, there's some teams that 90 % of their code is written using quad code.

1:12:22Boris Cherny:This is not just our team. And if you look at the impact on productivity, even though Anthropica has tripled, I think, since the start of the year, productivity per engineer measured in, you know, like, we were talking about this before, has grown like almost 70 % per engineer because of quad code. And so, you know, like, as a product person, I usually think a step ahead. And I think being at a lab, you have to actually think kind of differently. You have to think a step ahead, not two steps ahead. but also you have to be really aware of the model and kind of the exponential that we're on. Did you see the recent interview with Karpathy?

1:12:57Boris Cherny:I haven't had a chance to watch it yet. Okay. So one thing that he said in the podcast was kind of like, you know, pushing back a little bit because basically vibe coding, although it has a lot of miraculous results because of what it can generate, there's also a lot of like, he said like slop or, you know, there's like some drawbacks. So I'm curious, how do you think about that when the model produces a lot of code, but maybe it's not exactly how you'd like it, or maybe the end result has some non-obvious problems with it? AI coding is a tool like every other tool that we use, and you have to learn how to use it.

1:13:39Boris Cherny:So I think one of the most, you know, Karpathy, obviously, he knows how to code. I think a lot of people that are new to this kind of tool, they tend to just ask it to do stuff that's a little bit too big, or they hold a different bar for the model's code versus their own code. And so something that I do for the team is for the quad code team, we have the same exact bar, regardless of whether the code was written by the model or by a human. And so if the code sucks, we're not going to merge it. It's the same exact bar. And you just ask the model to improve the code and make it better. I think there's also kind of different ways of wielding these tools.

1:14:11Boris Cherny:Sometimes you want a vibe code. And this is really important for throwaway code and prototypes, code that's not in the critical path. And I do this all the time, but it's definitely not the thing you want to do all the time because you want maintainable code sometimes. You want to be very thoughtful about every line sometimes. So the way the problem, depending on the problem, you want a different approach. And so there's like a set of approaches that I'll use. Sometimes I'll vibe code stuff. This is actually quite rare. it's actually mostly for like prototypes and things like that that are throwaway code usually I pair with a model to make to write code and so first we align on a plan you know so this is like shift tab and plot code to get into plan mode and first the the model will make a plan then I'll see the code and then I might ask it to improve the code or clean it up or so on but it's a very involved process I'm pairing with a model we're working together to write this code and then sometimes I'll still write the code by hand so you know there's some parts of our core query loop where I have very strong opinions about like, you know, things like the names of parameters or kind of like on which particular line of code is, some code is.

1:15:18Boris Cherny:And so for this, I'll still write it by hand. I think the thing though is the models, I think are still overall not great at coding. I think there's still so much room to improve and this is the worst it's ever gonna be. But it's just insane to me to think a year back where the state of AI coding was, you know, like type ahead. And it's just a completely different world. And you sort of think about like where this is headed and kind of what's about to happen and what this looks like over the next few months and few years. And yeah, I think for me, what keeps me really excited about it is just having the context about this trajectory that we're on.

1:15:56When people hear cloud code, they think about coding, but there's many use cases outside of just software engineering, like querying data for like data scientists what are your thoughts when you think of

1:16:09Boris Cherny:cloud code for everything it was the craziest thing when i walked in i remember walking into the office like maybe it was like six months ago or something and our data scientist brandon had cloud code up on his computer he like sits next to us and i'm like dude what are you doing are you like trying it out and he's like no no i'm like it's like doing my work i was like what so he like he figured out how to like use a terminal and like how to install node.js and then he installed cloud code and then it was writing a bunch of sql and like doing analysis for him and now when I walk by kind of the the data scientists that sit next to us every person has like a bunch of quad codes up at the same time it's not just one anymore and they're doing all sorts of stuff they're like writing SQL and you know kind of crunching data they're writing dbt pipelines and they're writing code so I think there's all these applications outside of coding and it's just so cool to see how people are using this for all sorts of stuff.

1:17:04Boris Cherny:And there's even totally non-technical users. Half of our sales team at Anthropic uses CloudCode to do their work. They can connect it to Salesforce and they can connect it to different data sources and they can do their work this way. So it's just so cool to see. This is not how we designed it. This is not the intent. When I hear Cloud Code, I also think of Codex, one of the biggest competitors. And I'm curious, what are your thoughts on the competition with Codex and OpenAI? What does Cloud Code do better? And also, I'm curious, like the stickiness of these AI products, like, you know, what keeps people in Cloud Code versus Codex, for instance?

1:17:44Boris Cherny:You know, I'm not totally sure. I don't, at first of all, I don't really use the other products. okay for me you know like the thing i tell the team is like it's so easy to get sidetracked by you know looking at competitors and i think this is something that i saw that big companies fall into this failure mode a lot where because there's so many competitors and it's so easy to see the thing you could build by just you know copying it it's a little bit harder to come up with novel ideas and things that solve the user need better. And so the thing that I try really hard to do, and the thing that I nudge our team to do, is don't get sidetracked by all these other products.

1:18:24Boris Cherny:There's always going to be a lot. And the more there are, the bigger a sign of success that is for us. And the thing we stay laser focused on is solving our problems and solving anthropic researchers' problems and solving our users' problems. Coming to the end of the conversation, I just want to ask a few career reflections. One thing I was curious about when I was looking is that you didn't have a CS degree or a computer science degree. And you've become such a strong software engineer. And so I was curious, is there any part in your career where it might have held you back in any way? Or do you think it's not necessary or relevant?

1:19:03Boris Cherny:Yeah, I studied economics and I actually dropped out to start startups. Um, you know, for me, anything that you do, you learn on the job. And I think programming is just such a practical skill. I couldn't imagine, you know, the kinds of things you learn in school. And like, you know, if you're, if you're like in a data structures class or something, you're like learning this, but you haven't like built a product. How is it relevant at all? Um, so I don't know. I think my recommendation would be to people like learn coding practically. It's a very practical skill. and then if you want to go back and learn the theory after go do that but personally I've never felt like it it's helped me back at all what about productivity tips so I saw that you said you work roughly nine to six every day and you only type with two fingers but your output is ridiculous I mean you have all these side projects and of course your main stuff's no joke so what's your top productivity tips or how do you maintain that yeah I think I think nowadays my tips are very different than what I would have said a couple years ago.

1:20:05Boris Cherny:Nowadays, the tip is just learn how to use quad code and learn how to run a bunch of quad codes to do stuff. Like, you know, we launched plugins like a couple weeks ago and Daisy, who's one of the engineer that built it, she just had her clods like set up a Asana board, make Asana tasks. And then she had a swarm of like 20 clods just like build plugins over the weekend. And, you know, she ran it in like a Docker container, or dangerous mode. And it was done after a couple of days. And this is the kind of thing that is the future of engineering. And I think nowadays, when we talk about tips for productivity, it's learn how to use clod in order to automate toil, and also how to use a bunch of clods together to do work so you're kind of orchestrating instead of manually writing code.

1:20:53Boris Cherny:I think years ago, my tips would have been really different. It would have been a lot more prosaic than that, you know like about like blocking off time and things like this yeah it's it's interesting with cloud code i wonder what that does for you know the famous um like maker's schedule versus like manager's schedule it feels like what you just said is that software engine is becoming more like a manager's style of working where you got a fleet of these cloud codes and you're not you don't need deep focus to move forward you need context switching across like 20 different things. So do you no longer have big focus blocks for coding or what are your thoughts on that?

1:21:33Boris Cherny:Not as much. I tend to code on the weekends also. So I love the quiet time. But yeah, otherwise I'll kind of start every morning. I open quad code and, you know, like the mobile app, it's like, there's like a code tab in quad now. We just launched this this week, but we've been kind of using it for a while. And so every morning I wake up and I start a few agents to just like start my code for the day. And it's crazy because if you'd asked me like six months ago, if this is how I would code, I'll be like, no, are you crazy? How can you code in this way? But it actually works. This is here and it works.

1:22:03Boris Cherny:And this is how I write a lot of my code now. And I'll start a few agents. Then when I get to a computer, I'll kind of check in on the status. Sometimes I'll just merge it if the code looks good. Sometimes I'll pull it locally and kind of teleport to edit a little bit um but yeah and i think like you're gonna talk to fiona later and i think for her from what she told me she hasn't coded in you know like a decade but she's writing code like multiple times a week now because as a manager even though her schedule is insane she can still use the mobile app and she can use web and you know she can still open a terminal to just kind of write and write code for her um so yeah it's it's just crazy like we get to live through this transition where the thing that we do and like the thing that I grew up on it's just totally changing and yeah it's just so cool like it's becoming accessible to everyone and then last question for you is knowing everything that you know now in your career if you could go back to yourself when you just entered the industry and give yourself some advice what would you say just use common sense I think there's a lot of stuff in a especially in big companies that pulls you away from common sense there's a lot of this like organertia things are this way because they have been this way there's a lot of misaligned incentives there's a lot of good things but there's these things also so it's just really important to use common sense for this and you know early on in my career I was kind of starting a bunch of startups and worked at a lot of startups.

1:23:38Boris Cherny:And I think there are two, it's the same thing. Kind of use common sense to figure out what the market wants and what users want to build it. So yeah, just like trust yourself and develop your common sense. Awesome. Well, thank you so much, Boris, for your time. I really appreciate it. Yeah. Thanks. 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.

1:24:16I 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.