Lenny's Podcast: Product | Career | Growth
00:04:04 · Fiona Fung
[00:04:04] S1: Oh, I love this kind of love walk back in time. Yeah. IBM, working on DB2, the operating system services team. Back then I was thinking, "Oh, what's a hard area of the stack?" And I really thought the lower level you go closer to the OS, then it's more hardcore and you'll learn more. So I was really fortunate to gone into the IBM internship. But the funny thing was, I think there's even a big shift from IBM to Microsoft. So at IBM it was I think VIM. I didn't have an IDE that we used. I think there might have been an Eclipse license, but for some reasons, most of us didn't use it. So I remembered it was mainly like VIM and kind of terminal debugging. And then when I joined Microsoft, I mean, this is how naive I was, I didn't even know about IDEs and such. And back then you didn't really get to pick teams. His was early 2000s. Actually, first off, I should say I was so grateful that I landed the internship and the role, because to take us all the way back in time, the dot com bubble burst in 2000. And so for my graduating class, a lot of the companies weren't hiring or were hiring freezes. So I was so fortunate when Microsoft extended me an offer. And so they're like, "You're going to work on Visual Studio." I did not even know what Visual Studio was because I came from a Unix school. So I remembered asking, because I was thinking, well, the name Visual Studio, I'm like, "Oh, is this a better Paint program?" And I could tell the look of my manager's face like, "What is going on?" But then it ended up becoming the love of my life for the first 11 years of my career. But that was the first time I used an IDE. So joining the Visual Studio team seeing, "Oh wow, here's an IDE with debuggers and you can set break points and do multi-threaded debugging." That was also always mind-blowing for me to think about the stepwise change. So yeah, that was kind of the story going from IBM to Visual Studio. And then what I really loved actually about Visual Studio is I was on the Visual Studio editor team. So I used a VS editor to build the VS editor and that's where my whole love of dog fitting comes from. I remembered I wanted to first and foremost create a delightful experience, not only for myself, but for my teammates, because also if we go back in that time, if you remember, I mean, when did Twitter come out? Was it 2006 or so?
00:06:22 · Lenny Rachitsky, Fiona Fung
[00:06:22] S0: It feels like it's been around my whole life. [00:06:25] S1: But back then, before social media, it was also harder for most engineers to hear fast customer feedback. For sure, there you would be user research sessions or we would have customers visit us. But you didn't get the rapid feedback that you do nowadays. But back then I was so lucky because I was on VS. We ourselves gave each other so much rapid feedback because we were all heavy VS users on the team. Yeah. When I worked on Visual Studio, back then we also shipped software on CDs. [00:08:20] S0: I remember that.
00:08:20 · Lenny Rachitsky, Fiona Fung
[00:08:20] S0: I remember that. [00:08:22] S1: And that's why they were really hard deadlines because you had to make sure the software was ready for us to give to manufacturing, to then put on the CDs for us to then put on the shelves. And then so once that was another shift when we actually started to be able to ship software online. And I think that's the interesting thing, and I kind of mentioned this in my talk, it's engineering time was really precious resource, but you also have these really hard deadlines, for example, like printing software and CDs. And so back then you would do a lot more planning because you just wanted to make sure given the time you have, you make the best of it. And that's a shift that we're seeing with Claude Code and Cowork is coding is no longer the bottleneck. And so now you showed the tweet and that graphic, but now it's all about where has that shift happened. Now not only engineers, we also have designers, PMs, everybody on the Claude Code team checks in code. So when not only more people checking in code, but kind of different disciplines, but also the throughput is so high, how do we think about verification? That's kind of this other shift that I'm seeing.
00:09:27 · Lenny Rachitsky
[00:09:27] S0: Maybe just kind of set this theme that I want to have for this conversation. A lot of people are just wondering what is software engineering, managing software engineers, managing software and product teams look like in the future? And you are living through that right now. So you mentioned this point about a more focus on verification, making sure the quality of the code being 8X is actually high and something that will work. So just like let me ask this broad question, let's kind of see where this conversation goes. What does an AI pilled software team look like in 2026?
00:10:03 · Fiona Fung, Lenny Rachitsky
[00:10:03] S1: Because the roles are blowing, it's shifting more to this builder. Everybody starts being a builder, I would say. The other shift that I've recently done is I actually have a Claude Code remote session that I enlist in all of our repos. And so this way I have full visibility into the work that everybody's doing. And this instance, it also has access to all our Slack channels and I'll have access to how are the metrics of everything we track. And so every month when I'd be like, "Hey, you know what's fun? Let's take a look back." And so we'll actually do it together. I'll share my Claude Code, I've shared my screen, then we do our Claude Code session and it's just about, "Hey, what were the focus areas? What were some of the products that got shipped? How did it do? Oh, what were the feedback channels?" And so even though before I would've just used these sessions to generate PRs and bug fixes, I actually have these sessions to enable me to have conversations with folks that I support. [00:11:03] S0: Say more about that. So this is a management technique, let's say, to help people not just ship but actually ship better, understand if they're shipping things that have impact. Is that kind of the idea here? Just use Claude to keep on top of all the things people are shipping and then make that a conversation with them?
00:11:03 · Lenny Rachitsky, Fiona Fung
[00:11:03] S0: Say more about that. So this is a management technique, let's say, to help people not just ship but actually ship better, understand if they're shipping things that have impact. Is that kind of the idea here? Just use Claude to keep on top of all the things people are shipping and then make that a conversation with them? [00:11:20] S1: Exactly. So yeah, outside of just the action of shipping is how did it do in market or, hey, did we caught some bugs? And it's okay to, I have this saying, make new mistakes. It's okay to make mistakes, just make new ones so that we're always learning. Because if you aim to make zero mistakes, that probably means you're not moving fast enough or being a little bit too cautious. And so by having Claude, so then it can also look at, for example, actually, I was just looking at, oh, given some of the incidents that we have, let's look across all of this. Can we generate a theme? What's a good area investment for us next, especially we think about quality. Are we seeing any hotspots of where there could be a gap? I think that used to be just a much more manual process, I would say. If I look back a year ago, I don't think I would've been able to have some of these insights with Claude. [00:12:12] S0: Yeah. Well, partly it's because there's that and also people weren't shipping as much so you could just make a little bullet list. Here's the things I shipped last quarter, this feature, that feature, this feature, that feature. [00:12:22] S1: That's right.