Moving fast and navigating uncertainty | Jeremy Henrickson (Rippling, Coinbase)

1. 0:00 – 3:24

   Jeremy’s background

   1. JHJeremy Henrickson0:00

      It's very, very tempting to, to kind of float up here as a leader and say, "Hey, you know, you take that hill over there. You guys do this over here," when in fact, like, what, where you really learn where the challenges are, or the problems, or the successes is by, like, just, like, being there (laughs) with, with the people in the trenches on, like, one of the things, like, whichever one seems hardest or most complicated. And so I try to do that as often as I can, and I found that I always learn (laughs) a lot by, by going through that detailed exercise.

   2. LRLenny Rachitsky0:32

      (Instrumental music) Welcome to Lenny's Podcast, where I interview world class product leaders and growth experts to learn from their hard won experiences building and growing today's most successful products. Today my guest is Jeremy Henriksen. Jeremy is senior vice president of Product at Rippling, where he leads the product and design teams. Previously, he was chief product officer at Coinbase, where he oversaw 10X growth of the product and engineering organizations and helped scale Coinbase during one of the craziest times in the crypto markets. In our conversation, Jeremy shares his lessons about maintaining velocity of scale, creating a culture of fast decision making, the importance of product leaders going deep on a problem and becoming world experts at their domain, what to look for in product managers you're interviewing, why relying on frameworks can be so detrimental to your success, why you may want to avoid MVPs and instead design for the most complex use cases first, and tons more. Enjoy this episode with Jeremy Henriksen after a short word from our sponsors. Today's episode is brought to you by Miro, an online collaborative whiteboard that's designed specifically for teams like yours. The best way to see what Miro's all about and how it can help your team collaborate better is not to listen to me talk about it, but to go check it out for yourself. Go to miro.com/lenny. With the help of the Miro team, I created a super cool Miro board with two of my own favorite templates, my one-pager template and my managing up template, that you can plug and play and start using immediately with your team. I've also embedded a handful of my favorite templates that other people have published in the Miroverse. When you get to the board, you can also leave suggestions for the podcast, answer a question that I have for you, and generally just play around to get a sense of how it all works. Miro is a killer tool for brainstorming with your team, laying out your strategy, sharing user research findings, capturing ideas, giving feedback on wireframes, and generally just collaborating with your colleagues. I actually used Miro to collaborate with the Miro team on creating my own board. And it was super fun and super easy. Go check it out at miro.com/lenny. That's M-I-R-O.com/lenny. This episode is brought to you by Mixpanel. Get deep insights into what your users are doing at every stage of the funnel at a fair price that scales as you grow. Mixpanel gives you quick answers about your users from awareness, to acquisition, through retention. And by capturing website activity, ad data, and multi-touch attribution right in Mixpanel, you can improve every aspect of the full user funnel. Powered by first party behavioral data instead of third party cookies, Mixpanel is built to be more powerful and easier to use than Google Analytics. Explore plans for teams of every size and see what Mixpanel can do for you at mixpanel.com/friends/lenny. And while you're at it, they're also hiring, so check it out at mixpanel.com/friends/lenny.

2. 3:24 – 5:25

   What it was like leading product teams at Coinbase during the crypto boom

   1. LRLenny Rachitsky3:25

      Jeremy, welcome to the podcast.

   2. JHJeremy Henrickson3:30

      Thank you so much for having me. I'm excited to be here.

   3. LRLenny Rachitsky3:32

      So, I've heard nothing but amazing things about you and I'm excited to learn from what you've learned from your experience at Rippling, at Coinbase, and all of the products and teams that you've built. And so thank you again for being here.

   4. JHJeremy Henrickson3:45

      Yeah, super happy to be here.

   5. LRLenny Rachitsky3:46

      So, I want to start with, uh, with your time at Coinbase, where you were chief product officer. And you were chief product officer during maybe the craziest time in the crypto markets. It was, uh, I think, 2016, 2018 when... I was looking at the Bitcoin prices and it was like... It went from, like, $1,000 to $20,000, I think, in a, in a matter of months.

   6. JHJeremy Henrickson4:04

      Yeah.

   7. LRLenny Rachitsky4:04

      So, I'm curious, what was that experience like? And, in particular, what was it like leading a product team through that experience?

   8. JHJeremy Henrickson4:10

      The, the strongest memories for me, for me are during, like, 2017 where crypto, which had kind of been at its nadir in, like, early 2016 and kind of slowly started climbing out, um, just kind of took off and became a real thing in the, in the public consciousness. And, you know, Coinbase, which at the time had, you know, an exchange, just like on-ramp and off-ramp from fiat to, to crypto and back, experienced over the course of 2017 40X growth (laughs) in, in usage.

   9. LRLenny Rachitsky4:39

      That's like a dream come true for, for a lot of people.

   10. JHJeremy Henrickson4:41

       It's, it... No, I mean, it, it was... It was both a dream and a nightmare.

   11. LRLenny Rachitsky4:45

       Mm-hmm.

   12. JHJeremy Henrickson4:45

       Um, you know, and I was, I was incredibly lucky to be working on it with a, with a team of people that I could really trust and could stand shoulder to shoulder with in, in the trenches. And it was a lot of learning about how you can rapidly scale systems, you know, over time. And, you know, people like to trade crypto on Saturday mornings (laughs) and so, uh, a lot of Saturday mornings, it was just, like, some new, like, like, thing would break on the edges of the system and we need to kind of get in there and, and, and work on it. And so it was just a lot of really incredible lessons about who you choose to work with, and focus, and making sure you have the right people in the room at the right time.

3. 5:25 – 7:35

   How Jeremy kept teams focused and the biggest challenges he faced at Coinbase

   1. JHJeremy Henrickson5:25

   2. LRLenny Rachitsky5:25

      Okay, so let's actually unpack a couple of those. So, focus is really interesting and something people always talk about, but, you know, hard to actually do. I guess, how did you keep the team focused? I imagine just, like, you know, everyone's getting rich all over the place in crypto.

   3. JHJeremy Henrickson5:38

      Huh.

   4. LRLenny Rachitsky5:39

      Things are breaking all the time. Like, how did you maintain focus on, on your team?

   5. JHJeremy Henrickson5:43

      Well, the first thing is you don't talk about people getting rich (laughs) .

   6. LRLenny Rachitsky5:46

      Mm-hmm.

   7. JHJeremy Henrickson5:46

      It's like, it's a, it's a very technical... It's very technical. You talk about, like, it's customers. It's their money, right? And number one, it had to be secure, right? so there's a guy named Philip Martin, a friend of mine now, and he's, he's just this amazing, like, security leader, um, at, at Coinbase. And he was able to always put these, like, decisions that we were making extremely quickly-... like in context, right? And say, "Look, these are the kinds of decisions we can make and still have it be secure no matter how fast we, we need to move." And so security was always, like, the number, the number one thing. And then the second thing is, like, focusing on, like, the, the both the kind of immediate nature of the issue. "Hey, site is down," or whatever, and, like, resolving that. But also trying to set those in a context of, like, where we need to go over the next six months. Like, what are we actually shooting for? What do we believe the volumes are going to be? What's it gonna take to, to, to have, you know, everything from a user experience to kind of the, the deep backend of the product that w- would actually work for them?

   8. LRLenny Rachitsky6:41

      What was maybe the biggest challenge as a product leader trying to keep people focused and everything on the rails as things were going 40X?

   9. JHJeremy Henrickson6:50

      I think the biggest challenge was that in crypto ju- there's just so much uncertainty in general. Like, simple questions like, "Is Ethereum gonna be a thing?"

   10. LRLenny Rachitsky6:59

       Mm-hmm.

   11. JHJeremy Henrickson7:00

       Right? Are the subject of debate. And no one actually, you know, at the time, had an answer to that question. Lots of really strong opinions. And so you have to be able to have those debates because, 'cause lots is going, lots is going on. But then you have to be able to come out of those conversations with a clear kind of company point of view that you're all, that you're all shooting toward. And, like, while there may still be differing points of views and debates that happen on the margins, like, you go full speed toward this answer until you decide to go full speed (laughs) toward a different answer. And I thought we were pretty successful at that, um, at Coinbase, and it wasn't always easy. (laughs)

   12. LRLenny Rachitsky7:32

       Maybe just a last question there.

   13. JHJeremy Henrickson7:34

       Sure.

   14. LRLenny Rachitsky7:34

       Living

