Lenny Rachitsky: belief

Transcript context

…I spent seven years at Apple and learned under Steve Jobs when he was the CEO, learned what we called the death march, which is what we did to the engineers. It was like as soon as you shipped one version of the iPhone, you were just immediately thrown into the pit of building the next one and there was no break. It was just relentless and talk about an extraordinary outcome at the end of the day. There is no relief. In a competitive market, and if the market is valuable, it's competitive, no question. If you leave anything on the field, if you sort of leave a crack for your competitor, 100% chance they're going to go fill that crack. And so you have to be relentless. There can be no relaxation of the organization. It doesn't mean people can't come and go or people can't take vacations or live their lives, of course. And it's not like people are human beings. You can't grind the individuals down, but the team as a collective group of people has to be sort of on the ball all the time. There can't be a break. And if you leave one, you're just begging for the slightly more hungry competitor to come in and eat your lunch. And that's the beauty of capitalism. Also, very counterintuitively, and maybe the more optimistic perspective here is when you do give your team space to just twiddle their thumbs, bad things start to happen. Morale actually dips in my experience. People get distracted. They're like, "Oh, what are we even doing? It's not interesting." I find that keeping people busy and motivated and fired up, even though you may think they'll be happier taking a many week break and slowing things down, I find they get more, the more I actually goes down in those moments. So here's a management framework that I use fairly often. As an executive, you don't know how to get any decision exactly right. It's not knowable. You don't know how much budget to allocate. You don't know how many people to put on a project. You don't know how to set a deadline for when you're going to ship something. But of course, you have to set some default so you make your best guess and then you manage to that best guess and you learn as you go because in software development and in business in general, everything's emergent. These are not things that are knowable top down or a priority. And so you take a best guess and knowing that you're not going to get the right answer, you need to decide whether over-steering or under-steering relative to your perceived midpoint is better. And so let's talk about staffing. When you staff a project, is it better to overstaff or is it better to under-staff knowing that you can't get it right? Well, it's better to under-staff. If you overstaff, you get everything that you just said. You get politics, you get people working, I think most importantly on things that are further down the priority list than necessary. You have like 20 things on a stack rank list and you know that you got to do the top five, but the next 15 data's kind of ambiguous, but you've overstaffed the project. So the next 10 things down are getting worked on. Before you even know if they're necessary, that is poison. It's wasteful, it slows you down, it creates crust. And so it's very clear that under-staffing is less evil than over-staffing. In this particular framework, the advice is under-staff deliberately, always. And then the wisdom, the wisdom element is to know not to under-under-staff and sort of knowing the difference between those two things. And so that's the way we work at Rippling. Everyone is constantly asking for more resources and of course where we can afford to and where it's appropriate new resources arrive, but it is really important to me that we feel that we've deliberately understaffed every project at the company.…

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