Lenny Rachitsky: commitment

Transcript context

…That's really interesting. I got to tell you, the dominant failure case that I see in the real world is always, again and again, not enough detail. And it's also the most common failure mode where the engineers run back to the product folks and say, "I'm not getting enough from you." It is really like that, but I can understand why the hair stands up on the back of the neck a little bit thinking about it because, of course, if you give a senior engineer like, "Here's how I want you to go implement the schema for this database change for this model," they're going to be like, "What do you think? Who are you? Who are you?" You know what I mean? But what's really interesting is it's not a universal thing. The amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who's on the team. So, if you have a more junior person who's on the build team and then you have a more senior engineer who's involved in the shaping, they can make that junior engineer much more successful with additional detail. So, we're going to do this and I would suggest approaching it like this, this, this, and this. That junior person is, when they don't know how to do it, they're not going to ask because they don't want to show that they don't know, and they're going to hide the fact that they're lost and it's going to blow up later in the project. And on the other hand, if they are given more guidance, they're going to be able to be successful. They're going to learn about this is how this person who knows well, kind of approached it and then in the next round or a few projects later, you can dial it back and say, "Well, let's give less detail and see how they handle it." So, you can really give people bigger shoes to grow into and help them to be successful. And then, of course, you can also do it the other way around where if you've got some really stellar talent on the team and you have a long history and you have a lot of trust that they are going to be able to understand and solve it, then of course, you can leave things out. But the thing that I often see is if there's someone on the build team who really feels that they should be involved in the fundamental decisions about the approach, then a better solution would be to actually bring them into the shaping and have them play that technical role in the shaping session. If they have the right skills and the right perspective and the right knowledge to play that role well, then just bring them into the shaping. So, it's all about how do we bring people into a moment where we are using their strengths and then we're giving them an input, so that whatever their work step is that they're able to apply the maximum creativity, but also have the maximum clarity, so that they can really use that time well and also feel good about what they're doing. It feels like the core of this is de-risk the biggest risks and address the biggest unknowns as much as possible. There's probably this 80% of here are the risks. Let's just understand them deeply before we commit to this appetite. That is exactly right. There are these, we can call them rabbit holes, we can call them time bombs. There are these things where we say, "Oh, it'll be fine." One example, simple example, I worked with a team and they had a step of onboarding in a FinTech product and there was this step of onboarding and they would lose a lot of people in the funnel at that step because you had to fill out a whole bunch of information, and they figured out that they could actually pipe that data in from one of the partners that they had. They were partnered with banks and they're like, "Oh, we don't even need to be asking people this. So, we're going to fix conversion. We're going to eliminate a step from our user experience. It's going to be great." The thing that they didn't look at was if you go into the code on that step of the onboarding, it's not actually one step. There's like three different branches of that step depending on which bank the customer is integrated on. And so, that's the kind of thing where it all sounds so great and simple, and then you get into the weeds and you realize like, "Oh, wait a minute." You know what I mean? So, now, we have decisions to make. Now, if you're in the middle of a project and it's already been resourced and people are already on the hook that we're supposed to be doing this, and you already got the alignment that the engineering time is happening for this, and you're finding that out in week four. You know what I mean? You did all these beautiful drawings, by the way, and now, you're finding this out in week four, that's a bad place to be. But if we're in the shaping room and we didn't kick this thing off yet, we didn't even green light the project yet, and we have an engineer there, not just the product people, not just the designer, but we have that engineer who really insists on sometimes, I like to think of it like the grumpy old plumber who's seen everything and he insists on opening up the walls and looking at the pipes before he'll give you a quote. So, it's like when you've got that person in the room, they're saying, "Yeah, that all sounds great. Let's take a quick look at the code and figure out what screen you're actually talking about. Just let's just take a quick look." And it only takes a moment to open up the code, find this thing that we're talking about, and really look at it and say, "Oh, it's more complicated than we thought." And now, it's not like, "Okay, now, we're screwed and the project is going to be bigger." Now, we can have a really cool conversation about trade-offs. So, let's say we've got three different integrations here, three different segments integrated into different banks. How big are they relative to each other in terms of the deals we made or the percentage of customers who flow through those three different conditions? If we just did this on one of those branches, would it be a win?…

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