4. 7:35 – 8:52

   Advice for going through intense periods at work

   1. LRLenny Rachitsky7:35

      through a time like that, a lot of people are going through these periods of just, like, intense work and it's like, holy moly, this is, uh, crazy stressful, working, like, incredibly long hours. But then you look back at those times and end up being the most important meaningful periods of your career.

   2. JHJeremy Henrickson7:51

      Mm-hmm.

   3. LRLenny Rachitsky7:52

      I guess, one, is that, is that your experience too? And then two, I guess, is there any advice for someone that's maybe going through something like that of just, like, here's, uh, here's maybe the silver lining of being in a period like that?

   4. JHJeremy Henrickson8:03

      So it's hard, right? It wasn't, wasn't always easy. I had, like, a new daughter who had been born just a few months earlier, right?

   5. LRLenny Rachitsky8:09

      Oh, wow.

   6. JHJeremy Henrickson8:09

      Really tough to, like, kind of balance, balance those things. But I've always loved the rate of learning.

   7. LRLenny Rachitsky8:17

      Oh.

   8. JHJeremy Henrickson8:17

      And, and so like those... I- it is those experiences I feel that, like, have most sort of accelerated my own personal growth and personal learnings 'cause it's in the, in the crucible of things being hard. And so I think when people are going through those times, it's nice to take, like, you know, a, a step back and talk with friends or whatever about, like, what's really, what's really going on and setting it in the context of, hey, you know, three, four, five years, uh, from now when we look back on this we realize, wow, you know, we A, we did something amazing with that time, and B, we, we learned a lot and we were able to take that with us kind of into the, into, you know, whatever we were doing next after that.

5. 8:52 – 12:07

   Maintaining velocity at scale

   1. JHJeremy Henrickson8:52

   2. LRLenny Rachitsky8:52

      Before our chat I asked you what people ask you for advice most around. And you said that it's... That people often ask you for advice on how to maintain velocity at scale.

   3. JHJeremy Henrickson9:03

      Mm-hmm.

   4. LRLenny Rachitsky9:03

      Which, uh, is something every founder and product leader is always striving to do.

   5. JHJeremy Henrickson9:06

      Yep.

   6. LRLenny Rachitsky9:06

      And so what have you learned and what do you tell people about maintaining and maybe even improving velocity as you scale?

   7. JHJeremy Henrickson9:12

      I, I think there's a lot of different answers here, and I think a lot of them are, are very specific to the nature of the business that someone's in, right? Different businesses can maintain ve- velocity in, in different ways. I think there's kind of a universal truth that you want, like, small teams with clear missions, right? You know, if, if there's 300 people trying to work on one thing, like, uh, the... Just sheer, like, communication challenges, Dunbar's number, all of those things come into play, and it's really, really hard to act quickly. And so having smaller groups of people breaking down what is always a very, very large problem into, like, sufficiently small, small bits that small groups can attack wholeheartedly and minimize, like, horizontal communication I think is, is the first thing. I think the second thing is that to the extent it's, like, a technology problem, the more you can bake into, like, a, a clear platform, um, it reduces, like, the decision-making complexity for everyone who's working on, like, the domain part of the problem. And so, like, a clear platform with a clear interface, you can get easy to use in all the ways that both engineers and product people want it to be easy to use simplifies the, the, the space in which people have to think about these problems. Um, and that's not always easy, (laughs) right? Platforms are not y- you know, you can't just, like, write a platform and hope it's gonna work for the products. It's very much an iterative thing. But the more one can invest in that and have the right kinds of people who are capable of doing that sort of both systems thinking and product thinking simultaneously, um, I think is really important. The third thing, just from a leadership point of view, is, like, diving deep, right? Like, it's, it's very, very tempting to, to kind of float up here as a leader and say, "Hey, you know, you take that hill over there. You guys do this over here." When in fact, like, what, where you really learn where the challenges are or the problems or the successes is by, like, just, like, being there (laughs) with, with the people in the trenches on, like, one of the things, like, whichever one seems hardest or most complicated. And so I try to do that as often as I can, and I found that I always learn (laughs) a lot by, by going through that detailed exercise. And I think the, the last thing is just making sure the teams have, like, the right distribution of, like, experience and, and seniority. Like, sometimes you get a team started and the team is, like, perhaps doing something that's, like, zero to one and they're amazing at all this zero to one stuff. And then, like, two or three years later, like, those same people are trying to, like, scale the product to, like, you know, millions of people, and it turns out that A, they don't like that part of the job as much, and B, maybe they're not as good at it. So I think you end up just constantly, like, look at the team and make sure that A, people are doing things that they love. And if they're not, like, "Hey, try this other thing instead," right? And, and B, like, recalibrate the team and make sure, like, the right kind of skill sets are there. And I found if you kind of do all of those things and then have product leadership where we're saying, "This is what we need to do," right? And very, very clear and precise on, on what needs to be done, then you can usually actually accelerate over time because you bake more into this platform. It allows your engineers to do more with less, and that's always pretty amazing.

6. 12:07 – 14:29

   An example of small teams with clear missions

   1. LRLenny Rachitsky12:07

      Okay. Let me dig into a couple of these. These are really great.

   2. JHJeremy Henrickson12:10

      Yeah, please. (laughs)

   3. LRLenny Rachitsky12:10

      Um, (clears throat) so with the small teams with clear missions, is there an example of that at Rippling or Coinbase where that was, like, a really good example of this being true?

   4. JHJeremy Henrickson12:20

      One example is maybe three years ago when I, when I was, uh, just starting at the company, um, we decided that we needed to build a time and attendance product. Um, lots of market demand for us in that. We hadn't built it yet, something that many customers need. And so there were a bunch of ways we could have chosen to do that. But the way we did it was to say, "Look, let's find one engineer, really talented systems engineer who's actually capable of doing kind of product thinking, and have Parker," CEO, "also spend time on it." And you start there, right? And Sachith brought a few people on with him, and those four people over the course of maybe nine months or so built a time and attendance product. It was the only thing they were doing. They didn't have to worry about what was going on with our payroll product except to the extent they had to integrate with them a little bit, right? They didn't have to worry about what was going on with the kind of, the benefits team or kind of our IT products. They were, they were monomaniacally focused on this one thing and then identifying the places where, yes, you, there's connectivity to, to the rest of the suite. And that allowed them to move extremely quickly.

   5. LRLenny Rachitsky13:24

      How much of that was Parker being on the team helping them unblock everything versus being very small and focused?

   6. JHJeremy Henrickson13:30

      I think it was mostly small focus. Like, obviously Parker can, like, do things and unblock them in the way that only a CEO, um, can and that, and that helps. The thing is at Rippling, like, we've now replicated that, like, you know, a dozen times, right? That's our model for s- for starting new things. And so it can't just be him unblocking things, though he does (laughs) unblock things. It's more that, like, this pattern of having these small groups, like, be able to do things. And then being able to ha- like, go to those people, right? Whether you're Parker or somebody else in the company and be able to say, "A, how are things going?" Or, you know, "Are we working on the right things?" Or, "Let's see the latest designs for that thing and comment on it." Like, all of those things can happen just at a much greater tempo than if you're, like, trying to go three layers down into the org and, and do things. I think that's the other maybe key point here that, like, everyone is exposed to senior leadership. Like yes, we have, like, a management structure 'cause you have to, but that management structure does not interfere with the ability of kind of anyone anywhere in the organization to kind of, like, look at what's actually happening. And that happens very directly.

7. 14:29 – 18:03

   A model for building products

   1. JHJeremy Henrickson14:29

   2. LRLenny Rachitsky14:29

      So let's talk about that model you just described. So what is that model? So this is how you approach new products. And I know within Rippling there's many, many products and features. We're gonna talk about this.

   3. JHJeremy Henrickson14:38

      Yeah.

   4. LRLenny Rachitsky14:38

      And you're saying that you have kind of an approach to adding a new business unit essentially or new product feature.

   5. JHJeremy Henrickson14:42

      Yeah.

   6. LRLenny Rachitsky14:43

      What is, what is that model roughly?

   7. JHJeremy Henrickson14:45

      Yeah. So the model's quite simple. In, in the vast majority of cases, we realize we need to build something. Um, and we have, you know, the, the one-page view of what that is. And usually we're lucky enough that the things we're building sort of exist in some form in the industry today. Not in the differentiated way that we can build it, but, like, time and attendance as an example, like, that's a well-known thing in the industry. There's whole companies that do only that, right? So we start there. We find a single engineer who is extremely entrepreneurial, understands what it means to operate at tempo, understands what it means to, like, make decisions with low information, understands how to work very, very quickly with, like, a design partner. So we have a design partner. And we say, "Look, come into Rippling, spend a few months getting to know the platform, first of all. So go work on this other team, understand what's easy for them, what's hard for them, how the platform works, how other products have been built on top of this. Go talk with other, like, people who founded products here and understand what their experience is so that you can learn from and iterate on it. Get an opinion about your product and then start building it." Um, and during this intervening time, they're also recruiting, right, a team of usually two, three, four other engineers who kind of have that same zero to one mentality, and they start building. And, uh, usually over the course of, like, six to nine months, we can get a product from, you know, a blank sheet of paper to something that is launched or at least that we're using sort of internally when we dog food our, our stuff really heavily. Um, and then it grows from there. And then sometimes when you launch one of these products, you get close to launch, you realize, hey, actually a team of five or six people can, like, kind of handle this product ad nauseum. Sometimes you have to bump it up. It's like, okay, this thing's about to go to production. There's all these other things to do. The team needs, now needs to go from 4 to 15 or something like that. Really depends on, on the product. But that, that's the general life cycle and then you, you keep growing and scaling it.

   8. LRLenny Rachitsky16:34

      That is fascinating. So just so I understand, you find a founder type to kind of take the lead on a new idea, and do you recruit them internally or you sometimes find them externally just to focus on this new product?

   9. JHJeremy Henrickson16:46

      Both. Both.

   10. LRLenny Rachitsky16:46

       Interesting. Okay. And then you find a design partner for them to work with to figure out what exactly needs to be built, and is it idea pick one design partner or you try to encourage a few?

   11. JHJeremy Henrickson16:56

       Um, usually it's one. Like, so there's a designer, right? So we have, you know, a, a design team there and-

   12. LRLenny Rachitsky17:00

       Oh, design partner, meaning a designer, not a company that is, like, their partner in designing with.

   13. JHJeremy Henrickson17:06

       Oh no, no, no. No, like, literally somebody who-

   14. LRLenny Rachitsky17:08

       Okay.

   15. JHJeremy Henrickson17:09

       ... who, who, you know, knows Rippling's products, knows, like, our component library, knows all of that stuff and is, is, is skilled in, like, doing, you know, UX and, you know, interaction and, and visual design.

   16. LRLenny Rachitsky17:19

       Got it. Okay, designer. Okay, good. Cool. And then they basically with maybe a couple engineers just, that's the team that initiates a new product line and then launches it and then as it scales, it maybe grows the team, maybe not?

   17. JHJeremy Henrickson17:33

       Yep. That's right. And like, you know, every, you know, it's pretty ad hoc but every couple of weeks or something like that, they're meeting with, like, me or with Parker or, you know, whichever one of us is, like, the DRI on it and, like, giving feedback on the designs, kind of having a critical eye for like, "Oh man, if I were using this as a admin at, you know, a small company or an admin at a large company, how would I feel about this? Would this interface work for me?" And so we were pressure testing it, like, kind of throughout, throughout that cycle and trying to get the balance of, like, you know, speed and comprehensiveness

