Lenny's Podcast: Product | Career | Growth
01:01:26 · Lenny Rachitsky
[01:01:26] S0: Yeah, speaking of data science, I have a data science friend and he was just saying how data science is so different now where now most of their job is people doing their own not amazing data science work using AI, and then just showing it to the data scientists, "Here, here's the analysis I did. Can you just make sure it's right?" And half the time it's not right, and so the job is just a whole different job now instead of doing the work that they thought they wanted to do. Now it's like, "All right, I'm just reviewing all this AI data science all the time. What the hell?" Along the lines, coming back to just how your team operates and how things are changing, let me see if something comes with this question. What should an engineering manager expect from their team now versus a couple of years ago, what's a normal, I don't know, baseline expectation of how things should work other than just we're shipping faster, is there anything else?
01:02:20 · Fiona Fung, Lenny Rachitsky
[01:02:20] S1: Oh, interesting. Well, definitely I think most commits are Claude assisted, and so that was a shift. I think I kind of mentioned we have Slack channels with all the feedback and also our dashboards that we have gave to Claude. I think having engineers keep building that stronger product sense muscle is I think also another, and I think that in general helps with these really strong-minded product engineers. I would say more of these roles that were traditionally non-engineering, you do now see engineers, and sometimes you're just blocked by waiting for a cross-functional partner. I think there's less of those blocks now just because the models are able to augment additional capabilities that you may not have as an engineer. [01:03:12] S0: So it's kind of interesting. It's both directions. Engineers becoming more product-minded and responsible for the quality and success of a product, and then everybody becoming an engineer more and more. [01:03:23] S1: Yeah, that's right. Yeah, it's all blurring. [01:03:26] S0: Yeah, I forget who said this, but there's this like, " What is a role anymore?" And this guy said that it's like, "What's the average of what you do? What's the highest percentage of what you do, and that's kind of your role now," whatever it is to be. [01:03:40] S1: Yeah.
01:03:40 · Fiona Fung, Lenny Rachitsky
[01:03:40] S1: Yeah. [01:03:41] S0: Oh, man. I want to come back to your point about obsession with the product. Living, breathing, the product, dogfooding. I talked to a bunch of people that work with you about you, and that's the thing that came up most, just your obsession with living and breathing the product, using the product constantly, whatever it is you're building, this idea of dogfooding. Talk about just why that is so important, why that's something you instill within your teams and reports.
01:04:06 · Fiona Fung
[01:04:06] S1: Oh, love it. Yeah, I think it's really and this has worked for me. It's just been a really good way for me to keep a pulse. Anytime you build product, there's a dream. You're really hoping to enable an experience or making an experience better. So I think that helps me keep really close to the pulse. I also think, and maybe for sure on Visual Studio, that was where I got this love of it, but it's interesting because even Marketplace, I remembered once in a while, even after I left the team actually, one time I had a MacBook Air I wanted to sell. I'm like, "Oh, I haven't sold anything on Marketplace." And I could not believe it the minute I put it up for sale, a seller or buyer tried to scam me, and it was an interesting new scam vector I didn't detect, but that goes to, again, people will use your products in ways that you may not expect. And so especially as leaders or even anyone on the team, we all have different life, actually, it's funny when I was supporting the VR and AR teams, somehow how I used VR, the setup, I would always be able to find these really weird floor height issues. So that ended up being a, "Oh, I'm going to help us," because somehow I got a good repro environment, and so I think it's number one, that's how you keep your pulse on the product that you're building and don't get too lost in metrics and dashboards only, or presentations.
01:05:40 · Lenny Rachitsky, Fiona Fung
[01:05:40] S0: I think that's such an important point you're saying there that I just want to make sure people here is just like there's always this idea of anecdotal evidence and just examples versus the data, and what you're saying here is as a product leader, as an engineer leader, you've found a lot of success in the anecdotes, the specific little one-offs that you experience as a user versus obsessing with the data only. [01:06:02] S1: Yeah, and actually sometimes it's also how I've been able to most effectively help the team. So for example, the last team I was on, I was leading a VR team and because back then I have not checked in any code into that code base just because I was really worried about messing up the operating system, but what was a gap? We were doing a lot of polish fixes and I'm like, "Hey, you know what? I'll use my job fitting time to actually vet how the experience looks." And so that was also probably a way that I felt I could still meaningfully contribute to help hold the quality bar for the team, and then like I say, every team member usually always really appreciates because I think as a lead leader, you're supporting folks on team that outside of metrics and everything, everybody really wants to make sure their work matters and just making sure that leaders use your product. I think folks feel the leaders, and then remain really engaged and not too distanced.
01:06:02 · Fiona Fung, Lenny Rachitsky
[01:06:02] S1: Yeah, and actually sometimes it's also how I've been able to most effectively help the team. So for example, the last team I was on, I was leading a VR team and because back then I have not checked in any code into that code base just because I was really worried about messing up the operating system, but what was a gap? We were doing a lot of polish fixes and I'm like, "Hey, you know what? I'll use my job fitting time to actually vet how the experience looks." And so that was also probably a way that I felt I could still meaningfully contribute to help hold the quality bar for the team, and then like I say, every team member usually always really appreciates because I think as a lead leader, you're supporting folks on team that outside of metrics and everything, everybody really wants to make sure their work matters and just making sure that leaders use your product. I think folks feel the leaders, and then remain really engaged and not too distanced. [01:07:06] S0: And this connects a lot with your point that engineers need to become more product minded, that engineers need to become more PM-y, but this is like as an engineer, this is one way to do it. Use the product constantly and that'll help you understand what is missing in the product as a user because you're just using it.