The 2% of Engineers Winning the AI Era (Ex-Meta L8)

[0:00]Today we're speaking with Kun Chen. Kun, thanks for showing up today and having this conversation with me. Thanks for having me here. Yeah. Absolutely. How did you know that you needed to leave Microsoft and then go to a different company? The year I was at Microsoft and I decided to jump to Facebook was the year where I realized I was not growing much. I think people wait until they are not getting promoted to realize, "Oh, I'm not growing." I think that's a very lagging indicator. I think actually we can tell [music] are we growing much much earlier. The way I could tell I was not growing was by asking myself, "What did I do this month that I couldn't do last month?" And I think there were a few months where I couldn't give me a good answer. I felt like I was doing the things I have been doing. I already knew how to do this. Maybe I can keep doing things like finding ways to do them faster and better. Yeah, of course. But largely speaking, I'm doing the same things. And that's where I realized, "Oh, like I'm not growing here." One way I could solve that was to work with my current manager and find good opportunities to like stretch my muscles, right? But I think I chose to just acquire a completely different experience. I felt like that would allow me to learn more. And back then Facebook was like their stock was growing really well. They were setting up in the office in Seattle and a lot of people were talking about them as a really exciting place. So I said, "Yeah, let me go have a try." And yeah, that was probably like one of the best decisions I made. Both financially and also just personal growth I think was really beneficial. I love that test. What's the thing that I can do this month that I wasn't able to do last month? I think the the time period is really important there. I think people get stuck in this daily thing or they're only reflecting on a yearly basis. But I love this month thing. I'm like thinking to myself now like what am I I Like right now like what what can I do this month that I couldn't do last month? That's a great test. I'm going to steal that. Yeah, [laughter] especially I think even how fast things are moving now, I think people should continue to compress that time frame. AI like it's changing all the time, right? The tools that people are working with like a year ago were totally different. Like maybe not totally, but very different. The popularity of the tools, the usefulness of them, and tools themselves are evolving as well. So, I think yeah, the world is just changing very fast and we should constantly ourselves. Like are we actually stuck in a place where we are not learning much and we should make some changes. It doesn't always require changing the company or like the whole role or the the position or whatever you do, but I think it's worth asking the question to find out what are some of the changes that we can make. You are one of my friends that has probably one of the fastest career progressions that I've ever witnessed. So, I think you were at Microsoft and then Facebook and Microsoft and a couple other places, but what level were you at at Facebook? I got to E7. You got to E7. Okay, and then your partner level at Microsoft. And I think you're like 5 years younger than me or something like that. Like how did you do that? Yeah, I think to explain my journey, I probably need to start with like all the way from the beginning. I started coding and building stuff very early. I think it was like before I was 10 years old, there was this summer break where I stayed home by myself and my mom got her laptop from work and she just left the laptop at home and I had no other things to do. I just started playing with the laptop and there was like I think there was Photoshop or something installed there. Got me so interested. I I had nothing else to do, right? So, I just played with all kind of stuff I can find on the laptop. I started playing with Photoshop, started to like really get fascinated by what you can do. From someone who's never played with computers before, it It fascinating. So, I started doing more and more. Uh and then there was this summer camp uh at my elementary school that uh taught programming. Back then I had no idea what it was. I just went to uh the teacher and like look at him and say, "What can we actually learn here, right?" Uh my parents and grandparents were trying to decide, "Do I go there or not?" I uh talked to the teacher and the teacher just said, "Hey, look at this game I'm playing. I built it. You can build it too if you learn programming." I got very interested. Uh that was like a really good hook to get a kid into programming. So, I started to take the lessons there and it was interesting like the whole 2 months of learning programming. No one had access to computers. It was learning from uh whiteboards and writing on paper and the teacher will compile it for you and try to run it for you and get you the results because like computers were like not that common like as a resource uh that everyone has access to. So, Okay, so you learned how to program on with a pen and paper. Yeah. That's amazing. Yeah, so it was writing basic. We wrote variables. We wrote more and more complex flows. And at some point I think uh it was like at the end of the the 2 months of the summer camp, I finally got access to the computer where I can actually enter a program and run it. Uh it was just so super interesting and I got more and more into it. After the summer camp, I started doing like going to some competitions and and computers became more accessible and more common as well. So, in uh my I think my high school, there was a lab where everyone can just go and play with it. Uh so, I just got into it more and more. I built stuff. I I just loved building stuff. I think I went to a bookstore at some point uh when I was in high school and I got this book called How to Build Your Homepage uh something like that. And it was teaching you to use Notepad to write HTML character by character and I followed the book. I built a website. There were these like free web hosting services back then and I just took one of them, hosted by website, and showed other people. It was just like really exciting and interesting journey. So, that's got me into like more I would say more advanced like less academic just going to competitions like doing those basic Pascal like those kind of programming but more into actually building things. I built websites, I built apps and I was playing a lot of video games Counter-Strike like all those games spent so much time. Playing games was one of the things where I got a lot of interesting opportunities to like see how other people play as well and how other people cheat and people like to cheat and because of the knowledge I had about like computers how they work how the software how the games work, I could build cheating like software. So, I built a few of them and I I actually sold them for money. Like Counter-Strike? For an MMO called Dragon Raja. Like not sure if anyone's going to remember that but it's it's still it's still running. It's a game where they had a lot of design flaws. So, a lot of the calculations were done on the client side and the server would just trust that. So, like just opens up a ton of opportunities to cheat. I wrote a bunch of software like where you can pretty much like just let the software run and it will do farming and those things for you and you get resources. What was your education like? Did you go and do computer science like the traditional route? Yeah, yeah I went my major at college was computer science and I spent 4 years there but I didn't actually I feel like I didn't learn too much from the college. I was just building stuff on my own at my dorm room with a few other folks. I just build and build. I think most of my experience came from there. And then at some point I think I was third year of my college I got an internship at Microsoft. So, Microsoft came to our college and they run a test where everyone can just go there and take a test and if you're good enough like they take you as an intern and I became an intern at Microsoft spent like a summer over there and did a lot of things interesting things with the engineers over there. And I got really impressed by Microsoft. And I think back then there were not so many technology companies that are so experienced at building large-scale software, right? And there were so many talented people over there. I learned a lot just from being there for 2 months. And then I decided to go back to there like to take that as my first full-time job. Uh so that's how my career began. What did you work on when you were an intern? It was Bing, the Bing search engine. Back then it was not called Bing. It was Live Search, MSN Search, or Live Search, one of that. They renamed and renamed a bunch of times, but it was the search engine. And I I helped build some of the features in there. I think it was auto auto suggest. Okay. So when you type in the search box, there was auto complete part of that I helped with. This episode is brought to you by Linear. And they just published something that I think is worth talking about. They opened with the new [music] manifesto, issue tracking is dead. And what that means is that the behaviors around it, like the manual logging of issues, the prioritization [music] back and forth, the grooming sessions, where half the room is just trying to figure out what's even in the backlog, these things are a thing of the past with Linear. I lived this nightmare at Amazon. We had mechanisms for everything. And don't get me wrong, I'm a big believer in mechanisms, but more often than not the process of [music] tracking the work took as much energy as doing the work. You come out of a sprint planning meeting and think, we just spent 2 hours so eight engineers can figure out what they already knew they needed to build. What Linear has done is rebuilt the platform so that the stuff happens automatically. Your code, your decisions, your customer feedback, all of that context all lives in one place. And Linear actually works from that. So when something comes in, the system already understands what it is and where it fits. Nobody has to triage it manually. If you're an engineering leader and you want your team building instead of administrating the work, check out Linear. The link is in the description. It's amazing, you know, I think that transition from hacking a computer on your own, you know, or writing programs on on pieces of paper to cheating on a massively multiplayer online game, it's still really small when you're on the client side. It's still, you know, you can still understand what's going on. But then making that big jump as an intern to being like, "Oh, this is what it takes to build a search engine." Like that what like that's an amazing change of scenery. Yeah, totally. And I think um maybe the first 2 years when I was at Microsoft, I didn't fully understand how the search engine worked. There were many diagrams, there were many documents explaining parts of it. There was this giant diagram made by someone that's been there for for quite a while since the beginning of building search engine. And there was this diagram that explained everything. And when I look at diagram, I can understand each part. I don't understand how they fit together and how they actually work at scale. So it's not something that is uh just very easy for someone new uh to the industry to grasp. But it's okay. Like I worked on uh the components that uh I helped with. I deal with the problems that were presented to me and I think that's how I began. Uh and then over time, I think the knowledge takes a while. Uh takes a lot of really in-depth work to like fully understand. It took me maybe like 2 3 years uh to really like understand the full picture. You went to Microsoft and you went there full-time. What did you work on while you were there? You probably didn't work on search when you came back. Yeah, so when I started my full-time job, it was search engine and then I shifted between a few features. There was the auto complete. There was local search as well. Local search so searching for locations, things like that. And there was um data mining. There were so many logs coming in every day, right? So, that massive amount of data, how do we actually get value from it? It needs the MapReduce pipelines. It needs to like the whole system. So, I helped with that as well. So, yeah, moved between a bunch of systems. But I think maybe like the interesting thing in that part of the journey, like the early stage of my career, was that I just worked very fast because of my prior experience. Cuz I have been building things for probably like a decade by then. So, I just worked super fast. Everything assigned to me, I just get it done very quickly. And then that got me a lot more free time because I just finished things like way too quickly that other people haven't figured out what to assign to me yet. For a junior engineer, typically someone else is like kind of setting the direction, right? So, they kind of need to assign things to you. And I I just got a lot of more a lot more free time because I worked so so fast. So, I used the free time to explore additional things I could do. So, I looked at others and what kind of problems they are dealing with. There was this really interesting problem that people working on the search engine sometimes doesn't have easy access to the data about how people how users interacted with the search result page after they send the query. Like for certain queries, often times the product team will receive feedback and from a user saying, "Hey, this is like this results are really bad." And then we we we need to check data to see, "Oh, like what does that mean? What does the really bad mean? Did we present a wrong result that no one clicks? Or did we actually present some interesting results that's just not this particular user's preference?" Right? So, we need to understand that. And that requires data. So, there was no tooling within Bing back then to easily let you like type a query and see where did people actually click? So, I built a tool to do that. No one asked me to do it. I just had a free time and I realized there's this problem. Just did it and it went very popular within the team and more and more people started to use it. And that's I think what's helped me with the first couple of promotions cuz I was very independent and came up with these ideas, took initiative to build things that were useful. It made it very easy for me to stand out from the crowd. Like there were so many engineers, all very talented, but I think that's the thing that's led to me to get a few like very quick promotions in the beginning. So, you said when you were a junior engineer, you just like got all of your work done as quickly as possible. Were you one of those people that like spent like all night and weekends and slept under your desk? Or were you the type that just came in no BS, you got it all done, but then you also left at the, you know, right when it hit 5:00? At times, I would stay late. And every time I did that, it was because I found something just that's just like too fun to not continue working on it. Like sometimes get into these problems and I feel like, oh, maybe like 15 more minutes I can solve it. And then I ended up spending the whole night. So, that happens, but I think more often than not, I do just like leave at time and I go back to my place, I continue coding. Just build build other stuff as well. Okay, so you you kind of like gamified it or it was a game to you. Right? It's like, how quickly can we do this? How fast like did you sacrifice quality? Was it also high quality or was it kind of like fast and Uh yeah, I think I didn't sacrifice quality. I think everything I did, I tried to make sure like it's actually useful things, it's a quality work. I do make trade-offs on the scope of the things I do. So, I typically start very scrappy, use whatever existing building blocks that already there, try not to reinvent the wheels and try not to like go into rabbit hole of spending like 2 weeks solving something that's just like interesting but not super useful. Um so I I try to control the scope very precisely so I can deliver something useful to people quickly and get feedback. And sometimes people will like, "Oh, I thought this will be useful. Thanks for building it uh but it's actually not as useful as I thought it would be uh after I got it." So getting real-world feedback I think is very useful. There is a world where that tool that you built to get insight into how customers were using the search results page, somebody been like, "Huh, thanks but So did you get really quick feedback on that or did you did you like big bang created and like make a bunch of features and then show it to people? Or was that part of your mandate was to build the tool? No, I think I built tool in the way I think people will find value. Um and uh I built the first version, I showed it to a few people and those people gave me some feedback like which part of that was useful and which things they would probably like change. So I then took those feedback and started make iterations and make that more and more useful. So yeah, it took a while, took a few iterations but Were you like a junior or a mid? Junior. So entry-level. Got it. So you were you were entry-level I don't know what entry-level at Microsoft is like 60 or something. Like 59. You were 59. You hadn't made it to the state So you're 59 and you were just doing this on your own. Yeah. Okay. I work with a lot of people on their careers and they'll come to me and they'll be like, "Steve, like my manager won't assign scope to me. How am I supposed to get promoted? How am I supposed to grow my career?" And you're just saying like as a junior engineer you can go and create the tools there's nobody stopping you. Yeah, and I think that's an important aspect of being a um junior engineer is to not assume that you are only supposed to do things assigned to you. And I would even go further and say you should not only do things that's only assigned to you because that's the expectation. If you just do what is expected, then like what's the reason to promote you, right? Like unless the the manager was intentionally giving you things that would exceed your current level of expectation. But sometimes that doesn't happen. Uh so I think yeah, people should just take initiative and identify problems that other people have, identify problems that might maybe the users have or maybe the team members have or maybe the company has and just work on them. Um if you can deliver something valuable, then those things will will find its footing and then you will grow become something uh more impactful. What if I were to say, well, I don't have enough time to do all of this extra stuff. The existing assignments are taking up all my time and these deadlines are killing me. Yeah, so um I think being good at what you do is important. The reason I had free time to do that was because I finished my assignments very quickly. So I do think accumulating the experience the expertise needed to meet your baseline expectation. That is important. That is table stakes. Um so yeah, definitely spend the time to make sure the fundamentals are good uh are solid and then start to carve out some free time, right? There is always I think it's very very rare that a junior engineer coming to a company will be 100% allocated on things that's like just deadline after deadline. It's very very rare. Usually junior engineers will have some breathing room, especially when uh you work with the manager um on the expectations, right? If you feel like, oh, there are just way too many things that's that has a deadline and that's causing me to not have time to learn, you should talk with that uh talk with your manager about that and adjust the expectations a little bit, right? Maybe um because of the business pressure, people push too much onto you onto this uh person and that's not right. So I think some negotiation uh is also useful. So you left Microsoft as a senior and then you went to Facebook from there? Yeah, yeah. So let's talk about your time at Facebook. What did you work on while you were there? Yeah, so I joined Facebook and Facebook had this really interesting way they they introduced a new hire to the company was called boot camp. So everyone that joined Facebook had like a month or two months of time to just learn ramp up and talk to different teams and really identify which team to join. I chose a team that worked on news because that team had problems about search which I was familiar with. All right, so I thought oh like let's let me find the domain where I can leverage my prior experience. So I joined the news team and worked on some of the search problems and it was interesting. But I very quickly had this feeling that I was just it's not my thing. I worked on some pretty interesting problems and I solved them really well and people were like praising me for it. I could see myself just playing a very important role on that team but something didn't feel right. I I think was uh my manager back then the vibe was not quite right and also I think the whole problem space um was not quite like at the core of Facebook. Like Facebook was a social product, right? The search engine uh the search problem is more informational and uh not uh the same thing. So I had this feeling that I was not in the right place. So after 6 months I switched to another team and that was Facebook games. What year was this? That was 2016. Okay. What were the problems on the search team? Was it the problem of like how do we index all of this news quickly so that we can serve it up? Was it kind of like a like a cold start problem was the primary technical challenge there? There were many interesting problems there. So the problem I helped solve was more technical. We had these machines that had limited memory and if we vertically scale the machine to have more memory it's expensive. So how do we load the search index as much of the index into that machine as possible? That was the problem I worked on. The way I solved it was by like looking at the data that is being loaded and identifying patterns that could compress the data a lot. So, we turned a I turned a 9 GB index into 400 MB. It was a massive compression. And it was by looking at the data and realizing, "Oh, we're using so many bits for a number that is never like bigger than 256." So, like there were many many problems like that, right? So, by dealing with the data, by analyzing it, I could find opportunities to Interesting. Okay, so then you're like news is the side quests. The main quest you thought was like games. That's where the action's at. I actually didn't realize that. I uh So, interesting story. You know the meme where Zuck was saying, "Senator, we run ads." Yes. >> Right? So, Facebook was definitely an ads company, right? The teams, they would run ads on Facebook to recruit engineers from within the company to their team. So, I I was just like scrolling my Facebook on my phone and I saw this ad. It's coming from the games team. And the team just run the ad and say, "Hey, we are working on some super exciting products here. We're working with Blizzard and like Zynga and all these companies to build a really exciting games platform on like on Facebook in Messenger and everywhere." So, that got me really hooked and I was I was a big gamer myself. I thought if I worked on games, that would be super fun. So, I decided to jump. Wait, so you're telling me that Facebook ran internal ads for open developer positions within the company? Yeah. Do they still do that? Uh No, I don't know, but back then that was the thing >> you were scrolling on Facebook, so they're like, "How best else to reach you?" Yeah, yeah. I think running internal ads, they didn't they didn't have to pay like no one has to pay out of pocket, right? Like so, people just do that uh to like recruit. >> [laughter] >> It's actually very competitive within Facebook uh among different managers to acquire the bootcampers. So, new people join the company, they have to choose the team they uh work for, right? So, it's actually very competitive to get the people you want. Uh so, there were many many teams always have open positions, but they have to go to those bootcampers and really like lure them into their team. And there were so many interesting things the managers did to like get people in. What was the core technical challenge at the games division? I think the more interesting problems over there were product problems. So, technical problems, a lot of those uh things within Facebook, they have really good infrastructure. So, you don't have to like reinvent the cache. You don't have to reinvent the database. All those things were already done. The product teams, they mostly deal with product market fit, right? What kind of features will be actually adopted by users and will be actually valuable? So, I spent a lot of time back then talking with game developers to understand how they design games, what kind of games will work well on the Facebook platform. Cuz social gaming was not something that's figured out. Everyone was kind of I think before that like the Facebook games era, everyone was building games more in like a standalone format, right? You would build a game, you would sell it on Steam, uh and that's it. But on Facebook, uh it's a social platform and people talk about things in conversations, people post uh about things on their newsfeed. The communication protocol is very different. So, we had to design the platform to really fit well with the social dynamics over there. And that required code development between the platform and the game developers and sometimes the users themselves as well. So, I spent a lot of time just talking to game developers and uh really work with them to co-design what kind of games can work well and also talk to gamers, people who like to play Farmville, those basketball game in Messenger and Words With Friends, those games, right? Talk to those those users and understand in what scenario do they actually play the game? Who do they play with? What kind of privacy assumptions they have, those game activities, etc. etc. I think it required understanding all those aspects to figure out what is going to be a successful platform. So, that was the probably like the most interesting problems I worked at. So, after you spoke to all of these partners, like what was the output? Were you thinking about the ergonomics of like the APIs, you know, the facilities that you were exposing to these developers or like what was the actual output? Yeah, yeah. So, one example, when we started that project, we started with the basketball game. Maybe many people still remember that. So, you can throw basketball in Messenger and get a score. The score will get posted into the thread and people just compete. So, we saw that and we saw a lot of people loved playing that game in that kind of format. So, we thought, oh, it would be super interesting to build a platform so other games that have a high score mechanic can also come in and be played in the same way. So, we designed the whole platform with a high score and leader board mechanic in mind. And that was a big mistake. So, yeah, so we we spent months building that mechanic and building every part of the user experience with that assumption in mind. And we launched a product. We launched a platform. We had a few games that went live with us. I think we launched that before Christmas. We came back after the holidays and we look at the user retention numbers were just so bad. So, we then talked with the game developers and tried to understand why. The first round of the launch, we didn't even talk to many game developers. We just like built things that we thought will will useful, will be successful. We assumed it's going to work. And we tell the game developers, work with us on this format. Don't ask questions. Just do what we say. We gave them an SDK and that's how things work. That's it. After we see, oh, it's really not working. Why? Then we realize, let's talk to the game developers and see how they think about this, right? They have experience building games for decades. So we talked with them and they say, oh, that's because the high score mechanic is just too limiting. I have all these games here, like Words With Friends, right? It wouldn't work well in a high score format, right? It doesn't have a high score. Like you you play turn by turn. It's a turn-based game. And then other people have other games, real-time multiplayer games, like those IO games, like all kinds of games that wouldn't fit well with the format that we provided. Then we realized, okay, we made a wrong assumption and we need to redesign the platform. So we then kind of reshaped how we provided the SDK and how we provided user experience as well. We just like removed all the assumptions about high score. We gave the flexibility of what kind of activity is worth posting, gave that flexibility to the game developers themselves. And then we started to take this to see things take off. And people built quiz games, trivia games, turn-based games, all those things that were super interesting. And people started playing more and more. You made the cardinal sin of not talking to your customer and understanding them and then building something. And then after you realize that they weren't using it, that's when you started the first step of talking to them. Yeah. And I think with the games platform, it's interesting because there are three parties. One is the platform, one is the game developers, and then there's the actual players, right? These three parties, they have different concerns and we kind of have to like navigate across all three parties to really figure out what's going to be a good fit. So during this game development work, this is also when you were growing in your career as well, right? So you went from junior to E7 during this time frame? Yeah. And I took a detour to become a people manager for 2 years as well Uh during that journey. That's also super interesting. I learned a lot. So yeah, let's get into it. What's that story of going to become a manager? What did you learn? I think you went back to becoming an IC afterwards, so that wasn't a permanent thing. Yeah, yeah, so I I think I was following my curiosity. So I have to been an IC for a long time. It was maybe the eighth year of being an IC in my career. I felt like I never explored what's a people manager role looks like. I might like it and I thought I would. I I was pretty convinced that's like going to be the end game. So the opportunity came up and I just said yes. That was also an interesting story where my manager came to me and said, "Hey, like we need to scale the team and we need to have a manager that supports one part of the team." Because the team is growing, we have more and more people. So he asked me whether I want to be that manager and I immediately said yes. I just thought that's the natural next step and why not, right? And I was curious to see what that looks like. And then the VP had a one-on-one with me. The VP is now the CTO of applications at OpenAI, VJ. Oh. Yeah, that was our VP back then on Facebook games. So I talked with him. He just scheduled a one-on-one with me and we got into the room and he asked me, "Why do you want to become a manager?" And I said a bunch of things and then at the end he told me those are all red flags. You should not be a manager. >> [laughter] >> You should not be a manager. That's not the right motivations and you you probably won't like it. >> Wait, what did you say to him? That was What was the biggest red flag out of that group of things that you said? >> I I said things along the lines of I want to make bigger impact. I want to really like scale my scope. I want to work on bigger projects. I want to really influence a group of people, not just myself, like work beyond what one person can do. That sounds like what you might hear if I pulled any manager out and it's like, "Hey, tell me about the time that you became a manager. What did you say to your VP or to your director about why you wanted to be a manager?" They would have said those things, right? >> Right, right. So, those things I think are the things that people who haven't been in the management position would assume the role is about. And for a lot of managers, that's indeed the case. That's how they operate, and that's how they get value from being in that role. Um but I think after me being in the management role for 2 years, I I think I agree with that VP. Like the those motivations were not the right motivations. So, if working on bigger problems is the only motivation uh to go into management, you can do that without being management, right? You can influence people, you can work on big problems, and a lot of ICs do that. Uh I do that today. I think being in management is really more about supporting others, figuring out, hey, I have a team here, how do I help them do more? How do I help them grow in their career? And a lot of the time will be spent on that. And how do I recruit the right people uh onto the team, right? To make the team stronger? So, a lot of that is in kind of a support role. That was the reason I decided to come back to be an IC. There were just uh many, many weeks where I look at my calendar, and every week about 70% of my calendar was already booked. Okay. Uh so, it's regular stuff. Every week, same thing. Just keep grinding. There were so many one-on-ones, there are so many team meetings, uh there are meetings with other organizations, etc., etc. Those are regular stuff. I thought, "Oh, that's so grinding. And if I keep doing that for 20 years, I don't know if if I can do it." >> Your VP let you be a manager even after you gave him a bunch of red flags? Yeah, so interesting, right? Uh good question. Why why that happened? After the meeting, uh I went back to my manager. My manager back then really needed to scale because the team was growing very fast. Uh the games platform was was doing well, and we needed more people, and the team had to scale. If he continued to take on every single direct report, it's just not going to work. So, my manager uh taught me what to say. >> [laughter] >> He gave you the answers to the test. What are the right answers? Um I did it uh and I go went back to the VP uh VJ and I gave those answers and VJ was very smart. And he just >> [laughter] >> He He just said, "Hey, like I don't uh believe in this kind of overnight changes. Your answers completely changed. Uh that's not uh not how it works." He knew what's happening. Um but uh he still said, "I'm going to give you a shot. I like to take chances and I I think you better like really treasure this opportunity." He's been seeing how I work. He trusts me to be a really good engineer that can help coach and educate others. So, I think the foundation was there. The trust was there. The VP was like, "Okay, uh I'll take a chance." So, what did you learn becoming a manager? You probably anticipated what it would be like and then there was the reality. What met the expectation and then what was completely unexpected? I think what met my expectation was that I get to exposed to a lot of problems that I wouldn't otherwise like ever get exposed to. So, what happens when uh your team starts to grow? What kind of problems start to emerge and those things are not obvious from an engineer's perspective. But from a management perspective, you have kind of have to deal with that. How to actually recruit the right people to your team as well. Uh that actually like require a lot of investment. So, I think from a learning from a curiosity point of view, that's met my expectation. I learned a lot. And some of the things are super interesting uh even to today. When I work with agents, for example, I think one of the things I benefited from quite a bit from my management experience was to learn to lose control. When you have a team, when you are working through others, not by yourself, you are losing direct control on the problems, right? You are not going to control the code base. The code base might look ugly and you may not not like it. That's the same when we work with AI agents today. Some people when they work with AI, they micromanage everything. And if AI is generating some some codes they don't like, they spend so much time like tweaking it, prompting it to do things exactly the way they want it. I think that's like a mistake. Um I think when we work with AI, a lot of the same patterns apply. You have to think about this from a an organizational point of view and start to not have direct control. Start to think about what are some of the principles you can write down to help all the agents work better and control direction through that way. So I think, yeah, a lot of the management experience actually were quite beneficial even if I come back to be an IC. What was really surprising and then ultimately what made you want to go back to becoming an IC and writing code again? Yeah, so I think it was the grindy aspect. What happened was that after 2 years being a manager, I was actually a very good manager. Um so the teams loved me and I got really >> say so yourself. >> [laughter] >> I got really good survey results. So so like the company's run the survey and I look at that, compare myself with averages, other other teams. Doing pretty well. I I think I leaned into that role and I changed how I operate and I read a lot of books as well. Really good books about how to be how to operate as a manager. So I I think I did well. But then what happens after you do well is like people will want you to do more and I started to get the request to take on a larger team. So the team was still growing and we had other managers that left the company and kind of need to reorganize the team a little bit. And then I got asked, "Hey, do I want to take on this larger organization?" And then that got me like to really think. I suddenly felt like I could see what I I was going to do for the next 10 years. I will take on this larger organization. I will then do what the VP was like maybe not the VP yet, the director, what they were doing. And I I can see what they are doing and it's not that fun to me. So, I suddenly felt like, "Oh, if I can predict what I'm going to do for the next 10 years, that's not the kind of state I want to be in." I like more adventurous kind of way of working. I don't want to know what I'm going to do every single week. I kind of like had this thing in my subconscious that tells me, "Hey, maybe don't do that right now." So, I I decided it's not the right time to go deeper in that track. >> So, it was like the trajectory. You're like, "Okay, well, if I keep on going down this path, I'm going to get VJ's job and I don't like what he does. I like the guy, right?" Is that Is that kind of it? I actually like the VJ's job, but I I think it's going to take a long time to get to his job. So, yeah, VJ was super strong and I think when he was VP, he could manage every aspect of the business, right? So, he's not only a engineering manager anymore. It's actually more like a business owner and I I I like that. That I think I would enjoy, but it's going to take quite a while to get there and I felt like maybe that's a good end game, but not going to be where I start going down that track at that time. So, I felt like, "Yeah, let me at least spend maybe 10 more years as an IC and work on problems that will keep me motivated that will like really help me learn all the interesting stuff that's happening without committing to this like management role long-term." Were you a senior engineer when they asked you to become a manager? I was an E6. Okay. So, you're staff, I guess. Yeah, yeah, staff. Yeah. And then So, then they asked you to be a manager and then you went back to becoming a staff engineer. Is Did you still stay in games? Yeah, yeah. Okay. And then you got to E7 still in the games. >> Yes, still on the same team. Some people I talked with that also went into management, they actually felt nervous about coming back to an IC on the same team. They felt like people will see them differently, people will think they failed, whatever, right? They have this like a little bit of ego that is telling them not to do that. I think that's the wrong way of looking at things, at least from my experience. I was on the same team. I came back from a manager to be an IC. That was actually I think a great decision. If I jump to a different team, I think it would actually make my life harder. So, on the same team, people already trust me. I already worked with so many people on the team. So, being an IC, I can immediately establish a strong influence, right? I can very easily work with a lot of people that I used to work with. To be honest, no one cares like what you are I think sometimes we think people care about us way more than they actually do. The spotlight effect. Yeah. Yeah. You think everybody's looking at you, but they're not. Exactly. So, I think yeah, management, IC, no one really has the bandwidth to think about what you are doing. Like, they have their own jobs, they have their own career growth, they're managing, and what you are doing maybe is worth talking about for a week, and then no one's going to care about it. So, yeah, I think if people are in this position where they really want to like convert back to an IC role, but are worried because of the perception, I would say don't really think about that too much. What was the project or the set of circumstances that got you from senior to staff? And then after you became a manager, what were the circumstances that got you to from staff to senior staff or whatever E7 is? Yeah, it's mostly impact of the things that we did. So, going from senior to staff was mostly taking the games platform on Messenger off the ground and to a state where we actually have product market fit. We have a whole bunch of games running there, and it's working pretty well, and that I was a big part of that. So, I think the business outcome justified that and and the way I helped achieve that outcome was that I actually had to travel to a lot of game studios and talk to those developers and really operate in a way that is beyond what a senior engineer would do, right? I played more parts in the product decisions and everything. So, I think the strategic influence of my experience there was what took me to staff. Is it because Facebook I think Facebook famously was very reluctant to hire product managers, especially in the early days. I know they have a robust product management team now, but was this sort of during that transition where software engineers were expected to just have much more of a product impact? Yes and no. I think on some teams, yes. So, on some teams the the engineers were actually expected to also take on product decisions, but it's not uniformly across the company. So, I think on my team back then it's not the expectation. You can do fine without playing like the product thinker role. You don't have to do it. A lot of engineers they do pretty well by just being like a good engineer. But I I liked doing that and I felt like that was that's the bottom neck of the business is to understand product market fit is to like take the business it really onto the right track. If I didn't do that, then the project wouldn't have had the impact and the product market fit it had, right? So, I felt like I had I had to do it for the project to succeed. It's the project success that justified my impact as well. Yeah, I think if I just did what I would do as an engineer as a pure engineer, the project probably wouldn't have been as successful and I wouldn't have been promoted. You flew out to these game companies to meet with these people and then talk with them. Did you just book the flight and then go? Like you realized that you needed to go and talk to them or did your manager say like, "Hey, we should probably talk to these people?" Yeah, it was a group decision. So, yeah, not not just me. I think we came back from the holidays and we look at data and it's not looking good and we were just like talking about what do we do, right? And Facebook back then already had a few of those events where we would go and meet people. So, we just leveraged some of those events and say, "Hey, let's invite some of the game developers to come to our event and let's talk to them there." For some developers that didn't come to our event, we traveled to them. So, yeah, it's it's a group decision. >> But it would have been very easy to just be like, "Hey, I'm just in my office. Yeah, I'll go to the event, but I'm just going to be in this isolated silo here doing this thing." Yeah, I I think especially when an engineer travels with a group to an event or something, I think especially for maybe introverts, I'm an introvert myself. I think the default is to like hide in my corner and do my thing, right? And whenever someone needs my help, I'll I'll go help. Yeah, I think that's the the thing we kind of have to break out of to really make an impact on business success, we have to break out of the boundaries and not think of ourselves as just an engineer, but think of ourselves as a really smart person that can play a big role on any project that we we are part of. Ever since that project, it gave me this mindset that the title does not matter. Whether I'm an engineer or any other title people give me, it wouldn't really change what I do. What I do is always going to be what is the most impactful thing I can do for the for this business and make it successful. What about the the jump from E6 to E7? What was What were the circumstances there? I think it's a continued growth of the games platform and the evolution of the games platform from being a messenger-centric experience to a Facebook-wide platform and a lot of the games had to evolve. So, we started from within Messenger and then later on we have to figure out how do we grow the platform. And Facebook newsfeed was actually a very big surface area that was not very heavily explored. So, we did a bunch of things over there and later on we had a live streaming platform as well, Facebook gaming live streaming platform and that also changed how the team's overall mission was. So, I played a big part of how we rationalize the strategy over there and how we evolve the platform from being a like a turn-based game in Messenger threads to a larger ecosystem. So, that was probably like the E7 impact I had. I'm just wondering like what part of that was expectations at E6 and then what was the thing that was the larger impact stuff? Like how did you have this nose for impact to know that you could go after a bigger scope, you know, outside of turn-based games within Messenger? Yeah, I think in general I just I have this this sense how can we take things to next level? I constantly ask myself whatever project I work on. I was just like never satisfied. I think whenever I have a project that's running well, everything's going smoothly, I would just panic. >> [laughter] >> I would just think oh like what's wrong? Why is this like just going so smoothly? Because I think when things are going very smoothly and you feel like oh, it will just keep going whether I'm here or not, then I'm not adding value, right? Then why am I here? Why don't I do something else that's more useful? So, I kind of like just panic every time I get into that state and I really try really hard to identify how can we take things to a whole different level and that's often required taking initiative step function changes. So, not just like incrementally keep growing keep doing the same stuff but but like grow faster or whatever but rethink the story. Can we actually do a whole different thing? Can we rethink the whole strategy? So, yeah, I have this like constant rhythm of uh reinventing or rebuilding uh whatever I was uh working on. You freak out when things are going well. Yeah. You just like thrive on chaos. I think about like a lot of people, when they're in the chaos, they think to my they themselves like, "What is wrong with this this company's terrible. There's all this chaos that's going on. If we work really hard, maybe we can get to these smooth seas where things are kind of running themselves." And so, they they do the opposite. Most I think just rational people, they'll freak out in the face of this chaos, but you're kind of built in this opposite mode where you're like, "If it's too smooth, then you can't you get you you freak out, you get this anxiety." Yeah, yeah. So, I think when things are chaos, I do try to solve the chaos, right? And that's the fun part of it. When things are chaos, and I look at that, try to understand, try to rationalize, "Why is that so chaos?" And what is happening, how can we uh solve it? How can we bring that to a good state? And solving that problem was the fun part that got me motivated. And if things are just going well, I have this crisis of uh why am I here, and what am I doing with my life? And I just I keep looking for things that are more chaotic. And that's one of the reasons I uh switched from Facebook back to Microsoft because I felt like the Games platform was established. I can still see some new things to do, but it's largely like there. I wanted to try something that was uh more like starting from scratch. So, Microsoft back then was trying to build a Games platform on MSN. I thought I could help uh cuz I know how to build a Games platform. Uh so, I yeah, went to Microsoft and start that from scratch, totally zero to one. It was super fun and very chaotic, and I really enjoyed it. So, you came back as I guess partner level at at Microsoft. Zero to one, you found the chaos again, but in a situation where you had much more domain expertise. Did you solve that problem and then it became calm again and then that's when you moved on? That's part of the reason. Uh, so I spent 2 years there uh, at Microsoft building that games platform from zero to one. Talking to largely the same developers that >> [laughter] >> have been talking to. I'm like, "Hey, I I recognize you." Yeah, yeah, yeah. But it's a it's a very different experience for me because at Facebook there was all these other functions that were supporting me, right? I didn't have to worry about like signing business agreements with those developers. I didn't have to worry about, "Hey, are they making enough money? And if they are not, they are going to pull their games out of platform." And I didn't have to worry about, "Oh, how do we actually find advertisers who will put ads into those games and help everyone make money? And what kind of advertisers are there?" Um, so I didn't have to worry about any of those problems before. But at Microsoft, because I was the one that's proposing that we do this, they had some interest in like spinning up a new platform. That was the reason I joined, but no one had an idea for how to actually build a platform, right? So, I proposed, "This is how we build a new platform." And when I did that, I didn't realize how complex it was uh, to really establish a whole new business. So, I totally underestimated uh, the business development aspect of things and the money aspect of things. Uh, how to make everyone happy. So, that was a very new experience. Those 2 years learned a lot as well. I think more as a business owner like um, a product group lead um, than a previous like an engineering leader. You weren't a lure to go back to maybe being like director level or anything like that. Back to management, back to people management at all? Oh, I just said no like straight. Uh, >> [laughter] >> yeah. Uh, so I think when Microsoft was uh, reaching out to me back then, the role was not well defined. Like they just want to spin up a new platform, right? Uh is it going to be a manager, director, or is it going to be an IC that help them do that? They didn't figure that out. Um so, I talked with them and I convinced them, you really only need an IC here. You don't need you to be a director. Yeah, and I said I wouldn't be a manager. I would enjoy doing that as an IC. I would not enjoy that as much uh being a manager or director there. Yeah, I get that sense as well that even if you got brought in at director level, you would probably find some way to get back down to an IC to contribute. I had Philip Sue on the the podcast a couple of times. I think he went to E9 and then he was like, I need to get back to building. I need to get back to the code. So, he took a demotion to go back to start uh coding again. I get the same vibes. I think people that are builders and that thrive on chaos, they just they have to be building. And I think it's the cycle with software right now where this is the perfect time for you to be building. And we'll get into AI in a moment. Let's talk about career advice. Obviously, things have changed quite a bit since you were an IC um and working at at Facebook and Microsoft. What would be your advice now to people that are trying to break into the industry perhaps and then also people that are mid-career? How can they best protect their careers? How can they stand out? My advice would be very different from like for junior people versus mid-level versus senior and above. I think first thing uh especially for more junior folks, I would say be really good at what you do. It's very important. That's the foundation of everything else. So, just build things. Just build things you find interesting and would enjoy doing. Build a lot of them. I think before I started my career at Microsoft, I probably have already had built like a hundred different toys, like different things. Like some of them actually sold for money, right? Like those cheating tools. But a lot of them didn't sell for any money. Like a lot of them are just purely for fun. Oh, I love that. People are always asking me. They're like, "Steve, what what side project should I build so that I can get noticed?" You're saying build a hundred things. Yeah. Yeah. Don't don't commit to one thing. The biggest value I get from building a lot of those side projects and fun stuff like hobby things was really the exposure to different technology, to different tools that you wouldn't otherwise get from doing your primary job. So, especially in big companies, I think the tech stack tend to stabilize, right? You only with work with C# or like this very particular system. That's all you do for like 2 years. So, I think we kind of need these side projects to explore the breadth of the industry. So, that's one. The other is to really getting into this mindset of just doing things for fun is very important as well. Because otherwise, we tend to lose motivation. Like if people don't have a way to have fun, then what they do is when they have time, they would do other things. Scrolling Tik Tok or doing other fun things, right? Which is fine, but if you really want to go deep into this software development career, then I think you have to find something that will keep you motivated that you would keep doing this for hours and hours. I would often find myself whenever I have some time, I had a long day, I'm exhausted, I I'm sitting down. The things that I gravitate towards is building stuff. I find fun. And that's the most relaxing thing I could be doing. So, I think finding that state of mind Yeah. that mentality, I think it's very very useful for developing really deep skills in this domain. So, I yeah, I definitely would recommend. I love that because well, doing a lot of things I think is really important. You work on auto complete for being. You can only go so deep into auto complete. Yeah. Right? But when you work for a really large company, you're a part of a much larger organization. And so, you are going to be working on a very specific part of the stack. You might be working on the app load times for the Android client for Instagram so that you can shave off another 10 milliseconds or something like that. And to get that extra 10 milliseconds is going to require you to really understand what's going on, but you are just look you're looking at this tiny little surface area of what's there. Yeah. And so, I love this idea of like, "Hey, can you gamify it?" I also love this idea of being like very good at what you do. Like, do you know what a 90th percentile implementation of a thing looks like? Mhm. Right? And can you like can you go and execute against that? Instead of thinking of like a task as this sort of checkbox that you get done. Yeah. Yeah, totally totally. I think that your advice for juniors, I think that's good for before you get your first job and then also I think when you're on the job as well. Just like making sure that you're keeping your skills warm, that breadth of skills warm, even if you are working on a small surface area. What about mid-level engineers? Yeah. Yeah. Yeah. I think for mid-level and maybe um part of the senior uh role as well, the elements I benefited from the most was to follow my curiosity. So, whenever I feel bored, whenever I feel like I'm not growing, I'm not learning more, I jump. Just get out. You freak out. Yeah. Yeah, like find another thing to work on. Uh that was very beneficial for myself uh looking back, right? Because I if I stayed in those comfort zone and I like everything is smooth sails and I just keep doing what I have been doing, I I will get paychecks every month. Like I there's not going to be any trouble, but I wouldn't have learned all those new things I now got exposed to. So, I think following curiosity and never get comfortable with just like doing whatever you have been doing is important. Can you give me an example of following your curiosity where you just decided to learn something completely orthogonal to what you were doing on a day-to-day basis at work. Yeah, I did this multiple times. When I stopped at Microsoft and jumped over to Facebook, that was one time when I felt bored. I felt oh, I just I was doing what I have been doing already, so I want to try something new and Facebook was the new thing. I didn't know how Facebook worked, such a big social network. How does it work? Especially like internals. I followed the curiosity to jump ship to Facebook. And then within Facebook, I also followed my curiosity to work on games instead of news because I felt like games was going to be more I can learn more and I would find it more fun to work with. And then later on, switching to management was also following my curiosity. I didn't know what that role would look like. I would love to have a try and no matter where I end up, I know I would learn something new, right? I think the learning was was driving me to make a lot of those changes. Later on, I think switching from Facebook back to Microsoft was also just following my curiosity. This is the pattern that I repeated the most was to make sure I'm always learning something new. I'm following where my curiosity leads. That kept me learning and kept me motivated. So I'm always energetic about the things I do. That I think is very important as well because when you are really passionate about something, you will do your best. You will really like outperform a lot of others who are just there to get a paycheck. So yeah, finding that place is going to be very useful. So when you moved to a new place when you were following your curiosity, you had single-threaded focus on that one thing then at moment? Or did you did you ever do any side quests when you were you know, suppose when you were working on the game stuff, were you like, I wonder how JPEGs work? And then you like did a like a deep dive there or you're like, I'm going to pick up React even though that wasn't maybe part of what you were doing on a day-to-day basis. I didn't do much of that. I typically, when I find myself exploring side quest, that is an indication to me that's maybe the main quest is no longer that interesting. So, whenever I take on a main quest and I find it super interesting, I would just go all in and spend every single minute on that problem and make that as successful as it can be. And then once I'm done with that, I might want to switch to other problems. >> Let's round it out. So, as a senior or a staff level engineer, so pretty senior, what advice would you have for folks at that level? Yeah, I think for more senior folks, your situation is very different. And I think something I find to be different, at least in my experience, was that when I'm more senior, I get pulled to other companies more often. Then I have to explore where do I go. So, there will be other people, maybe your previous managers, people you worked with, have moved on to other places. And if you had a good experience with them, you had a good trust built with them, they will probably reach out to you and say, "Hey, I need people here and do you want to come?" I get that a lot more often when I was more senior levels. So, I think in those situations, realizing your leverage and know to negotiate. I think at more senior levels, is one negotiation can make such a big difference, right? Sometimes it's between a whole whole different level. So, when you switch to a different company, if you negotiate just a little bit, and if you know that they need you there and you have the leverage, then just do that and use that to get like maybe a level jump in those switches, right? And often times, those those level jumps are what you deserve. Because maybe you have been working in the same company at the same level for a while. Maybe you were already performing at the next level. You just didn't haven't got the promotion yet, right? You had growth and those growth haven't reflected in your level and you should take those opportunities when you jump to a different company to really rethink what is the right level for me in this new role and can I negotiate a little bit with this new company on whether that's the right fit. I think the default is people make lateral moves because those other companies recruiting them have the incentive to pay them as little as possible or like not at least not to offer them a much higher position up front. So, I think people need to realize that and need to really utilize their leverage. Yeah, I think senior and staff engineers, especially in big tech, they're very capable and high performance just to get to that level and then if they're following their curiosity or seeing what else is out there, I completely agree. I think what they would really like is the lateral move because they don't feel like they're necessarily operating at that high level in that new domain, but of course you're not because it's a different domain that you'd be jumping over to. So, just like recognizing that you actually do have leverage in those times of transitions. I think that's really powerful. Yeah, realizing what's those other companies pulling you, what do they need, what are they looking for and if you feel like you do have the right skills to fulfill that need, then you have the leverage and you have to use that. I've been holding off on this discussion for a little bit while, but let's let's talk about AI. Yeah. Maybe we can start from a if I'm a junior or mid-level engineer, how should I be thinking about AI in my day-to-day and where do you think that that's going to be going in the next couple of years? I think that's first set the scene. Maybe one question people get asked a lot is AI going to take my job. I think AI is 100% going to take people's jobs. It's only a question of who, whose jobs. And I think while AI is taking some jobs, AI is creating new jobs. So, as a whole, as a society, we may actually have more software developers, more builders. But, some people will lose their jobs, and some other people will suddenly get a job that they wouldn't otherwise get. So, I think it's important to look at like these dynamics happening. So, in my last job, I have been working with a lot of CTOs and talking with a lot of companies' CTOs as well. I got this view of what's happening in a lot of teams, and I think they share a lot of commonality. So, a lot of companies, what they are seeing is that these AI tools are getting traction, they're getting adoption. Most developers, they already use AI one way or another. So, they use GitHub Copilot or Cursor or Coda code, whatever tools out there. But, when they look at their company as a whole, the company's productivity may be only increased by 10%, 15%, not a massive amount, right? So, it's very different from how people talk about AI on Twitter and like this social media. So, what is happening? Um, when these CTOs zoom in, what they see is that in their company, there is maybe 2% of people who actually figured out how to use AI very effectively. And these 2% of people are so much more productive because of that. But, then, the majority of the company, the mainstream, is still using AI in a very shallow way. Yeah, they are using AI, but they are not really getting the most value from it yet. The mainstream people are actually also, they don't seem to have enough curiosity to get to that next level as those 2% people did. So, when we average that out, look at the whole company in aggregate, yes, or maybe only 10% lift, it's not that much. And some people might actually conclude that AI is not that impactful. I think that's where they missed the picture of what's happening in that 2%. It's massive. It's a massive shift in how we operate, how we work, and how we produce software. So, I think people need to realize this is an industrial revolution happening right in front of our eyes. It's just like how we shifted from like manual woodworking to steam engines, how we shift from steam engines to electricity, and and then the internet, and every time like this technology transformation happened in small scale first, and then later on it took over the entire world. People who are still in doubt of whether they should use AI or should uh lean more into it, they need to have the urgency uh to really figure this out because I think if people really haven't figured out how to get value from AI in a few months or within the next couple of years, those companies, what's happening is that they are moving the impactful projects to those 2% people and say, "I will give you a lot of tokens. You can use those tokens as much as you like, and just keep charging ahead." And those impactful projects get executed a lot faster in the hands of those 2% of people. Those large, slow-moving teams, what you usually see is, "Hey, like let's rename this button. Let's rename this piece of text." They will come back and say, "That's 3 months." CTOs just don't like seeing that, right? Like um it is not how they would like to operate. And I think over time, if the teams still operate in the old way and they still give these 3-months estimates, at some point the CTOs will say, "Hey, like why do we have these teams here?" And they will just like try to double down on the 2% more and more, and I think that's a very risky position for a lot of developers to be in. Mark Zuckerberg just came out and he threw out a PR, and everybody came in to go and approve it, maybe to give him some feedback. Like it's happening. And then I got into this big funk. I'm like, "What am I doing?" Like everything that I did for my entire career, I could just see that AI is eventually going to take it over and and I realized I had been moving the goal posts in terms of what AI and AI agents could do and then I realized that like everything that I'm pulling up right now, all of the cope that I'm putting in there right now is just me moving the goal post slightly. And it's it's going to it's just it's just coming after me. And then then in in January and then February, I'm like, "Okay, I'm good now. This is just a big change of what's going on. I need to like lean in and figure out what's going on." So I fired up I've been using Cloud Code for a little while but really on toy stuff and so I've been really leaning into Cloud Code and CodeX and what a different world that we live in right now. It's absolutely unbelievable. I can totally see how a lot of my work just could have been done by an agent. You know, you joke about it now that like, "Hey, adding some buttons and flipping them around would take 3 months." Those are very real estimates that senior engineers would give you and product managers like, "Why does it take 3 months to wire a button to have slightly different behavior?" And then they would say something like, "Well, because the data flows through four different services and each one of those services has to have like a new API value that's going to be keyed through and then we need to put some buffer time in there for testing. And then now you can kind of go in and then just be like, "Move the button." It's like, "Okay. Yeah, sure. What else do you want me to do?" Yeah. Yeah. Do you think that there's a first mover advantage? So that 2% of people right now that are really leaning into to agents, do you think that they're they're leaving behind the 98% or do you think that the 98% of people can just lean in once the tooling has become more mature? Oh, okay. That's a really interesting thing to dig into. My hypothesis is that the tooling will never mature until the AI models have plateaued. So, what's happening in the past 3 years? We first started with GitHub Copilot being the most advanced AI coding tool in the world, right? And then look at what happened after that. There's Cursor that's like kind of was taking over. There was Cloud Code that completely changed the workflow. And now people are doing these orchestrators on top of Cloud Code. And GitHub Copilot, where is it? Like it's I don't know anybody that's using it other than like people that are forced to use it within an enterprise setting. >> Yeah, so look at how quickly things changed over the 3 years, right? It's only 3 years. Some of the tools that we have been working with have existed for decades. So, only these 3 years things have already changed so much. That's why I think the tooling is just a continuous process of evolving along with the AI capabilities. So, until the AI has stopped advancing, the tooling will not stop changing their shape. So, I I think everyone's working with AI tooling right now. I would recommend a mindset of assuming everything is just temporary scaffold and we're going to rebuild everything every 6 months or maybe even faster. So, look at Cursor. That's a good example. Cursor started being very Copilot-like, very much GitHub Copilot-like, code completion. They then added agents. And recently they they just announced Cursor 3, which is more like Codex. So, more agentic. These products, they are evolving because they have to. Because the AI is getting better and we no longer get enough value from code completion alone. We get more value from delegating tasks to agents and letting them do the task, right? And this is going to keep shifting. So, Steve Yegge has this gas town concept and I think it's getting more mature now. When it first came out, I tried it. It's not quite like working super well, but but I I think that's actually like a future state where you have uh orchestration and everything done by AI as well. You have a whole army of uh AI agents working for you. And it's going to continue to shift. I I don't think Gas Town will be the end state. I think we'll just continue shifting. So, uh I wouldn't recommend investing too much time in very specific tooling. But, I think we should invest time in a different mindset of continuous learning, really leaning into playing with AI, really see them as a very valuable new way of working that's totally different from what we have been doing in the past decades, but is going to be the future. So, I think the mindset will will ultimately drive us to keep up with the evolution of the tools. I completely agree. But, I I do see this situation where everybody's trying to figure out like, "What's this end game for this orchestration? Where's it going to be?" I do like your point of saying the foundational models start to plateau. That's when maybe we'll see some stability in the tooling around it. I think the juniors are oddly in an okay place Mhm. if they are going to embrace AI and they are AI native. I think Cloudflare, they just uh they're hiring like 1,111 interns or something like that. And so, they just realized that all of these young people that are AI firsts are injecting a lot of energy into their organizations. >> Yeah. Maybe in an attempt to bump up that 2% number. Mhm. The next logical question is like, "What should you do as a mid?" If you're in a in you know, like if you're in this mid-level, maybe bordering on senior senior, maybe even going into senior, is now the right time to go all in with this tooling uh with this AI? Yeah, I think junior and um and mid-level engineers, right now, I see two different camps. One camp is freaking out. Things they have learned over the past couple of years have been so trivially done by AI, right? Uh they spent so much time learning the languages, the frameworks, and everything. And now AI is doing those things faster. Uh so, some people are freaking out. And then there are some people who are kind of like they haven't been AI-pilled yet. They don't think it's a big deal. They think it's generating slop most of the time, and it's not that useful. So, I would generally recommend both junior and mid-level engineers to see this as a really good opportunity to leapfrog some of the senior engineers. There are people who have been working for like decades who have built their skills with those very specific mechanics in mind. So, some people, they are really good at writing Java. Their whole career is Java, right? So, they are really good at it. Like they they are. And some people are really good at C# or like these particular very specific frameworks and languages. Those people uh they although they are senior, they have decades of experience, some of those are still super valuable. The muscle memory they built and a lot of the mechanics they have learned over the years are not as valuable now. So, the gap between someone like that versus a junior who's just starting their career has just reduced massively. So, if you are junior starting today or mid-level uh mid-level is still very early in your career, right? You can totally leapfrog a lot of those people, especially those people who have built a lot of the experience, but they don't believe in AI yet. So, they are going to fall behind in terms of the leverage they have. Now, the juniors and mid-level engineers, if they really found the way to leverage AI to leverage all the compute, like there are so many GPUs working for you. Like those compute is massive power. If you know how to harness that power to do work for you, you can do a lot more than people who just rely on their experience with very specific mechanics. I love it. Reframing it as an opportunity to leapfrog people. I just started being on X at the beginning of this year. I was like, oh, what's going on over here on X? And I'm just like, oh, one of the greatest places in the world to be at the cutting edge and like what a cesspit of the you know, an echo chamber that's going on over there. And a lot of people are saying like, oh, careers are dead now. Like pack it up everybody, it's time to become a plumber. But I love this reframe of just being like, no, maybe there's not a pipeline problem. Maybe junior engineers are totally going to be still hired. It's going to be a different type of junior engineer. So, do you actually not see a demographics bomb? You know, there's this narrative around senior engineers come from junior engineers. And if we're not hiring junior engineers anymore, we're not going to have senior engineers in the future. No, I think the activities are shifting. So, what we previously have defined as junior and senior, those definitions will no longer hold. So, I think everyone great opportunity for especially for new people, you can totally build a skill set that can allow you to be more valuable than some of the senior folks who have been there for quite a while. Senior people should also know how to leverage their seniority. So, a lot of the experience they have built over the years, especially how to think from a system architecture point of view, not in like every line of code, but how do we maintain a scalable system? How do we deal with flaky production? How do we actually maintain a healthy system that can scale to a large number of users? Those problems are something the AI models are not particularly good at yet. So, some of those skills still matter a lot. And senior engineers, they are in a position where they can orchestrate a large amount of AI agents to do work that will not turn into a mess. If you don't have those experience and you're just like someone that's haven't done any engineering before, vibe coders, true vibe coders. So, true vibe coders, when they build things, they can get that to a certain step. >> So, true vibe coders, are you defining it as like not even looking at the code? Right. So, my definition my previous definition for any vibe coders is they don't understand the code being generated. Mhm. They only look at the product they're working with, right? I think my definition has shifted a lot as well because right now for some of the things I do, I don't even look at the code anymore. But, I can still understand what's happening there. I just don't need to look at that very often. That's why I started to say true vibe coders cuz I think there are people who are working with AI to build software that truly don't understand what is being built. People who do have experience have a massive advantage over those true vibe coders because I think true vibe coders right now can take something to a prototype. Maybe a MVP they can launch. But, once they have thousands of users they have real production, security, commerce problems, like all those things start to come in, they do not have the skills to keep going. They have to then call someone or hire someone who actually understands engineering. So, I think the the years of experience working with large-scale systems still hold. And people need to learn how to leverage that. The way to leverage that is not by coding everything yourself anymore. It's by really orchestrating a large amount of agents to do a lot of work under your supervision. So, I think that's where senior engineers can differentiate themselves from junior folks who are also learning these agents and can also code super fast. I think a lot of senior engineers right now are stuck between a rock and a hard place. They are now doing all of these pull request reviews, CR of code reviews for all this AI generated code because of the safety concerns that are there. But, they're also getting a ton of pressure from C-suite to like put AI into all of the products, revolutionize how AI processes are done within the company. I think there's just this big identity crisis that's going on right now, which is like, "What's my actual role?" And then, "What does success look like in this new world?" The way I look at the evolution of AI models is that they started with being like an intern who cannot really do anything without supervision. You need to be very specific about what you want with them, and they will come back with a small piece of work that you can maybe use. And then later on, the models just kept getting better and it started feel more like a junior engineer now, and you can assign a whole task. And oftentimes, you will get the right results, which is good. And it will keep going. It will learn how to work with large systems and how to not turn every code base into a mess. I think it will get there. And then, when we look at our role, we software developers previously spent a lot of time writing code. But when code can be written by AI and super fast, our time started be spent on defining what to code, right? This is happening in a lot of companies right now, that people start spending time defining the requirements, figuring out what is the right thing to build, because otherwise, what's happening very interesting a lot of teams is that people who just started to learn how to work with AI, they realized, "Oh, I can put up a prototype so quickly. Let me just raise 20 prototypes. And hey, like help me review my PR and get those these prototypes merged." And the whole team turns into a chaos. And sometimes, these prototypes are being raised by VPs and directors and managers, right? The team start to have this burden. So, I think people will need to figure out how to actually make efficient use of AI, and that process can is going to take a while. I've been out of the game for a couple of years now, so AI wasn't even allowed when I left the company. But I do feel for these senior engineers, especially at Amazon. They had a very large outage. Apparently, they had some agent in the cloud that decided to delete some some services and >> [clears throat and laughter] >> a very efficient solution for a certain type of prompt. And so now there's some broad policy that all changes need to go through a senior engineer. Yeah. So their entire day is just reviewing code. And no, they can't just have the AI do the code review. Like they need to be the ones that are there. How would you advise that particular type of senior engineer to get out of that problem? Is it just like, nope, you have to deal with it? Is there a better answer for this person other than to like wait until things change? Yeah, great question. And I I I actually don't think anyone has a perfect answer right now. At least everyone I have been talking with are still figuring this out. Like it's really interesting when you look at social media, what people are talking about, a lot of the times it's like those very specific techniques. Oh, I have this skill that helped me plan things so much better. I have this markdown file. Gary Tan has this G stack, right? Uh the whole repo got like 60 GitHub stars. It's just a set of markdown files. People spend so much time talking about these things, which is like interesting, like they are worth investing and figure out, okay, what kind of optimizations we can do. But I don't think that should be the primary conversation. I think we actually need to spend more time to figure out what is the new way of working. How do we actually operate in this new world? For example, we talk about code reviews, right? Everyone's realized, okay, code review is a problem now. It's the bottleneck because everyone's writing so much more code. Then people started to look at PR review and say, oh, why is it so slow? Let's build some products and tools to make it faster, right? People are doing that. Cursor acquired Graphite to just solve the code review problem, I think. A lot of companies are doing this. But we should actually step back and ask, should PR review still exist? Are we optimizing something that should no longer exist? And the reason I say that is PR review was done in a world where one human writes some code, another human reviews it, and checks and balances, and makes sure the guardrails are in place, and just offer a different perspective, right? In that world, okay, PR review is the mechanic to do that. In this new world, an AI agent has written the code. The author is the checks and balances. So, the author is already looking at the AI code and making sure it's in a good state, and then raise it. How much value do we get from having another human having another look? Right? So, I think we actually have to rethink, okay, how do we actually operate in this new world? Do we still need a PR review process, or should we change the compliance and regulations and everything to say PR review is not the right thing anymore. We actually need more things that happens when the first author looks at the AI-generated code. How do we help them make sure the code is good, and they can confidently merge it. So, that is like a whole space of exploration I think is not happening enough, and I think people should talk about that more. But, to your question of the senior engineers in this position where everyone's racing AI slop, and they are accountable for making sure like those things are good. My advice would be to not carry the burden manually, because if those senior engineers put themselves as the reviewer of all the AI slop, they will lose that battle, 100%. What they can do though, is to build systems that can help them automate a lot of the pain. So, when senior engineers review a piece of code, what do they actually care about? What problems have they actually found that were not easily identifiable by AI? Can they turn that into a skill? Can they turn that into an agent that can just do that for them moving forward, right? There's a lot to be done over there. I don't think there's a very proven playbook for how exactly to do that at scale. Everyone's figuring this out, but I have seen some people do this uh to a certain degree of success. And I think that's where the senior folks should be spending time to build systems that can combat with the problems they see. So, no answer. >> [laughter] >> Yet, I do think that there should be some refactoring of the code, refactoring of the architecture to reduce blast radiuses. I think generally that's going to be the right answer. I also think that providing the prompt that the AI code generated is also really important as well. And then part of that prompt should also be how do I make sure, how do I ensure that there won't be a bunch of production issues that are going out. And then like also including that inside of the review as well. Let me ask you this. Yeah. Do you think there is always going to be a human in the loop when it comes to code generation and pushing out to production? Uh short answer is no. Um I think what's shifting now is that software developer's role is shifting more and more towards the higher level of abstraction. So, when AI is a junior developer, the develop the human developer is playing a senior developer's role. When AI is operating as a senior developer, the human developer will have to operate as a uh engineering manager role. And when the AI is able to do an engineering manager role and can self-orchestrate within a team, the engineer's role, the human engineer needs to shift to a director. So, what does that mean? A director, when they look at their org, they care about developer productivity, right? So, a CTO that has a company with 50 engineers, they care a lot about developer productivity within their organization. What kind of things are slowing those developers down? How can we make them faster? How can we remove those roadblocks and uh improve our tooling, everything? The same thing has to happen with agents. The human engineer needs to look at the agents and ask, how can I make them work faster? How can we identify inefficiencies happening there? So, I think the humans uh role will just keep shifting towards the higher level of current organizational hierarchy. We will work as a engineering manager, a director, a VP, and eventually a CEO, where the rest of the organization is just agents. I think that's my theory for what's going to happen if AI capability can keep advancing. With that assumption, if we look at what an engineering manager do, they don't always review the code. They almost never do. They almost never do. Yeah. So, how do they know the product is ready to ship? They ask questions like, "What have you done for testing? Did we do end-to-end testing? Did we do some dog fooding? Did anyone actually use the product and gave some feedback? Did we do some scalability testing, load pressure testing, everything?" Right? They ask those questions, and those questions don't require human looking at the code. If AI is operating as the IC engineers and we developers shift into a EM role, then we will not touch the code anymore. And I think we should be okay with that. I think that's eventually where things will shift into as AI becomes more capable. And this is where I touched earlier about losing control. I think learning to lose control is actually a very important skill in this AI world, because people who like micromanage, who really needs to control every single thing, is going to find themselves being the bottleneck. I just don't know how you get there. We have these millions of lines of code, these production systems that are serving so many people, so many users, edge cases that have never been documented that sort of only exist there, metrics, monitors, alarms, gigabytes, terabytes of logs of things that are going on out there. Mhm. I just don't know how we get from senior dev to engineering manager to director. This is like I just don't see a line of sight. I do see potentially a line of sight for people going from zero to one fully AI and then potentially building there. I don't see a lot of like taking existing and then like sort of like pulling the inside out. >> I think it's not going to be immediate, and I don't think it's going to happen at a large scale overnight, but we will see uh start to see some companies, especially startups, operate that way, and they will start to demonstrate what kind of systems have to be input in place to allow that to happen. Like let's take a step back, right? Even looking at pre-AI world, pure human organizations, we still have selves. We still break systems, and we still like make those mistakes, right? So, Facebook went down a couple of times uh when everyone was human. There was no AI. >> [laughter] >> Right? Amazon as well, AWS. I I think AI is maybe worse and like amplifying some of those problems and weaknesses in our system, but they are not the root cause. I think it's really uh about how we establish our systems in a way where these outages and blast radius can be minimized. I think we will very likely start to see changes being more controlled in terms of like like feature gating and AB testing before rolling out to production uh at scale. So, some of those systems, I think will start to be leveraged more to control the blast radius. Let's move to a segment that I call bullish, bearish, or So, I'm just going to go through a bunch of topics, and then you tell me whether you're bullish on it, you're bearish on it, or you think it's BS. Okay, sound good? Okay, Facebook releasing a useful frontier model. Bullish. You're bullish on it? >> Bullish. They invested a lot. They had good people. They had hired a whole bunch of very talented researchers, and they had the investment that was needed. The track record was not that promising. They have been investing in this for a while, and when you have the right people and have the right investment and have everything needed, the ingredients are all there. I'm pretty bullish uh, will happen, and I think it's going to be a good thing. If they keep the same philosophy of, uh, building open source, open weights models, that would be a very beneficial thing for the ecosystem. So, uh, bullish, bearish, or on Open Claw? Open Claw. Bullish. Bullish. And, uh, I definitely don't think it's Um, I think it is a really interesting combination of agent harness setups that allowed a mainstream adoption and realization of what agents can do for them. That in itself was very valuable. Just like ChatGPT, before ChatGPT, large language models were already there. Google invented it first, but no one built a useful application, so, uh, the mainstream didn't really think about this too much, right? It didn't start this AI evolution. I think ChatGPT had this moment where it became good enough for the mainstream people to realize how good AI is. And Open Claw did the same thing. So, I think it's useful in that sense. How defensible is that going to be? Uh, is someone else like Cloud Code going to replicate everything they do and get more adoption, more mind share? I don't know. I think that is a dynamic that will continue to evolve. Just by itself, the accomplishment it has done on the industry is already, uh, very big one. Yeah, absolutely. And I love that it's open source. I have my Open Claw like just updated itself constantly, but then also distill the release notes so that I know exactly like man, the the rate of change that there for that particular project is absolutely astounding. I'm also bullish on it, though. I try not to let my that that particular opinion known cuz I feel like everybody kind of poopoo's on it. What do you think about local LLMs? I'm probably more bearish than the average people working with local LLMs right now. There's a community of people, tinkerers, very bullish about local LLMs and they try to make the most use of it. I think that is good. Um, and I I we should have more explorations and more models that can be run locally and can do things for people. My theory here is that a local hardware is never going to match what a data center can do. Yeah. So, there will always be a gap. What will likely happen is that the local hardware can get to a state that is good enough for a lot of things, and we will run those things for free. That becomes how we leverage local LLMs, uh and that itself is valuable. But, I don't think that will be the cornerstone of a new industry because the intelligence just requires so much resource, so much compute that has to be done by an infrastructure, like how we get uh power, how we get water, right? How we get internet. It's not by inventing everything in our house. We could do that. We could build a generator. It's not going to be as efficient. It's not going to be the mainstream. It's going to be fun for a lot of people. I just don't see it fully closing the gap with the frontier. It's like the people that want to go off grid, and they they set up solar panels and a battery, and it's like, cool, you know, you're part of the solution, you're giving back, but ultimately, it's going to be a fringe thing. Like, I think you get the most bang for your buck by connecting to the grid. Bullish, bearish, or AI PMs is the hottest role in tech right now. Why why why is that case? Is there an argument for it? So, the way that the argument is synthesized is essentially, now that code is solved, for whatever that means, a pretty technical product manager can come in with their tastes, and they can say, "Hey, this is the thing that needs to be built." And now they don't need devs in the loop at all. Like, they're technical enough, maybe they've crossed some sort of threshold, they understand how some software is built. Now, they are more powerful than they've ever been. If you believe in this hierarchy of yours, where, you know, it was interns to senior devs to engineering managers, when we get to that point, a PM could have sensibly say, like, "I have an AI dev team," right? And so, my taste is the thing that's actually going to make the product a success. >> Mhm. Okay. Okay. Okay. I think the thought process is very reasonable, but there are some flaws in that argument. I don't think every AIPM has great taste. >> [laughter] >> It's actually pretty rare to have a PM with great taste that can translate to something that's actually successful. I think a lot of people claim they have great taste or they can mock up something that looks beautiful, but they cannot actually build a thing that is both useful and has great taste. It has to be a really nice balance. That itself is a very complex process. I think that process, it doesn't always require a PM. That's why I called on that argument as my first reaction. I think everyone can be that person and can bring taste into a a thing they built and can really leverage AI in the way a PM would. An engineer can get a lot of value. An engineer has been more powerful than ever and a designer has been more powerful than ever as well. Kind of everyone that has the passion to build something now has a superpower to help them do it and what they need to do is to really focus on what are the right problems to solve. How do I bring some judgment and taste into the solution of the problem, right? So, that it will actually get attention and can actually solve real problems. That is not tied to the PM discipline. So, I think yeah, while PMs they they are becoming more powerful than they ever has been, they are not the only ones. Marc Andreessen talked about this Mexican standoff, you know, designers, PMs, and devs questioning why the other groups exist or that the other groups existence is their days are numbered. Do you see a situation as the organizations evolve where there's essentially a design leader, PM leader, and a dev leader that are working in concert or do you see it more as one person that's building everything together like on their own. >> more like the latter. So, I think everyone will start to acquire skills from the other crafts and they become better at those crafts and can operate more autonomously, especially with AI. AI kind of raised the the floor. Someone who has no idea about go-to-market can just talk to AI and get to a pretty reasonable level of like building a good strategy for product. And someone who has no knowledge about like product business and design, they can get like some decent capability from AI and then they can learn from the other crafts, right? My assumption would be that the talent stack will collapse and everyone's skills tend to become more uniform and like people will be less specialized and more generalist and more versatile. Those people will have advantage over others and that will become an incentive for more people to become like that. Do you think of a a world where maybe in like a large organization, devs are these super generalists? They are working together to orchestrate agents or do you think of them as carving out mutually exclusive ownership boundaries and then making sure that they are responsible within those boundaries, but not really collaborating with each other? I think there will be still human collaboration. When you look at what one person can do versus what one person collaborating with a lot of other humans can do, I think the latter will always win. Uh when you really have a lot of smart people working in the same direction. So, I think human collaboration will not go away, but it will raise the bar for when do you need that collaboration and when is the right trade-off. So, when you work with one person, I think right now a lot of startups, the golden path they have is like they build something, have some like reasonable traction and start to get funding to grow a team, right? To have more people working together. I think one person can now go further without having to do that. One person can do a lot without having to get funding because all they need is like $200 for the subscription. They can go pretty far. So, I think the bar will be raised, but it will not be eliminating the value of human collaboration. Well, what's next for you, Kun? Yeah, so I left Big Tech. I have been with big companies all my career and I think when I look at my next steps and where can I really learn something that's completely new, I think I have to jump into a very different experience. And right now with AI, it just felt like the right moment to acquire a very different experience. Right now, I'm a solo builder. I have a whole bunch of ideas that I piled up over time that I would love to explore. I would also love to start creating some more content of my journey, what I learned to share with others and engage with the community. I think that would be a really fun role for me to be in and I will learn a lot and hopefully some of the things things I build will be useful. That's awesome. I'll put all of your links for your YouTube channel and your Twitter in the description. Kun, thanks so much for having the conversation today. It's been great. Yeah, my pleasure. Thanks, Steve.