8. 18:03 – 22:26

   Jeremy’s thoughts on MVPs (minimum viable products)

   1. JHJeremy Henrickson18:03

      right.

   2. LRLenny Rachitsky18:03

      This reminds me, you're also, I hear, not a big fan of MVPs, that you like building-

   3. JHJeremy Henrickson18:08

      (laughs)

   4. LRLenny Rachitsky18:09

      ... products to further, to a further point. Is that, is that true? And then if so, how do you, how do you think about the initial version of a product?

   5. JHJeremy Henrickson18:16

      First of all, I don't want to knock on MVPs. I think-

   6. LRLenny Rachitsky18:18

      (laughs)

   7. JHJeremy Henrickson18:18

      ... MVPs, like, have their place. They're, they're extremely useful, particularly if you're, you know, literally a zero to one company that's never done anything before and you don't have, like, clear market validation. I think in our case specifically, for, for Rippling, a minimum viable product would do a disservice, like, to both our customers and to, like, the very team that was building it. And the reason I believe that is that when, when you design a minimum viable product, you're optimizing for speed. And in that s- opt, set of optimizations, you are minimizing the deeper product thinking about what can, like, fully differentiate our product based on not only existing, kind of, capabilities within our products and platform, but based on what it ought to do in the future. And so it sort of limits product creativity, but worse, it leads to building the wrong thing technically, right? So if you're only thinking through the simple cases and you're an engineer and no one's pushing you on saying, "Wait, what about that, you know, healthcare or hospital administration case where like, you know, it's mission critical now," then you're going to make a different set of ass- architectural assumptions. And then you're going to build on those and you're going to build on those for six months, nine months, a year, and you'll have dozens or hundreds of assumptions built on top of those, and it's extremely difficult to unwind those decisions once you've built them into the product. And, and therefore, you know, we believe very deeply, it's like sure, understand those simple cases, right? Understand if you're a two-person company, you don't need all of these other things and what is the product gonna look like for you to approach it? But also, understand what it would mean to have 10,000 people globally around the world with this, like, ridiculously hard use case. What's the model that would support that, right? And let's make sure that as we're doing the technical and product design for this thing, that it accommodates that view, even if we're not gonna support it in the first version, (laughs) right? Even if we make, like, the product decision to say like, "Look, we actually don't need to handle that case right now," you still build a product in a way that's not gonna, that's not gonna prevent you from getting there in the future. And does that take a little more time? Sure. Yeah. But does it save you time in the long run? Absolutely, right? And so, um, so that's our approach.

   8. LRLenny Rachitsky20:39

      Is there an example that comes to mind of a product you built at Rippling or Coinbase of just like, it could have been this really simple MVP and then ended up being like, no, we did the right thing by building it further along the spectrum?

   9. JHJeremy Henrickson20:49

      Yeah. So I think a great example of this at Rippling, uh, is our global payroll product, right? We could have said, "Hey, look, um, we just need to support this one country," right? "We need to support, uh, whatever, the UK, let's say. So we're going to copy all of our US stuff, like just replicate it and, like, change all the things to be UK-like." That would've been the fastest thing to do tr- dramatically (laughs) oversimplify, right? But that's not what we did. What we did is we said, "Look, we need to launch with six countries and these are six super different countries that we, that we want to, like, look at and they're gonna have different requirements from, like, an HRIS standpoint, from an employer of record standpoint, from how you pay global contractors, from how payroll works, and we're going to make a system that works for those countries." And there's, like, lots of downstream implications for that. But what it means is that now our global payroll system, adding a country is, well, it's not easy, (laughs) but it's a lot easier than it would have been if you had to, like, continue to stamp out and replicate and then of course maintain all of these things that have very little underlying connectivity. And instead what we have is, like, you know, 80% of the system is baked into our global payroll platform and then, like, the 20% is, like, country specific. And most of that specificity can be handled not by engineers, right, who are very, very expensive to change things that are, like, local specific, but instead it can be configured by somebody that's in compliance, by somebody that's in legal that needs to get the right documents into the system. And all of that stuff can be handled by, by, by the system, uh, which allows us to move much faster sort of going forward.

9. 22:26 – 23:17

   Designing for the most complex use case first

   1. JHJeremy Henrickson22:27

   2. LRLenny Rachitsky22:27

      I've heard you describe this kind of idea as you encourage teams to design for the most complex use case first.

   3. JHJeremy Henrickson22:32

      Yeah.

   4. LRLenny Rachitsky22:32

      Is that kind of the instruction you give these teams?

   5. JHJeremy Henrickson22:35

      100%. Many times. (laughs) So it's one of these things that, like, until you're here, it's a really difficult thing to kind of grok because A, it's so counterculture to, like, the background that most people have come from. It's like, "No, no, no, don't think about all those things. Just, like, zoom in on this, on this one case, use it as a wedge and then grow from there." And this is one of the reasons that we have people, especially new people in these kind of founding roles come in and spend a few months just, like, absorbing the culture to, like, really, really learn, really learn these lessons and it's one reason that we're extremely high touch with kind of new products in, in their infancy to make sure that we just don't fall into that trap, right? Especially because, like, simultaneously with doing this, we're like, "Hey, but we need to ship this as fast as possible," right? And so you want to get the, the balance of those two

10. 23:17 – 27:09

    What a compound startup is and how it works at Rippling

    1. JHJeremy Henrickson23:17

       things right.

    2. LRLenny Rachitsky23:17

       So when I think about Rippling, I think of you got kind of the culture is to do things the hard way and the, the, the right way. And an element of that is there's this concept that I've heard that Rippling is this compound startup.

    3. JHJeremy Henrickson23:29

       Mm.

    4. LRLenny Rachitsky23:30

       What does that term mean? And then how does that approach impact the way you build product and organize teams and all the things you were just talking about, MVPs and, you know, building new products?

    5. JHJeremy Henrickson23:40

       The idea of a compound startup for us is that we're basically a lot of businesses that all work together, right? Like if you think about, about the products we offer, we have payroll. Well, there's entire companies built just on payroll. Insurance and benefits, entire companies, that's their entire life. In fact, like, a fragment of benefits is the entire life cycle of a whole company. Y- you know, our IT products, device management and identity management, time and attendance, each of these things are industries into themselves with, like, multi-billion dollar companies serving each of them. The insight Parker had v- you know, before he founded the company was like actuallyThe result you get that when you have that is that there's all this data that gets replicated and copied and is impossible to keep in sync everywhere. The right answer is to have a single system of record, one place, one database where all of that information is resident so that each of these downstream systems can always have the right data at the right time. And then you can build on top of that, you know, things like workflow and reporting and analytics and permissioning and, and all these kind of underlying capabilities. So the idea of a compound startup is like all of these different businesses benefit from being built on top of one platform. The activation energy for that is extremely high (laughs) , right? So before my time at the company, you know, Parker Persson, the technical founder, and others, you know, built all of the first versions of all of these products. And it was a minor miracle (laughs) they were able to do that. But having done it, right? We then had that platform and we could continue to build like new verticals and new startups, right, on, on top of that, um, on top of that foundation.

    6. LRLenny Rachitsky25:16

       This touches on something that comes up a number of times in this podcast, which is the importance of differentiation. And it feels like this is the differentiator for Rippling. It's not gonna be just a better... one of these vertical solutions, right? The main differentiators, we're gonna do it all and everything's gonna be so much better because it's all in one platform. Is that, is that kind of where the original idea came from or is there a different way to think about that?

    7. JHJeremy Henrickson25:38

       Yeah, I think that's right. So I mean, the, the, the fundamental contention is having a single system of record. I- is better for many, many, many reasons (laughs) , right? The, the most simple of which is there's, there's a single source of truth and like all of these other products can rely on it, but also unless you start without assumption of everything being in a single system of record, there's a bunch of other things you can't do, right? You can't, you can't build out a, I don't know, a permissioning system that looks at the various attributes across all of these products. You now suddenly have to do an integration and each of these products talks different languages. You can't do simple things like build a product and say, "Who is this person's manager?" Most products you can't do that. Most products, you find some system of truth, export everybody's name and email address in a spreadsheet. You know, have another email address or another name, maybe an employee ID of like who that person reports to and upload that to another system, which by the way is immediately out of date because organizational structures change all the time. Whereas with Rippling, it's always correct, right? We are the system of record. So all of our products, they're like, "Hey, who's that person's manager?" And the system immediately knows, right? And that's a very, very simple example of something that, that you can only do if you start with... Like solving, to come back to our earlier point, like solve the most complex use case first, right? Solve the fact that this data all needs to be in the same place. And so our ability to kind of differentiate, right, boils down to kind of that one fundamental decision, which just allows us to do things that are impo- literally impossible for any other company to do.

