Lenny Rachitsky: preference

Transcript context

…Great question. Yeah, it's very hard to identify. A few things. One is, does the engineer want to win in the market? Does the engineer really care about winning against competitors, winning the hearts and minds of the customer? Do they understand the business context in which they operate by which they need to do that? Are they curious about how the company makes money, about what customers love and don't love, about what the most important project is and why it's important? They're asking you questions about the business outside of just the engineering domains. Are they able to execute on what they said they were going to execute without your help or do you actually feel like you need to be behind them? Are they the one actually setting the pace, asking you to keep up with your specs, keep up with your decisions, respond more quickly to the things that are blocking them, bringing more PMs or more designers to do more things? Are they being proactive in different channels where you think it's actually your job, but actually they'll jump in anyways? For example, we have different Slack channels with a bunch of people sometimes asking questions or raising issues or having blockers. And you have engineers who are just jumping in and explaining how a feature works, getting the feedback and fixing a bug proactively. And you may think, "Well, that's not the priority. I need to control what the engineers are doing." That's not your job actually, that's not your job. Your job is to make sure that they're aligned with the long-term vision and that they can deliver what they've committed to, but on top of that, they can do whatever the hell they want. And if they're taking on something that puts the things that they committed to at risk, they'll communicate that. So, again, that proactiveness, that desire to help, that desire to improve that accountability on their product. If their product isn't performing, if their product has feedback, are they doing it themselves or they need you to push them? So those are all mentality and culture aspects. I'm not even getting into the technical rigor and the quality of their systems and the velocity of code because I'm not a good judge of that. That's not really my role. But those are the things that I would immediately look at that, I think, is just fundamentally different in the engineering team that we built at Ramp versus others. And it's just a big part of the culture shift and the culture that we've been able to build. That was an awesome answer. And I think as a PM, you often don't want your engineers and designers to have such strong opinions and to be so on top of everything because there's just like, "Oh, no. Okay, here's what I think we should actually do," but engineers have all these opinions. And what you're saying is that's what you want to lean into, assuming you trust that they know what they're doing and can actually get things done. And so it's like a catchment to you a little bit, but I think that's a really unique culture and approach. And so that's an awesome answer. And, look, there's drawbacks to that culture where you get to a radically empowered engineering team that thinks that they know the product better than the designer or the PM and they push back on the designs or they disagree with the PM, but I'll take that culture any day compared to a culture where they're just taking things at face value and not challenging the thinking and not actually thinking from their own perspectives. And it is like I'll take someone on my team any day that challenges what I tell them to do or what I think is important and is maybe a bit harder to manage, but it'll make me think way deeper about what I'm asking them and what I think is important. And I'll grow as a manager much faster because of that.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.