11. 27:09 – 28:14

    Rippling’s unique culture of fast decision-making

    1. JHJeremy Henrickson27:09

    2. LRLenny Rachitsky27:09

       What would you say is, uh, one of the most unique things about Rippling's culture that maybe you haven't mentioned yet?

    3. JHJeremy Henrickson27:15

       Uh, I would say it's fundamentally speed of execution, right? I, I think in speed of decision-making. It's the thing that i- is probably the hardest to explain to people before they're here. Like it, it's hard to understand until y- you experience it. Like, let's not schedule a meeting for next week or tomorrow or later today. You know, we're in the middle of a meeting, we need to make a decision. Let's either make the decision or if we can't, let's like Slack call in the person that we need in order to make that decision and we'll be done with the decision today. And like sure there are irreversible decisions you can't make that way, right? But for the most part, we really value like the tempo of decision-making and the speed, the speed of response. And no company I've been at, at any scale, five people, (laughs) you know, 5,000 people has ever operated at the tempo this one does. And I think that our ability to continue to operate at that tempo, which is partly due to the fact that we are a compound startup and have these small teams, independently operating teams and all the rest of that, is a really differentiating thing about the culture of the company.

12. 28:14 – 32:13

    Rippling’s leadership values

    1. JHJeremy Henrickson28:14

    2. LRLenny Rachitsky28:14

       I'm reading Kevin Kelly's new book, or I don't know if you've seen his new book. It's a, all these like little tidbits of advice and one of his pieces of advice is that usually the best time to do something is right now.

    3. JHJeremy Henrickson28:26

       Yes. (laughs)

    4. LRLenny Rachitsky28:26

       And that feels like that resonates with the way you all think. I'm curious just how you create that culture and ability to make decisions fast. Is it purely top down founder, this is how they behave? Or is there something else that you found is effective to create this culture of moving fast, making decisions really quickly?

    5. JHJeremy Henrickson28:43

       Obviously a huge piece of this is like Parker himself, right? It's an attribute of his personality, likes making decisions quickly and it's also a deliberate strategic decision on his part to like have a company that makes decisions quickly. And so he models this constantly, right? In Slack, in conversations, in person and in, in every way possible. And there's an expectation kind of throughout the company if you kind of look at our leadership principles, like his ability to make decisions quickly is something that kind of everybody promulgates. But also I think there's a number of things we've done to sort of like bake it in, right? Like in the way that we, you know, even do like say quarterly planning and the fact that like there's this timeline for decision-making that doesn't leave like, you know, a lot of room in the way that we expect people to know their domains, especially in product, right? In product, you're, you don't own like little feature. You own like your product and you're expected to be the world's foremost expert in it. And if you are, what that means is like instead of having to come back to people three days later with an answer just off the top of your head, you can be like, "Yes, this is what I think I should do about that." Or you know, "Give me 30 minutes to look something up and like I can tell you what we need to do about that." And so all of those things in combination just yield an environment in which these decisions happen very quickly.

    6. LRLenny Rachitsky29:55

       You talked about quarterly planning and you're saying that there's like here's the timelines, we need to make decisions on these dates. And there's a culture-

    7. JHJeremy Henrickson30:02

       Yeah.

    8. LRLenny Rachitsky30:02

       ... of just we stay firm to that and if you don't, then-

    9. JHJeremy Henrickson30:04

       Yeah.

    10. LRLenny Rachitsky30:05

        ... we're gonna move on.

    11. JHJeremy Henrickson30:06

        That's right. And so, and so... And it's, it's shocking to people when we actually move on, right? If they're, if they haven't been here yet. It's like, "No, no, that date passed." (laughs) You don't, you don't get to like retroactively like, like make everybody react to the fact that you didn't operate quickly enough, right? And it's, and it's not a, it's not a hostile thing, right? It's just a, people just have to get used to it, so it's a, it's a deep cultural principle and the fact that everyone stands behind it, uh, just means it's like gets reinforced on sort of its own, out of its own gravity.

    12. LRLenny Rachitsky30:34

        Do you have values, like internal values that you've kind of outlined that are a part of this? Or is that not something that you find super valuable?

    13. JHJeremy Henrickson30:42

        No, we actually ... I find them quite valuable and actually our COO, Matt McInnis, who, you know, joined the company about a year before I did, you know, he has been the one to, like, really drive this. And if, you know, you go to ... I can't remember the specific URL, but on Rippling, there's a ... Search for Rippling leadership principles.

    14. LRLenny Rachitsky30:55

        Mm-hmm.

    15. JHJeremy Henrickson30:56

        You know, there they are. Um, and they are really true to the culture of the company. The way we came up with them is, was to, to us, you know, a couple of years ago to introspect and to what the, what actually made people successful at the company, like who's successful? Why are they successful? Why do they enjoy being here? Or alternatively the opposite, right? Like why have people not worked out? Why do some people, like, not enjoy it here? And like those are the things that are differentiating and those are the things that we wrote down.

    16. LRLenny Rachitsky31:23

        Are you hiring? Or on the flip side, are you looking for a new opportunity? Well, either way, check out lennysjobs.com/talent. If you're a hiring manager, you can sign up and get access to hundreds of hand-curated people who are open to new opportunities. Thousands of people apply to join this collective and I personally review and accept just about 10% of them. You won't find a better place to hire product managers and growth leaders. Join almost 100 other companies who are actively hiring through this collective and if you're looking around for a new opportunity, actively or passively, join the collective. It's free, you can be anonymous, and you can even hide yourself from specific companies. You can also leave any time and you'll only hear from companies that you want to hear from. Check out lennysjobs.com/talent.

13. 32:13 – 33:44

    Advice for cultivating fast-decision-making teams

    1. LRLenny Rachitsky32:13

       For someone listening that's like, "We need to move faster," and everyone always feels this, "We need to move faster. We make decisions faster," what, what piece of advice would you give someone for helping them do this at their company?

    2. JHJeremy Henrickson32:27

       I think it's really context dependent, but, but I think it starts with, you know, whoever is in the role of, like, making the top level product decisions, right? Of them being, one, extremely clear about what those priorities are and more importantly extremely clear about what all the priorities aren't. Right? Like, there are so many things that, like, could be important or people can make the case for being important or whatever that, like, are fundamentally distracting from, like, the core mission of getting something done. But secondly, for that person to go all the way to ground on it, right? We have a, we have one of the leadership principles is go and see, right? So like so, so to, to look at the thing and then, like, walk all the way to ground and, like, talk with the engineer who's, like, writing the code on the thing because inevitably, this top level communication is insufficient to get to, like, the detail of, like, what matters and doesn't matter. And you don't have to do that everywhere, but if you do it in enough places, what it does is it creates a clear expectation of that kind of clarity sort of across the board and, like, forces everyone to sort of, like, up their game a little bit and just helps people understand what the expectation is. Right? And I think in the absence of those sort of clear expectations, it's difficult for people to, like, perform at their best, right? And so, um, we try to do that pretty frequently.

    3. LRLenny Rachitsky33:43

       Okay. I definitely

14. 33:44 – 38:42

    How deep-level thinking and working on the ground helped Rippling expand to other countries

    1. LRLenny Rachitsky33:44

       wanna spend more time on this, but, uh, before we get there ...

    2. JHJeremy Henrickson33:46

       (laughs) .

    3. LRLenny Rachitsky33:46

       Uh, so go and see. I love that, and that actually has come up recently on a number of podcasts, just the importance of people continuing to ask questions and going to, like, the end of what's possible. Uh, recent story was IO talking about building the cash card and going to, like, the warehouse and watching the printings of the cards and things like that.

    4. JHJeremy Henrickson34:03

       Yeah.

    5. LRLenny Rachitsky34:04

       I guess first of all, do you have a sense of where that came from and why that ended up being so important to y'all? And then two is just, is there an example of you doing that or someone you've seen do that and sh- and that leading to something really important?

    6. JHJeremy Henrickson34:16

       In the early days of our, um, kind of global efforts, right? When we were first trying to figure out, like, what global payroll was, it was really tempting to say like, "Oh, well, we're gonna go into the UK and that's going to be, like, relatively similar to what we're doing in the US." But our kind of head of payroll went in and said, like, "Actually, here are the ways in which, like ... We knew it was gonna be different, but here are the ways in which we didn't anticipate that it was going to be different." Which made us realize that we had to completely alter our approach, right? For how we think about learning about each of these countries and going into them and having, like, a fulsome experience and, and that then backs into things like, well, every country does tax filings. Every country does them slightly differently. But how are we going to build a tax filing system that's going to allow us to, like, satisfy the needs of every country in which we're gonna run payroll? Right? And it was only through that, like, very early on, like, deep look at how one country was actually operating and then doing the same thing with the next country that, like, we were able to set in motion all of those things, right? It's not like we knew all the answers at that point, but it allowed us at a much earlier stage to put in motion a bunch of stuff that we need to do that then got subsequently much more clarified and much more precise, um, over time.

    7. LRLenny Rachitsky35:30

       And so the, the leader of that team basically just went and studied the tax laws of each-

    8. JHJeremy Henrickson35:35

       Yeah.

    9. LRLenny Rachitsky35:36

       ... country?

    10. JHJeremy Henrickson35:36

        That's right. Like, went all the way, like, went all the way to ground. It's like, okay, like, let's go and open up the big old, like, I mean, it's, like, online these days, but the old tax book and look like, it's like ... Or when you're in the United States, like, you have to go look at Ohio or Pennsylvania, which have all these, like, little, like, local, like, city or county based taxes. Um, and it's, and it's incredibly instructive to look at just a few of those and think like, "Wow, how do, how do I think about, like, configuring these change, like, uh, unannounced, right? Like, some city administrator, you know, or the city legislature or whatever they call them, right, they decide to change the tax rate. Well, how are we gonna know about that? How are we gonna change it? How are we gonna change it so it's effective at the right time? And you don't think about those things until you've gone all the way to ground and looked at how these things are actually, actually worked, how they're communicated and how they're thought through. And I think the same thing is true of every aspect of every product, you know, in, in different ways. Right? it might be a technical thing, it might be a design thing, it might be a, a, a compliance or regulatory or governmental thing. But whatever it is, that detail always exists and unless you're getting down there and seeing it and understanding it firsthand...... you don't really understand what your product needs to do.

    11. LRLenny Rachitsky36:42

        And I think an important element of this that's between the lines maybe is don't delegate this to someone. Like you may have a-

    12. JHJeremy Henrickson36:46

        Mm-mm.

    13. LRLenny Rachitsky36:47

        ... tax expert on the team.

    14. JHJeremy Henrickson36:48

        Mm-hmm.

    15. LRLenny Rachitsky36:49

        And I imagine many leaders would be like, "Oh, go figure this out and tell me." And I think-

    16. JHJeremy Henrickson36:52

        Yeah.

    17. LRLenny Rachitsky36:52

        ... what you're saying is you go do that and learn, become the world expert at it.

    18. JHJeremy Henrickson36:55

        That's right. That's right. You go do it, you go learn, and then we can make the case for hiring the tax expert, right? Which we do have, by the way, now (laughs) , right? Like that's, that's an incredibly important part of our success is having that specialist, but not before somebody with a product mindset. Like the tax specialist is amazing at tax, right? That's what they're, that's what they're, they love and that's what they do. But that doesn't make them necessarily a great product thinker. Right? So the person with a product thing has to, has to get into those same weeds first to really understand it.

    19. LRLenny Rachitsky37:24

        Do you give any guidance on just like how much time to spend on all that stuff versus like, you know, the regular day-to-day of, say, a product leader on a team? You know, there's... It takes a lot of time to become a world expert on the tax, uh-

    20. JHJeremy Henrickson37:35

        Mm-hmm.

    21. LRLenny Rachitsky37:35

        ... systems of many countries. Or is it just like there's nothing more important than that, that is like your job and what are you doing not doing that? How do you, how do you think about it?

    22. JHJeremy Henrickson37:42

        I think it's an equally... You know (laughs) if a job is 80 hours a week, that's like 40 of your hours. Like it's, it's... I, I think, I think that, that it... You can't really understand a product unless you've gone there, right? And yes, it takes time. And you're right, you can't just ignore like the, the other half of the job of, you know, communicating with, you know, the engineering team and like writing documents or whatever. But like what's the point of writing a document if you don't know what you're talking about? Right? And so, and so we very deeply value that. And it's one of the reasons that we keep, at least at Rippling, our product organization really thin, right? We expect like a single leader, right? To be able to know like the full scope of the product. In fact, great product leaders can in fact do that because they like have this native curiosity and, and interest and like ability to absorb a lot of stuff. And, uh, it makes... It's a lot of fun (laughs) because now like I have a group of people around me who like are all like really good at what they do and really understand what they do, and that, that's kind of just an amazing, amazing place to be.

15. 38:42 – 40:42

    Why product leaders need to be right

    1. JHJeremy Henrickson38:42

    2. LRLenny Rachitsky38:42

       I'm looking at this list and I just wanna keep asking questions about it. Uh, one of the-

    3. JHJeremy Henrickson38:46

       (laughs) Sure.

    4. LRLenny Rachitsky38:46

       ... principles that I love is, and it reminds me of Amazon has the same principle, I believe, which is leaders are right a lot.

    5. JHJeremy Henrickson38:52

       Yeah.

    6. LRLenny Rachitsky38:53

       Why do you find that to be important? I know you w- weren't necessarily designing all these principles, but I imagine that's something that you guys follow often and comes up a lot.

    7. JHJeremy Henrickson39:01

       I mean, this is one of my favorite ones because I think for... Particularly for a product org, right? Because product leaders have to be right (laughs) most of the time because their decisions reflect across the entire org, and their decisions fundamentally spend time, right? And they spend energy. And if they make good ones, the company does really well. And if they make bad ones, the company doesn't. And one of the things I really value in product leaders are people who can go into like an ambiguish information with... Uh, ambiguish situation with incomplete information and like a dis- a complex decision space and can like look at that and listen to everybody and read whatever they need to read and say, "This is where we need to go." And like even if everyone else is like, "Ah, I don't know, that feels wrong for this reason or this reason," if they have like the confidence to like make that call, and then a year later when you look back on it, for them to have been right, that's extremely valuable. And it's one of these things that like it's really hard to test for, right? You can, you can get it by like talking with people and, and asking, "Hey, was this person like usually right in retrospect?" And people think about it. But like in the context of like a given company, just you have to take the time and see if those decisions are, are, are largely right. And it's the one value we have which is like you can't really learn it-

    8. LRLenny Rachitsky40:19

       Mm-hmm. (laughs)

    9. JHJeremy Henrickson40:20

       ... right? Either, either you're really, really good at making those kinds of decisions or you're not, right? That's a very peculiar skill that we, that we really value.

    10. LRLenny Rachitsky40:28

        Awesome. Shifting a little bit.

    11. JHJeremy Henrickson40:31

        Mm-hmm.

    12. LRLenny Rachitsky40:31

        I know you all are going through this global expansion. We talked about this a little bit.

    13. JHJeremy Henrickson40:34

        Yeah.

    14. LRLenny Rachitsky40:35

        And so just a few questions along these lines, 'cause a lot of companies start, you know, in one country. Most companies do. And then they decide, "Let's expand to new markets."

16. 40:42 – 42:29

    How Rippling decided where to expand to first

    1. LRLenny Rachitsky40:42

       So I guess first question is just how do you decide which markets to go after, and, and specifically where to start first? And then just prioritizing the list of markets. What's kind of your, your algorithm for that?

    2. JHJeremy Henrickson40:55

       So it starts with an assumption that we're gonna have to be everywhere ultimately, right? That, um, you don't actually have to build like native global payroll in every country in the world. It doesn't make sense to do that in every country in the world. But you definitely want to be able to pay people in any country in the world and you want to be able to have contractors anywhere in the world and have their information be in your HRS anywhere in the world. And so the decision for us, we were fortunate to... Or when we made that decision to have quite a few customers, r- running like thousands and thousands of customers. And so we knew not only where the kind of US employees were, but by virtue of being an employee system rep, we actually knew where they had other employees. And so it was quite easy for us to say focusing on US-based companies, which is incomplete data (laughs) , right? But if we just look at our US-based companies, we know that there is immediate demand for those people to pay people in, you know, countries X, Y, and Z. And we just like listed those out in raw numerical order. And then we kind of looked at, okay, how hard is it to build in these countries and how valuable is it to build in these countries, right? Like what is the strategic value of building in the UK or Canada or Germany or India or wherever? And then just... We had a discussion on like where is there risk, right? Where, where, where is this, where is this hard? Where is there a long pull? Where does this like... In what countries does it take like a long time to get approval or whatever? And we just stack ranked them and, uh, and then we revisited that decision, right? Like the early decisions that we made on w- exactly which countries. Like we have subsequently like reordered those over time, and as we've dove- dived in the countries and learned more, you know, we, we, we rejigger things like a little bit. But for the most part, like that same basic list we started with is still like, you know, mostly right.

17. 42:29 – 45:32

    The case for expanding internationally before you think you’re ready

    1. JHJeremy Henrickson42:29

    2. LRLenny Rachitsky42:29

       Okay. And then the other question a lot of founders always struggle with is when is it time to start expanding internationally? 'Cause you know, there's pros and cons. Do you have a sense of what convinced y'all to start going international?

    3. JHJeremy Henrickson42:41

       I think our case is slightly special, but I think the right answer to that question is always before you think you do.

    4. LRLenny Rachitsky42:46

       Mm-hmm.

    5. JHJeremy Henrickson42:46

       (laughs) Before you think you need to. Because like there are... It's harder than everyone... If they've never done it before, it's harder than you think it is. It's more specialized than you think it is. People in the UK really, really care if there's a U in color, right?

    6. LRLenny Rachitsky42:59

       Mm-hmm.

    7. JHJeremy Henrickson42:59

       Just as we care if there's not a U in color, right? (laughs) There's just, like, all of these subtle lessons that, like, cultural lessons for companies that take, like a really, really long time to absorb. And so my view is you always should do it earlier than you think you should, th-than you think you have to. In our case, it was always something we knew we had to do. In fact, we have a very clear thesis that companies that aren't global, particularly in payroll, but also in kind of insurance and benefits and, and IT, if you're not global, you're just not gonna be around in 10 years. Because companies were becoming global, and then COVID happened (laughs) and companies became global much faster, right? It stopped being the province of, like, 100-person companies plus, and like started filtering down into very, very small companies. It just became commonplace for small companies to be multi-country. And so that very much, um, accelerated kind of our, our timetable. And then you saw, you know, other people noticed that too, and you saw other companies starting to try to address parts of this problem as well. And so there's this kind of competitive dimension which is sort of secondary i-in, in most ways 'cause we were gonna do it anyway. But like that also kind of adds a little bit of a, you know, fire under the, under the thing.

    8. LRLenny Rachitsky44:07

       What have you found to be most surprising about expanding internationally to be successful in, in expansion for folks that are maybe starting down this road of like, "Oh, shoot. We should think about that."

    9. JHJeremy Henrickson44:16

       I think the thing that was most surprising to me the first time I did this (laughs) back at Guidewire in the, in the aughts-

    10. LRLenny Rachitsky44:22

        Mm-hmm.

    11. JHJeremy Henrickson44:23

        ... um, and remains the most surprising thing to most people, you know, every time I do this again, is that every country is unique. You can't just like, you can't just take your US-based approach and like drop it into another country. Other countries find it insulting. It doesn't matter how much success you've had here. Everyone always believes, rightly or wrongly, that their local context is special and you have to respect that. And it comes down to, like, little things like there being a U in color or not. Or, you know, if you ever see a demo delivered to somebody in another country where they see like a detailed screen about a person and it includes a Social Security number, it's like that you immediately lose credibility. Doesn't matter how good all the rest of your stuff is. And so I think that that, that is consistently the thing that I think is most surprising to people is the degree to which that's true, which seems obvious in retrospect, right? If you took, like, German system or something and, like, demoed it in the United States with, like, poorly translated stuff, we would think it would suck too, right? And so, but it's not... It's really hard to adapt to that mindset. And, um, and so it takes just a lot of energy to, to kind of overcome that organizationally.

18. 45:32 – 48:08

    Why Jeremy isn’t a huge fan of frameworks

    1. JHJeremy Henrickson45:32

    2. LRLenny Rachitsky45:32

       Makes tons of sense. I'm gonna go in a different direction now. Um-

    3. JHJeremy Henrickson45:35

       Sure.

    4. LRLenny Rachitsky45:36

       ... frameworks. So I know that you're not a huge fan of frameworks. We were ta-chatting about this before we started recording. And so I'm curious just to hear your perspective on why you're maybe not a fan of frameworks and then also just, like, how you crystallize processes and concepts for your team if you're not just like, "Here, here's a framework you should use."

    5. JHJeremy Henrickson45:54

       Look, I think frameworks are very helpful. That's why I'm not exactly anti-framework-

    6. LRLenny Rachitsky45:58

       (laughs)

    7. JHJeremy Henrickson45:58

       ... but I am anti-process as a substitution for deep product thinking, right? So I like to have just enough process to create a frame (laughs) , right? So the right decisions can happen and, like, no more. And I think there's a danger, especially as companies scale, that you end up saying, "Well, you know, if only we categorize, you know, everything correctly in Jira, like, you know, we will be able to make, like, really good prioritization decisions." I'm like, sure, extremely helpful to have clear categorization and, and things in Jira and have, like, data and analysis and to be able to do all of that stuff. But what you really need to do is decide what's important to build, right? And then, like, have a way to build it, like, really efficiently. And so, so I think the right answer, the right amount of process for any given team i-is like, or the right framework for any team is really just d-dependent on, like, their specific life cycle. So you won't see me saying like, "Oh, we need to use, like, this Scrum thing or that Kanban thing," or whatever, like, the latest, newest thing is. It's like, don't care about any of that. What I care is about something that's going to enable this team, in this context, at this point in their life cycle to build the right thing as efficiently as possible. And I'm fine if those are different for different teams. And the only place I care about unification is, one, on the quarterly planning process, and two, like, everything does need, in fact, to be in Jira because (laughs) otherwise you can't rationalize about what's actually getting done and not.

    8. LRLenny Rachitsky47:18

       Is there a process or framework that, uh, you find is, like, counterproductive that you're just like, "Stay away from this thing, uh, we've had a lot of trouble with it," or, or generally it's like, "Let's just rethink everything ourselves?"

    9. JHJeremy Henrickson47:30

       Um, no, I don't find one to be particular- I don't... I haven't consistently found one to be particularly problematic 'cause I think any framework sort of has its place, you know, right place, right time. I think there's, I think there's danger any one time somebody, like, dogmatically says, "I think we should use process X" 'cause that's almost never the right answer, in my, in my experience. I think, I think there are places where that can differ. Like, if you start a company, like, on the basis of process X and, like, everyone's bought into that process and everyone understands it, um, I think that could be really, really great. And like, and, and on the engineering side, I think this is hugely valuable. It's like test-driven development, first line of code is gonna be a test, not the actual thing. Like, fantastic, very supportive of all that. I think it's kinda different in the product world.

19. 48:08 – 52:49

    The differences between building product at Rippling and Coinbase

    1. JHJeremy Henrickson48:08

    2. LRLenny Rachitsky48:08

       If you had to compare the way Coinbase builds product process-wise or just product development process-wise to Rippling, what would you say are the bigger differences?

    3. JHJeremy Henrickson48:17

       I think the differences are largely born of, like, the different domains, right? So crypto, as we talked about earlier, really hard to predict (laughs) what's going on. There's all these questions about what's the future of crypto? What's going to matter? Like, what do we even need to build? What's gonna survive? And so the process we had at Coinbase around, like, having those debates and, like, getting to a decision and disagreeing, committing, and then from an execution point of view, being able to move fast, like that was the trick, right? At Coinbase. Here-We know the things that we need to build, like at a, at a high level. And the trick is how do we really differentiate it on the basis of like these amazing platform capabilities we have, or how do we have to evolve those platform capabilities, um, in order to continue to build something that's just discontinuously better than everything that's out there? And that like yields a different decision-making process. So for me it's like the mental model is actually of how I approach those things are the same, but they just like yield different results in the, in the actual, um, making of the software. (laughs)

    4. LRLenny Rachitsky49:12

       What is that actual difference do you find like day-to-day? Is it like timeline differences? Is it how quickly... I don't know, the way you structure, how far out you plan? What do you find is like the concrete difference as a result?

    5. JHJeremy Henrickson49:25

       I think the difference is in the day-to-day velocity of like decision-making, right? Because we can... You know, at Rippling if you're like on, I don't know, pick a random team, if you're on the device management team, like, you know what you gotta do. Right? There's no ambiguity. You're not debating about, you know, whether, you know, Mac or Windows is going to exist (laughs) in the future. Like, none of- there's none of that cognitive dissonance, right? There is we need to build this, it's hard to figure out how we need to build this, right, 'cause there's all these different things that we could leverage, but, but we need to basically get this done. And so the, the kind of total velocity I would say is, is higher here. Which is not to say people work harder or less hard at Coinbase. Like, Coinbase was, like, an amazingly fast, like, environment. But it was also subject to the fact that, like, you just don't know what the crypto markets are going to do, and you have to be incredibly reactive to that. And so I think maybe that's the one thing. Like, the, the reactivity to, like, the environment and the crypto environment, what's going on and the, the uncertainty of the regulatory environment, all that stuff. We got really, really, really good at handling those things really rapidly, which is something that we need to handle somewhat less, um, here at Rippling.

    6. LRLenny Rachitsky50:34

       Sounds quite stressful, uh, at Coinbase.

    7. JHJeremy Henrickson50:36

       (laughs) Uh, yeah, I mean, it was, um, it was fun. Like I, it stress-... Yes, it was stressful. I mean, every job I've ever had has been stressful, but in, in its own unique way. But it all- all of that stress I think is in the shape of a problem, that's in the context of a problem, that's really interesting. I mean, that's why I stayed at these places, right? And so, um, but yeah, it's stressful. (laughs)

    8. LRLenny Rachitsky51:00

       And looking back, what a joy.

    9. JHJeremy Henrickson51:02

       Yeah. No, g- they are very good memories. Like, I look back, I don't really... I remember the stress, but I don't, like, re-experience it, right? I re- I remember, like, you know, forging these relationships and building these amazing products that, that I've been so lucky to be a part of. And, um, and so I have, you know, almost only good memories (laughs) of, of the places I've been.

    10. LRLenny Rachitsky51:21

        That's what I find too. You go through these hardships, uh, and then you look back, and you're like, "Wow, that was so cool." But a-

    11. JHJeremy Henrickson51:26

        Yeah.

    12. LRLenny Rachitsky51:26

        ... assuming they go well, assuming the company works out, and like-

    13. JHJeremy Henrickson51:29

        True.

    14. LRLenny Rachitsky51:29

        ... it feels like, you know, it was successful. A l- a lot of times you're at a startup, you- your life sucks for two years, and it doesn't work out and that, there is a lot of ba- you know, upside and good memories to that-

    15. JHJeremy Henrickson51:39

        Yeah.

    16. LRLenny Rachitsky51:39

        ... but it's less, it's less, less glorious.

    17. JHJeremy Henrickson51:41

        Yeah, that's fair. Um, though, I mean, the, the, the first company I was really at, kind of out of school, this company called Reactivity-

    18. LRLenny Rachitsky51:48

        Mm-hmm.

    19. JHJeremy Henrickson51:48

        ... back in Internet 1.0 era, and, like, we were trying to figure out, like, how does this internet thing work and how do we start companies on the basis of these tech- new technologies, and how do we help other companies, like, build stuff and figure it out. You know, and that company, like, fundamentally, like, didn't work out. Um, ultimately got kind of spun itself out and got acquired, uh, which, which was great. Um, but, like, it was this extraordinary set of people that I was so lucky to work with, and I, you know, I loved all the time I spent there, and it was foundational to, like, everything else I ever did. And so even though that effort didn't, like, you know, pay off in the traditional set, like, the value of the, the learnings I had there and then the people I had a chance to work with was just really exceptional. So feel very lucky.

    20. LRLenny Rachitsky52:30

        That's a really good point actually, and I think I should correct even what I said, that even when things don't, like, work out traditionally, those experiences end up being incredibly valuable in all these unexpected ways.

    21. JHJeremy Henrickson52:41

        Yeah, 100%.

    22. LRLenny Rachitsky52:42

        Yeah. Okay. So final topic.

    23. JHJeremy Henrickson52:45

        Sure.

    24. LRLenny Rachitsky52:45

        I want to talk about hiring, hiring product managers and-

    25. JHJeremy Henrickson52:47

        Mm-hmm.

    26. LRLenny Rachitsky52:47

        ... interviewing.

    27. JHJeremy Henrickson52:48

        Yeah.

20. 52:49 – 58:29

    How Jeremy hires PMs at Rippling

    1. JHJeremy Henrickson52:49

    2. LRLenny Rachitsky52:49

       So you've hired a lot of PMs over the years. I'm curious what's something you've learned about what to look for in product managers and also just in product leaders that other people may not be focused on as, you know?

    3. JHJeremy Henrickson53:00

       Uh, like, I mean, I don't know that I have any, like, particularly special insight here. I, I think there's a couple of things that I do ask that I, that maybe are more of an emphasis because it's Rippling than, than not. But, like, the first of those is when people are done with going through our process, there's a part where they, they do this case study. And an important part of the case study is that it's, like, actually too complex for people to, like, have all of the answers upfront. There's just, like, the space of the problem is, is too large to do that. Which means that, like, in the interview there's a lot of opportunities, or in the case study there's a lot of opportunities to just, like, ask ad hoc questions or to, like, change one assumption, and seeing how people react to that is really indicative of how deeply they understand, you know, a new problem or how quickly or how mentally agile they are. And, you know, and some people are extremely good at that. They hear an assumption and they, like, blink a couple times, they're like, "Oh, well, that has, like, these 400 implications," right? And they just start rattling them off. And some people get, like, really flummoxed, right? Um, and obviously for our environment, that former is, like, really, really, um, important to us. I think the other thing that really matters to me is, like, the insightfulness of que- questions that people ask, which is indicative of, number one, their, like, actual interest in the job, right? Like, people tend to ask better questions when they're, like, more excited about working at a place and, like, done their research and are asking people about it. And also, like, the quality of those questions, like, can vary quite dramatically. And, and that's okay. I don't expect the quality to be the same all the time, but, like, sometimes people ask a question, I'm like, "Oh, man, I would have never thought to ask that question. That's such an insightful question." And then I pause and I have to think about my answer a little bit, and so it kind of pushes me to be a little bit better. Um, and when that happens, I know I have usually a pretty good candidate on my hands.

    4. LRLenny Rachitsky54:42

       Is there an example of someone asking a really good question like that that comes to mind that you think back to and like, "Oh, wow, that was great"?

    5. JHJeremy Henrickson54:48

       I remember about three years ago, I was interviewing a guy named Kyle Boston. And Kyle, uh, is now, now runs our platform product organization. And I can't remember the specific question he asked, but it had something to do with, wait a minute, if you have all these products and you have this like employee system of record thing underneath it, shouldn't we be thinking about like how to create these like various pillars of kind of underlying platform technology, things like p- permissioning all this stuff. And this was before we like fully formalized the concept of our like platform beyond the kind of employee system of record. And I remember thinking like, yes. Yes, we should. (laughs) And you know, that had entered our minds before, but the fact that somebody which, who had like almost no context on the company, right? That, that's what was impressive about this question is like, man, you've been thinking Rippling for like a couple weeks while you were like interviewing with a bunch of other companies or whatever. And like you've thought about it deeply enough to have this insight into the nature of the platform that we're building. Like immediately like gave me a bunch of confidence in, in his ability to kind of think through the sorts of things we need him to think through.

    6. LRLenny Rachitsky55:58

       And I think it touches on PMs need to be business leaders and-

    7. JHJeremy Henrickson56:02

       Yeah.

    8. LRLenny Rachitsky56:03

       ... great questions are often about the business and the future of the business and how to make it run more efficiently. And this in, you know, there's like a product org element to it. But I find that that's like a really under-appreciated element of PM areas, just like thinking about the bigger business, not just like the PM product.

    9. JHJeremy Henrickson56:18

       Yeah. For me, it's like two things. It's like thinking about the bigger business, right? And having, having the context like around, you know, whether it's like revenue questions or strategy questions, but also like the detailed questions.

    10. LRLenny Rachitsky56:28

        Mm-hmm.

    11. JHJeremy Henrickson56:29

        Right? It's like, oh wait a minute, the implication of this thing that I'm getting asked or of this thing, Jeremy, that you said earlier is all of these things, right? And their ability to kind of understand that, that this isn't a simple business. That it's really hard, it's really complex. And the ability to kind of, to have these insights to help them think through those details is really cool.

    12. LRLenny Rachitsky56:49

        You talked about this prompt they, you give product managers. Not to give away what you're actually asked these days, but is there an example of a prompt that you've given in the past or you think is like a good example of a type of prompt to give a product manager candidate?

    13. JHJeremy Henrickson57:01

        I, it, uh, in terms of like a general kind of approach, I think a prompt should always like reflect the actual business that they're gonna kind of come into, right? So, so when we do like, so our process overall is, is actually quite short. It's basically, you know, get in contact with us somehow, eventually get h- you know, connected with a hiring manager, have a conversation with them. Then more or less you have a conversation with me, which is a product discussion. And then we have a case study which follows that. That's the whole process, you know, modulo-

    14. LRLenny Rachitsky57:29

        Awesome.

    15. JHJeremy Henrickson57:29

        ... other conversations around the edges. And the questions that matter are around like how do people think through that product discussion, right? Which is relevant to our business, and how do people think through that case study? That's number one. And the second thing is there's always a part of my interview which is, which is, uh, maybe sounds very simple, but it's just like, "Hey, what questions do you have for me?" Right? We actually do that before we do the product discussion. And that's an incredibly important question 'cause, because it, it is again indicative of like these things that people have thought through or not thought through or kind of the, the depth of their thinking or their interest and engagement in the role. And like at that second discussion it doesn't have to be like perfect or anything. But, but it is a very strong signal when people, you know, whether they've thought through a set of questions they wanna ask or just like, you know, on the fly, like generating them, you learn a lot about how people think about product, about, you know, what they're looking for, about, you know, what they like doing and not doing just through those questions.

21. 58:29 – 1:00:19

    Advice for junior PMs

    1. JHJeremy Henrickson58:30

    2. LRLenny Rachitsky58:30

       For PMs that are maybe in their early career that are listening to this-

    3. JHJeremy Henrickson58:34

       Mm-hmm.

    4. LRLenny Rachitsky58:34

       ... what advice would you give them to help them accelerate and advance their career most in the early part of their career?

    5. JHJeremy Henrickson58:41

       Be humble. Uh, being a product person means that like by definition you're living in a world where like no one knows the right answer yet, because if somebody did, they would've already built it, (laughs) right? And so having like no matter how smart you are, and there's a lot of smart people out there, right? There's always stuff you don't know. There's always people who are gonna know things that you don't know. And it is only through that acknowledgement, right, that you can actually have the humility to say like, "I'm open to absorbing all of this stuff I don't know and open to synthesizing all this stuff and coming to different conclusions." And so I found that that humility is one of like the biggest differentiators in early career product leaders who sort of are, you know, able to let go of like how awesome they were in school or in their first job or whatever. I mean, I had to do this (laughs) right? And, and like, and realize like the job is always hard and the job is always about discovery every single day. And if you can maintain that like curiosity and elasticity of thought and, and creativity and like coming up with solutions, you'd be awesome. But if you close yourself off to that and think you always have the right answer, then there's like no hope.

    6. LRLenny Rachitsky59:49

       This touches on, uh, another principle that I still have sitting on my screen here, which is-

    7. JHJeremy Henrickson59:52

       (laughs)

    8. LRLenny Rachitsky59:53

       ... uh, great leaders change their minds a lot or just change their minds.

    9. JHJeremy Henrickson59:57

       Yeah. Willing to look at new information and say, "My mental model is adjusted by that." Or, "I was wrong." Very simply. I mean, I think it's also important to be operating in an environment where you're allowed to say that you're wrong, right? Everyone's wrong sometimes. I mean, be right a lot, but everyone's wrong sometimes, right? And, and being able to be in an environment where you can just like say, "Yep, I was wrong. Here's the way in which I was wrong. Let's move on." Is incredibly powerful.

22. 1:00:19 – 1:02:15

    Lessons from working with a founder who has strong opinions about what the product should be

    1. JHJeremy Henrickson1:00:19

    2. LRLenny Rachitsky1:00:19

       Final question. You've brought up Parker a number of times and something that is clear about him is that he's a very product minded founder.

    3. JHJeremy Henrickson1:00:26

       Yes.

    4. LRLenny Rachitsky1:00:26

       He has a lot of strong opinions about what products should be.

    5. JHJeremy Henrickson1:00:29

       Yeah.

    6. LRLenny Rachitsky1:00:29

       And as a product leader with a founder like that, uh, is often a challenging place to be, similar to being the first PM at a startup and the founder has strong opinions about product.

    7. JHJeremy Henrickson1:00:39

       Yeah.

    8. LRLenny Rachitsky1:00:39

       So my question is just what have you learned about being successful as a product leader with a founder that has very strong opinions about what their product should be?

    9. JHJeremy Henrickson1:00:47

       Yeah. No, that's a great, it's a great question. So I think you gotta be adaptable, right? Like, it's like any other relationship, right? You have to understand like what the nature of that relationship is, where that person's going to care, where you're going to care, the ways in which you can challenge each other. Um, like I think fundamentally, you need to make sure that person is willing to be challenged, (laughs) right? So, you know, I've seen product leaders or CEOs who are like kind of unwilling to be challenged. Um, and I wouldn't be able to work with those people. (laughs) Um, uh, but yeah, Parker is, uh, incredibly strongly opinionated, but he's also incredibly informed, which makes for some really, really great debates. And I've just found that like whatever, and it's not even a CEO, but whatever a manager's idiosyncrasies are, you have to find a way to like work with those. And I think that that adaptability, like I'm just sort of... I like being like, you know, a moldable puzzle piece where I can just kind of fit in. Um, I think that's actually one of my, one of my core skills. And so that's worked, that's worked out for me. And you know, Parker and I before I started, you know, started developing like a deep foundation of respect, which is like extremely important to like building that. And like over the years, it's just gotten deeper and deeper, and um, you know, we don't always agree but like when we don't, we can have a totally reasonable discussion about it. And um, and you know, that's what makes it fun.

    10. LRLenny Rachitsky1:02:06

        Adaptability actually is a... I took a StrengthsFinder test once-

    11. JHJeremy Henrickson1:02:10

        Yeah.

    12. LRLenny Rachitsky1:02:10

        ... of finding my own strengths and that was my number one strength is I'm adaptable.

    13. JHJeremy Henrickson1:02:13

        (laughs)

    14. LRLenny Rachitsky1:02:14

        I think we share that.

23. 1:02:15 – 1:08:31

    Lightning round

    1. LRLenny Rachitsky1:02:15

    2. JHJeremy Henrickson1:02:15

       That's excellent.

    3. LRLenny Rachitsky1:02:16

       Yeah. Seems like an important attribute for, uh, being in a place you're in. Well, with that, we've reached our very exciting lightning round.

    4. JHJeremy Henrickson1:02:22

       Ooh. Okay.

    5. LRLenny Rachitsky1:02:22

       I've got six questions for you if you're ready.

    6. JHJeremy Henrickson1:02:25

       All right. I'm, I'm ready. Hit me.

    7. LRLenny Rachitsky1:02:27

       Here we go. What are two or three books that you've recommended most to other people?

    8. JHJeremy Henrickson1:02:31

       Well, first is like my favorite series of books ever, which is the Baroque Cycle by Neal Stephenson. Uh, it's a nine volume epic or three, three volume, nine book epic depending how you want to look at it. But like, it's about the time like just before and like into the enlightenment historical fiction. A lot of fun. And then I also love, uh, The Culture Series by Iain Banks, um, which is just like super fun, far future sort of universe that I, that I really enjoyed.

    9. LRLenny Rachitsky1:02:59

       What's a favorite recent movie or TV show?

    10. JHJeremy Henrickson1:03:01

        Watched The Last of Us. Um, you know, was an avid fan of the game and uh, I thought they did a really, really nice adaptation. Um, favorite mo- like I guess recent movie, it's not that recent, but I really liked Tenet, which, which I thought was a, a... I'm, I'm, I was impressed with their ability to kind of go there and make that movie, and I just really enjoyed it like end to end.

    11. LRLenny Rachitsky1:03:22

        We had a... It kind of ended, but we had a drinking game anytime someone mentioned Last of Us, which, uh, took over White Lotus. I'm going to drink some tea right here.

    12. JHJeremy Henrickson1:03:30

        Okay, fair enough. I'll try... I've only got water. Normally, I got tea but I have water today.

    13. LRLenny Rachitsky1:03:33

        That works. Uh, but it's interesting, it hasn't come up often, so I think maybe we end that for now and see what new pattern emerges.

    14. JHJeremy Henrickson1:03:40

        (laughs) Yeah.

    15. LRLenny Rachitsky1:03:41

        And then Tenet feels like... I was just thinking, it feels like a Compound movie. Compound startup as a movie.

    16. JHJeremy Henrickson1:03:47

        Yeah.

    17. LRLenny Rachitsky1:03:47

        A movie is-

    18. JHJeremy Henrickson1:03:47

        Yeah.

    19. LRLenny Rachitsky1:03:47

        ... very complicated too. (inaudible)

    20. JHJeremy Henrickson1:03:49

        So I enjoyed it. I liked, I liked trying to like figure out like the multi-timeline chart in my head as the movie progressed. (laughs)

    21. LRLenny Rachitsky1:03:56

        The puzzle piece was in you, trying to find all the puzzle pieces.

    22. JHJeremy Henrickson1:03:59

        Yeah. Yeah, for sure.

    23. LRLenny Rachitsky1:04:00

        What is a favorite interview question you like to ask? You already maybe answered this, but anything else come to mind?

    24. JHJeremy Henrickson1:04:06

        I think I did. No, my favorite one is like what questions do you have for me by, by far.

    25. LRLenny Rachitsky1:04:09

        Great. What are some favorite products you've recently discovered that you love?

    26. JHJeremy Henrickson1:04:14

        I guess I'll just mention... I don't know if I can call these favorite products, but there's two that come to mind. My wife's computer, um, broke the other day and I realized it was the CPU cooler that went bad, and the Corsair H60 CPU cooler was like super easy to use and really adaptable to lots of motherboards. I thought that was great. My other favorite product is the one I'm wearing in my ears right now, which my first pair of nice headphones I ever bought died last week, late last week, um, and had to do like some really quick research into my new favorite pair of headphones and these Focal Bathys are like super nice. I'm a bit of an audiophile. I like to listen to like classical music and ambient stuff, so we need a lot of dynamic range in these and you know, noise cancellation, and these have been like great so far.

    27. LRLenny Rachitsky1:04:57

        Okay. So what is it, what are they called?

    28. JHJeremy Henrickson1:04:59

        Focal... I think it's Bathys, B-A-T-H-Y-S.

    29. LRLenny Rachitsky1:05:03

        Okay. And is there a specific model or there's like that one?

    30. JHJeremy Henrickson1:05:06

        That's it.

Episode duration: 1:08:31