SPEAKER

Jeremy Henrickson - VP Product & Engineering @ Rippling

Jeremy Henrickson is Rippling's VP of Product and Engineering, responsible for scaling a world-class engineering team across two continents. Previously as Chief Product Officer at Coinbase, he oversaw 5x growth of the product and engineering organization and transformed a scrappy startup into a global cryptocurrency platform with millions of users. He began his career at Apple in the 1990s and holds a BS and MS in Computer Science from Stanford. Jeremy enjoys playing board games and piano with his kids.

"When I have a number of teams and each of them has a product leader AND an engineering leader... the expectation that I set with them is like, "Look, you guys are gonna have different points of view, and that's okay! But when you come to me, you either need to 1) have a really clear, shared point of view on something because you've gone into this together and have thought it out. OR a clear point of disagreement, so that we can tie break on, 'Okay, which one of these is actually more important right now?'

And either one of those is totally fine. But a shared understanding of the facts, a shared understanding of the trade-offs is the floor that I draw on those conversations.”

- Jeremy Henrickson

Show Notes

• Jeremy’s experience scaling engineering and product at Coinbase (3:00)
• How to bridge the gap between engineering and product (5:26)
• How to think about hiring the right people for early and growth stages of a company (7:56)
• Finding both true believers AND skills for scaling + navigating hiring doubt through the “crypto-winter” (9:37)
• Common tension points while scaling engineering and product organizations (14:27)
• How much technical detail and context should be shared between product and engineering? (19:00)
• How to build trust and credibility when you’re leading a new team (21:11)
• Dunbar’s number and the different phases of scaling a product and engineering organization (25:43)
• Different ways to structure engineering and product organizations (29:20)
• When You Should Combine Engineering and Product Orgs & Jeremys different approaches with Rippling, Coinbase & Guidewire (35:16)
• What to do if you want to pursue a career in product AND eng leadership (40:13)
• How to get engineering & product aligned when they have misaligned expectations (43:02)
• Where to begin if you’re an engineering leader who just took over product manager responsibilities (45:21)
• Takeaways (46:29)

Transcript

Jeremy's experience scaling engineering and product at Coinbase

Jeremy, I just wanted to, to open up an official welcome to the Engineering Leadership podcast. We're excited to dive into our conversation. Thanks so much for being here with us.

Jeremy Henrickson: I'm really happy to be here. Thanks for having me.

Patrick Gallagher: So when we think about our conversation scaling an organization by itself is a really hard problem. And one of the tropes that are oftentimes comes up from our community is about the competing interests, the friction, the pain that can happen, oftentimes between product and engineering. And prospect of doing both... getting both engineering and product aligned and effective together. And scaling fast seems like an impossibly complex problem combined.

However you Jeremy have this unique cross section of experience, both scaling and integrating both product and engineering together first at Coinbase. And now you're applying those lessons at Rippling.

So really to begin, I was just wondering, what was the experience like scaling both engineering and product at a place like Coinbase?

Jeremy Henrickson: Yeah. I mean, well, first of all, Coinbase was such an exciting place to be able to try to do something like that. And you certainly don't do it alone. So, I mean, my first observation is... it wasn't me scaling it. It was a whole team of people, community of people coming together and just being willing to do whatever was necessary to make the business succeed.

I think, in my role at Coinbase, I was responsible for both Product and Engineering. One of the simplifying things about that is it made decision-making and consensus driving among like engineering and product leaders within the company much crisper than it would have had to have been otherwise.

And that was really important for reasons of speed because you know, the crypto of all places move just incredibly fast and what you believe you know, this month might be different than what you believe next month because the facts have changed. And so having a really short path from kind of those changes in the market to being able to kind of react to them, both in a product and engineering kind of side was really important. And so its kind of that fundamental premise where we said, "Look if I can retain kind of both of these functions for a while, we'll just be able to move faster.

But the reality is that. there's a limit to, I think, how any one person can do that. I was able to do it pretty well for a while because we had very product minded kind of engineering folks. We had very engineering minded product folks. But ultimately the engineering piece will overwhelm the product piece just out of sheer numbers. There's more people there's more details going on. And ultimately I had to scale myself out of that part of the role.

How to bridge the gap between engineering and product

Jerry Li: How do you cultivate the culture of helping Product folks to have a mind of Engineering and vice versa?

Jeremy Henrickson: I have a bit of a rule when I hire product people to start with. And that is that a part of my process tests for the product person's ability to understand engineering. Ideally, they've been an engineer at some point in their career history. But if not, the kind of ability to understand the nature of the trade offs that people make.

And I think if you don't start with that like raw capability, it's really difficult for product people to understand the nature of those engineering trade-offs. And the fact that, this kind of thing, accumulates technical debt and that kind of project though, not customer-facing actually will help customers in the long run.

The second thing is that I make sure that kind of on both sides of that equation, like, Engineering to Product and Product to Engineering that... you get people to understand each other's list of priorities, which of course starts with having list of priorities, right?

So not everyone has the discipline of saying "Yes! Here is like force ranked the set of things that I think we need to do to make the products succeed, or force rank the set of things I need... I think we need to do to scale Engineering..."

and taking both of those lists and pushing them together. Right. Saying, "No! No! There's actually a single set of priorities!"

And having everyone sit in a room and really understand each other's points of view.

And it's not about making people agree with the other person it's about having that shared context. And that shared ability to reason about priorities under a world where there's really limited resources.

And I've, I found that exercise whether you're doing it with individually contributing engineers all the way up to like CEO and like board members is a really effective way of getting people to kind of have that sort of empathy that's needed to make good decisions there.

Jerry Li: Does that mean to the extent possible you would prefer made a decision in the same room? Bringing together both product and engineering so that they can have shared context?

Jeremy Henrickson: Absolutely. So in the same room as much as possible. And in fact when I have like a number of teams and each of them has like a product leader and an engineering leader the expectation that I set with them is like, "Look, you guys are gonna have different points of view. And that's okay. But when you come to me, you either need to one have a really clear, shared point of view on something, because you've gone into this together and have thought it out, or a clear point of disagreement. So that You know, we can tie break on, okay, which one of these is actually more important right now?"

And either one of those is totally fine. But a shared understanding of the facts, a shared understanding of the trade-offs is sort of the floor that I draw on those conversations.

How to think about hiring the right people for early and growth stages of a company

Patrick Gallagher: I guess in the order of operations scaling probably also starts with people. Cause then people build the systems and the processes. So I wanted to dig in a little bit deeper into some of the people aspects.

So how do you think about... or how do you currently think about hiring the right people?

Who'll be both successful in the earliest phases of the company to then go through the scale up phase of the company. How do you think about hiring the right people?

Jeremy Henrickson: I think the reality is that most people, me included are better suited to some phases than others. There are very few people who are like, great as one of the first of three employees of the company and are also great as a 3000th employee of the company. Some are. But it's unusual.

I think to maximize the chances of success at that you have to find people who love complexity of problems, right? It's not that they love a particular phase. It's not that they love a particular domain. It's not even that they love necessarily particular part of the job. It is that they like solving whatever the hardest problem is right now. They have a mind that is pliable and one that, takes true enjoyment out of like solving those problems. And its kind of those people who tend to like not care what stage they're at and who are ability to introspect and transform themselves to suit the needs of the business as it scales

On the other hand, I think there are a lot of people that are just like really good at zero to one. Right? And they're awesome in that phase and they know they're awesome in that phase. And they also know they're not awesome outside of that phase. And that's okay too, right?

The life cycle of any company includes people that make it through parts of phases. And then they're like, you know what, for whatever reason, this is not right for me. And I think that's a quite natural part of scaling an org, recognizing that and being honest about it. And trying to find ways to make it work if you can. But if it's not going to work, that's okay.

Finding both true believers AND skills for scaling + navigating hiring doubt through the “crypto-winter”

Patrick Gallagher: One of the things you mentioned earlier was about what was special with the Coinbase experience was the community of people. And fundamental beliefs in sort of the philosophies of what crypto is doing for the world of finance...

and so I was wondering if you could, I guess expand a little bit about that experience because I'm thinking about people in our community who maybe are working on technology, that's either prehype or pre mass adoption.

We are trying to find the right people with the right skills. But also with sort of that right. fundamental belief in why that technology is important.

Like how do you find that intersection of people?

So I'm wondering if you talk a little bit about the experience of intersecting, fundamental belief in the technology and then the skills to help you scale the organization?

Jeremy Henrickson: Yeah. I mean at Coinbase this was a particularly interesting thing because either people were deeply believers when they came to you and they love the company because they knew it was trying to do something kind of deep in the space. Or they had no idea about what this crypto thing was. And like they had to acquire that sort of depth of belief. And like finding those people it was really hard. Right.

And there, there are stories from like before my time, when they would post these interesting like problems on, I think it was Reddit or something like that... Where it's like, just post it and like, see who responds. And like you get a self-selecting algorithm for people who are like interested in just spending their free time solving this sort of interesting problem that's relevant to the domain.

And at scale, that looks a little bit different. So for us, it was very early in the process. These kinds of like interview questions that we would ask them, the sorts of problems we had asked them to solve were all like crypto related. Right. And so you would immediately get a sense of one, whether they enjoyed that. But two, whether they could grok it. Because it's actually pretty hard to grok, especially back in like 2016 or earlier. When people didn't really know what this thing was.

Now, I think the challenge is that like the intersection of people who are like really super into crypto back then with a set of people who were like really good at scaling companies was relatively small. Right. And so the trick was to kind of evaluate both like that, like belief in the mission, interest in crypto native ability to grock and understand it with the... No! They understand what it means to like build software that's like 100% secure every single time. Or that's not going to fall over as like the volumes, like double and triple and 10 X and a hundred X. Right.

And finding that was, you just got to test for both skills as you along. And you know, we found a right few people who found right more people and ultimately it worked out. But was hard at first cause no one, especially 2016. 2016 was the end of a very long, crypto winter before the craziness of 2017. And finding people in that period was... and persuading them to like bet their careers on this crypto thing was tough.

Jerry Li: I remember my first exposure to Coinbase is back in 2016. it's in Money 2020 in Vegas. There's a, the annual conference for people in FinTech.

Jeremy Henrickson: You came at an interesting time because it was really... internally the company, there was a lot of when I joined, there was a lot of frustration. Not necessarily at the company, but it was just been a long time. And people had been like working really hard to make this thing work and the company was doing okay, but not great.

And so thank you for bumping into us that year it helped us along.

Patrick Gallagher: They're engineering manager like different different groups and events that we've held in the past. One of the biggest problems that always comes up is "We're a small company. We don't know how to stand out or source or get people to identify us or understand our brand..." and the practice you shared about sharing interesting problems related to the technology that you're working on on Reddit... To me is mind blowing. Like that seems like such a fascinating way to attract people and like also to identify you know, prospective talent on your technology.

The other question I had related to this was, you know, you're talking about the, the big winter in cryptocurrency. How'd you work through doubt with the candidates that you worked with?

Jeremy Henrickson: And so I was, I was somewhat lucky in that I came in sort of at the near the end of the crypto winter. But that meant there was sort of maximum doubt as well. And the reality was I just, I had to tell the story of how I came to believe in it and acknowledge the possibility that, "Hey, look, maybe it never works. I'm pretty sure it will having gotten conviction around it. And I'm betting my kids college on it. Right. And, And I think it's gonna work out. But you had to find people who are willing to to really understand what it was and B have the faith to jump. Right.

And I think that was okay. Like as hard as it was to find people, what it meant was that the people who joined were incredibly high conviction, Right? Which helped bolster everyone else's doubt.

So they, some other people of doubting, like, wait, I know this person here who seems like super smart and super credible, like just joined my team. And that gives you like a little boost. Which is all you need like a little boost to kind of carry you through the next few months. Until things start picking up.

Patrick Gallagher: The virtuous cycle of overcoming doubt that's beautiful.

Jeremy Henrickson: Yeah. Yeah.

Common tension points while scaling engineering and product organizations

Patrick Gallagher: So now here we are, you're bringing together people, the right people with the right belief and then the skills to help with scaling. So looking forward when you have these people together, serving in both engineering and product functions, helping build out the infrastructure and the product...

What are some of the common tension points while scaling that you typically see between product and engineering or what can you do to anticipate those and solve those problems as they come up?

Jeremy Henrickson: Yeah, there are a lot of tensions, but I think the classic one of course is like features or speed of delivery versus like long-term technical orientations slash sanctity.

And I think very early in a company's history, there's like a lot of, there's a lot of truth to that, right? Where it's like, you got to move fast just to kind of prove out the product and established product market fit.

But once you've established a certain degree of product market fit, I often find that this question of speed versus kind of quality or, or long-term orientations, like just mostly a false trade-off.

And so I think that tension which can exist the way I like to try to resolve it is to, is actually coming back to the other thing I said around like prioritization... that fundamentally, it can't possibly be the case that these things are actually in tension. That one of them is going to be important just to to ensuring the survivability of the company. And another, one's going to be important to serving the survivability of the business. Right? This is one of the same.

And so the way I like to try to work through those tensions is by like talking it through and understanding what the real import of those things are. And I think people are... particularly those who are like on the ground doing the actual engineering work, right? One of the things I always have to try to remind myself as like the world that they see their context is, is in this thing right now, that is, that that they're trying to solve. Their context is not in the "Three years from now here are all of these other problems that you're going to solve."

And similarly, like a product person who's like, "Well, here are all of the things that we're going to need to do to win in the market here are these features."

They don't see like the detail, like "This is the thing that a new engineer's rustling with and it's like really hard to understand the code and the onboard, because there was like this old system built like three years ago that doesn't really work anymore. And if only we rewrote it, we'd like to be 50% more efficient..."

And so like bringing those two things together in the same room at the same time on a regular cadence rather than in a reactionary mode to things that are just happening. I think is the way that often helps resolve some of those tensions.

Patrick Gallagher: How do you set up that conversation? Like, is there a specific framework that you found or agenda to help both sides bridge the context gap and share different perspectives and priorities and sort of cross examine those things?

Jeremy Henrickson: Yeah, the way I like to do this, ultimately... and this is incredibly iterative it never starts here, but is to have a periodic quarterly or, or whatever, more frequently, depending on how fast, like externalities move. But. Quarterly, monthly, whatever, essentially review process where you do the three month forward planning.

In crypto in particular, by the way, planning more than three months forward wasn't really possible.

Uh, But same thing. same thing, by the way, is true at Rippling. It's just like, there's so much going on that you can get a good three, maybe six month view. But like getting a view out further than that is generally unrealistic. But having a cadence where people know that "Yes at the beginning of the quarter or the beginning of the month or whatever, we're all going to come in we're going to do this difficult, but hopefully not too time consuming exercise. So like re rationalize all the kind of things that we know about now, relative to the things that we knew three months ago."

And once you've established that as a pattern, and once people recognize the value in it... It was some time, but it actually made their lives easier. It made Engineering smoother because there were fewer asks from products in the middle of two weeks after the planning or whatever.

And so they can operate more efficiently. They can actually get projects across the line. The debates have already been had. That really gives people confidence, I think, to be able to kind of come in and do that on a repeated basis.

And then there's a secondary benefit, which is that having done it once or twice before, there's now a bunch of shared context among the people that were having that debate. And so the next time you come back a few months later, you're starting from a higher point of kind of consciousness and understanding of these topics.

And that's, institutionally self-reinforcing as you scale. And it creates some resilience as Leaders change, right? It's not like the engineering manager of that team is going to be the same one forever. I mean, it's unusual for that to be the case.

So someday, you know, that person's probably going to change. And the fact that there's been this process that has helped institutionalize the rationale and the memory and the context for all of these things, goes, it goes really long way.

It doesn't supplant by the way, the need to have like daily communication PM sitting right next to Engineers. I think that's actually even more important. But it's certainly a rhythm that helps the business.

How much technical context should be shared between product and engineering?

Jerry Li: I have a follow up question on that. Granted having shared context between engineering andproduct is going to be really helpful for getting the team aligned and making decisions. But I believe to a certain extent, there needs to be aligned, in terms of how much more detail we need to share, there could be diminishing return... so how do you draw that line in those conversations?

Jeremy Henrickson: Great question. So obviously too much detail is both overwhelming and not very productive, right. You just rat hole on like on the details. And so I think there's two different ways. I think about this.

The first is that you have to describe things in terms of not the details, but in terms of what you're trying to accomplish and what the problem is. So it's not you know, "Here's the technical solution to this thing."

It is, "Here's the nature of the problem and why this is bad. Slowing us down, it's causing bugs customers don't like it, whatever. And here is a description of what we get after we do this thing. Like here's the solution and the actual benefits of having spent this time."

The details don't matter. Like you have to trust your engineering leaders that "Yes, the details of how we're going to implement this are going to yield that benefit."

If you can't trust the engineering leaders to do that, then you have the wrong engineering leaders in place. Right? So that, that's the first way to think of it.

The second way to think of it is that there's actually a set of things, which this process doesn't work at all. And that is for the things that are like truly like revolutionary, either on the innovation front. Where it's like, somebody has the insight to do something like totally new. That's not going to come out in like a quarterly planning process, not usually. And sometimes they do, but it's unusual.

Or like the deep technical change, right? Like we have this foundational problem with whatever architectural thing. And some really smart engineer over there it's going to be like "You know, what, if we only did this... It would have this longterm benefit."

Right. And that's again, not going to emerge from like some standard, like product planning, or even some standard engineering or architecture, community planning process.

That's going to emerge from a Human having the insight. And so you have to have like a capacity in the organization to like allow for those innovations or those kinds of creative solutions to come out. Otherwise you turn into a big company, right? Where innovation cycles and things start moving slow and all the rest of that.

And so I think drawing that balance and recognizing the limits of that other process are incredibly important.

How to build trust and credibility when you're leading a new team

Jerry Li: A lot of people reported obtaining the trust between engineering and product. Is really hard. How do you establish those kind of a trust

Jeremy Henrickson: I don't think there's a shortcut to building trust. Trust is incredibly difficult to earn, even if there's good faith on the way in the door. Like, yes, I believe this person might be trustworthy. Like actual trust where people in their gut feel it is really hard to earn.

And so my advice always to new people who come in, regardless of what role they come in to is in the first week or two with it must be two... Get your hands really dirty on something. Go in, dive deep, figure something out. Ask the questions you need ask. Right. And meet people and show that you're kind of willing to do whatever it takes to get something done.

Because that more than anything else makes people think, "Okay. Yeah. This person's credible." Particularly as you scale, right? So once you have an engineering organization of 150 or 200 or 300 people.

Like the fear I get all the time is, Oh man, we're bringing in like a new engineering manager. That person would be no good."

I tell the engineering managers, like... "You will write code your first week. You're going to go in, you're going to solve bugs. You're going to have some insight that the team hasn't had." That is incredibly important because even you started that way. And like people by default trust or you start the other way and people by default don't trust at which point now, even if they're the right person for the role... you have, like months and months and months of work to do to re-establish that trust.

And so I'm a very deep believer in people being incredibly hands-on and that being like the seed. And I think that's the only thing that has to happen, but that's certainly the seed that engenders, the rest of the trust as people go along.

Jerry Li: I can definitely confirm. In my earlier company when One point we , we had a new VP of Engineering come in. And it's very effective for the person to earn the trust from the team because the way he introduced himself without going through road real maps or other high-level stuff. Immediate jumping into a ongoing production issue and work with the team and brainstorm just like a team member. That worked incredibly well for establishing the trust, on day one.

Jeremy Henrickson: I totally agree with that. I had a new product leadstart this week and she you know, should she came on board and didn't really know anything about the product or the team and not, and definitely said, "Okay here's how you build credibility with this team; go off, there's some of these support issues right over there. It's not glamorous it's not fun. But it will earn you a tremendous amount of credibility because people will will understand that you actually want to understand what's causing these challenges for the engineering team."

Right? It's like, "Wait a minute. There are these issues coming through..."

And if you can simply solve that root cause. Right. You will immediately be friends with these folks. And I think that sort of thing is just so powerful. Especially when scaling and especially when you pass the Dunbar number and like people don't know each other anymore and default to lack of trust instead of trust.

Dunbar's number and the different phases of scaling a product and engineering organization

Patrick Gallagher: I'm so glad you mentioned the Dunbar number. That's one of my favorite concepts of all time and structuring teams and communities. For those tuning in, who are unfamiliar with the Dunbar number, it's sort of the limitations of the amount of intimate relationships that you can form.

And Dunbar's number is about 150, meaning that it's really hard for humans to have more than 150 intimate relationships. And there are certain sort of layers of intimacy that go down to like your closest people, which is about five or six or so I believe.

So Jeremy, love that you've referenced Dunbar's number. That's what my favorite concept of all time.

Jeremy Henrickson: Well, I, I love that number because it's, in my personal experience has been so true. I mean, I've been lucky enough to be now at three companies that have scaled from like relatively small to, well, beyond that number.

And like, there are things that happen when you cross like six people. There are things that happen when you cross 12, 13, 14 people and so on and so forth.

And 150 one of those numbers where it's just like the dynamics of the organization right around there somewhere, just necessarily change. And it's a very human thing, which is great because it means you can take lessons from one company. And absolutely apply them to the next, because it turns out human beings are human beings doesn't matter. It doesn't matter where they're from. It doesn't matter what their context is. Like, there, there are fundamental things that are more or less, always true, maybe with slight variation.

I think that's why it's possible for people to kind of bring that experience from one place to another and, and have it meaningfully impact the trajectory of a new business.

Patrick Gallagher: Speaking of, of some of the structures. I was wondering if we could talk a little bit about some of the sort of stages of evolution of a product and engineering or through that scaling process. You know, You mentioned the changes in companies that happen at six 12 and 150 being one of those numbers...

How does product and engineering organizations sort of evolve structurally through scaling or what are some of the different structures or phases that you identified in that scaling process?

Jeremy Henrickson: Yeah. So I think the specific structure or any, any business, at least in my experience, varies based on the nature of the business a little bit. So you know, way back at Guidewire, back in the, in the aughts right.

When I joined the company, we had essentially one product, it was a. claims product and in property and casualty insurance carriers like have three main aspects of their business, like claims billing and policy administration.

We had one. And so the nature of how you build that, that one is quite different. Then we started when we built the second one and the third one, and that changed like the structure. And so it was really those milestones we said, went from one to two or two to three, and I made the big difference.

Um, at Rippling, it's pretty different because we are a multi-product company from the very, very first day. And like, obviously I wasn't here in those very early days, but our structure is that we have like, eight different teams, each of which is very small and incredibly entrepreneurial. And then you thought a platform team and you thought like an infrastructure team and then some ancillary stuff.

And the kind of curves you go through there are different. Where it's similar is in each of those teams. Right, so when a team crosses 20, then like a certain set of things might happen. Like suddenly you now need two engineering leaders, like one engineer manager can't handle everybody anymore. Or at least one engineering leader can't handle everything anymore. And so you end up with that split and that creates like cross team communication issues.

Whereas at Rippling exact kind of counter example of that, like only one of our teams, has like 20 engineers on it. Right. And so only one of those teams has kind of had the split to that. Even though, as a whole, the company has 160 or 170 engineers now.

And so it's largely about the, kind of the fundamental units of the business and like what is that because that's going to drive when you see those scaling factors in each of the teams.

Different ways to structure engineerings and product organizations

Patrick Gallagher: When you were assessing past decisions around how you would want to set up the different organization structures at Rippling or at Coinbase or otherwise... were there certain trade-offs or benefits that you were considering around your decisions? And why did you make certain choices about how you set up your organization structure?

Jeremy Henrickson: Yeah, for sure. So I think that there were some common themes that emerged, or I guess is what I'd say...

The first one is, I like to keep organizations as flat as I can, as long as I can. So I usually end up in a situation where there's like 20 people reporting directly to me.

And I do that because minimizes The context differential, right. which allows people to make better decisions. And then also like just appealing to people cause they're like closer to the top. But eventually that breaks down!

And so the decision that I think about a lot is... When do you introduce like some sort of layering, like what's the last possible moment. And when you do like, what is the nature of that?

So at Rippling, for example, ever still more or less than the structure where everyone reports like basically straight to me and the challenge with that is of course there's too many people reporting to me, but the other challenge is... what is the internal structure that we have, where we could draw some line?

And turns out at Rippling, there's this kind of convenience set of things, where we have products that are focused on HR products that are focused on finance and products that focus on IT. And so there's this sort of inevitable evolution that at some point I need to bring on kind of those people. Right?Or promote people into those roles.

And that decision is a hard one and I don't, I've never found a clear rubric by which to answer that question. I agonize over it, like at every company I'm at. Like, cause as you're scaling... those decisions, fundamentally alter like the way in which the business needs to operate.

And so, I think what I've always come back to is that whenever you do like promote somebody into that role or bring in somebody from the outside as it experience, you have to be really, really thoughtful about that leader.

And the bar is like super high. Which seems obvious. Except that under the pressure of time and too many people reporting to you and all the rest, it's really, really easy to say yes to somebody who's pretty good. Right. And so like for solving that instinct and really holding the line, even if it takes you a year is incredibly important.

Jerry Li: What's the risky part of making that decision. , is it reversible if we police the wrong people , with wrong things can happen?

Jeremy Henrickson: So it is reversible. It's just painful to reverse. And if you're going to reverse it, you have to reverse it quickly. Like in 30 days or less, right. You have to recognize that you made a mistake and I've definitely made mistakes before.

And you unwind and as quickly as you can, you acknowledge to everybody. "Yep. Yep. I screwed up!"

You have to own that decision because it was yours to own stone. And then you move on and you try again, you get everyone in room and say, "Hey, what did we learn from this? Okay. Here's the ways in which we're going to make this better next time."

But if you let it linger which I'm also guilty of having done in my past. You end up with some pretty permanent scars, right? Trust in executive leadership drops. Cause like, "Wow, you let that person hanging out way too long."

Trust in like... you get the, you start getting the, "Oh man, we're coming to big company." Right. Because that person all they cared about was processed and not the product or whatever. Right. Like those kinds of mistakes.

And I think that's really hard to unwind because it's like it's trust right long time to earn. Really quick to go. And so I think that's really the cost. The most important cost is the reduction in trust.

Sometimes you end up with a few other costs, I think around like they change something about how things work. Those things tend to be pretty easily reversible. Though those are, I found those to be relatively, even if it's painful. And even if people are frustrated with it for a few months, like ultimately it's on the long-term scale of the company, it's a little blip. But yeah, it can be a big deal.

Jerry Li: And what are some signals help you make a decision. "Well, this is the right time! It's about time to introduce another layer."

Jeremy Henrickson: I think there, there are bunch of different signals. The first is a very personal one, which is just like, "I don't have the time. Right. I do not feel like I am serving my team well. For whatever reason, like one-on-ones aren't as productive as they should be, I'm not giving people enough feedback. I don't have enough time to like really run all hands at the frequency that I want."

Like, things like that. Like first obvious signals that something is not quite right.

The second signal is more like the anticipatory signal, like where I can see in the future, like "Here's where we need to be six months from now. We're not there now. And I don't have anybody including myself who can make us get there. Right. Either me, cause I don't have time or because there's no one with the appropriate skillset..."

And I haven't been lucky enough to see this movie a few times now I have that pattern recognition. So I can see around that corner and say, "Yep, that's going to be a problem. It's going to take me six months to hire somebody anyway, I better get started now." Right. And I think that pattern recognition helps.

Without having that pattern recognition I think the thing that helped me was really listening to the engineers on the ground. Specifically, the engineers here, I'm talking about now, even in what I've had like roles with product, because you'll start hearing, at least I've started hearing like little things like " Tests are just taking too long."

Or " it took me longer to do this thing because I couldn't find time to meet with that person."

Or " I'm frustrated because I'm not able to get this done as fast as I want."

Like, those are all signals of maybe a very specific issue, but they're really signals of a lack of leadership somewhere, right.

Where there hasn't been somebody who has been fundamentally responsible for drilling all the way to ground and making sure that stuff doesn't happen. so I think even without the pattern recognition, that's I think the most important signal I've heard.

Jerry Li: And that's a really good point. And also the signal coming back from the engineers are sort of a delayed. So it's already happened a while before they started complaining.

Jeremy Henrickson: That's totally right. That is completely right. The other thing I think it does though, is listening to that signal also gives you an opportunity to like, just talk with people, right. About things and to build trust again. It's like, I don't have time with the individually contributing engineers every day.

So every time I have even like five minutes with one of them, like I made sure I'm like asking that question, like "What's hard right now? What's easy? What's going well?"

Because I find that signal is much more powerful than any signal I get filtered through a set of managers.

Patrick Gallagher: That is a really concise and powerful question to ask... "What's hard right now?"

And it's just gets to the root.

When you should combine engineering and product orgs & Jeremy's different approaches at Rippling, Coinbase & Guidewire

So as we're talking about introducing different layers and we've been talking about you know, simultaneously scaling Product and Engineering right now at the same time.

When does it make sense to create individual ownership between engineering and product organizations? Or when should you have them both under one organization? What are the dynamics there?

Jeremy Henrickson: I can only speak from my personal experience. And I actually think the answer to this question is probably quite idiosyncratic to the company. Right.

But in my own experience, there almost always comes a time when I realized that my personal value to the company would be greater if I were doing something other than I was. Right. Or that I can find somebody that's better at than me at the parts of the job that I'm not doing.

And so like, at Coinbase you know, this hit uin like 20, I guess, what was it? 20, early, 2018. Or maybe late 2017 or 2018. I was like, "Look you know, I'm holding the thing together. But the reality is if I were able to focus full-time on product and strategic things, and somebody else was able to come in full time and like, do the engineering and the rest of the engineering scaling bit, the company would be better off."

Partly just because it would have two minds instead of one contributing sort of at that level. But also partly because there are people that are better than me at that.

So for me, it's about having the insight that the benefits of having both things combined are now being outweighed by the fact that the org is scaling in some way.

And a specific structure for how you solve that problem maybe there's a lot of ways to do that. It's like, "Okay, I could hire an engineering leader that's reporting in to me. I could hire an engineering leader that's reporting into the CEO. We could divide up the organization into like these three pillars so it makes me more efficient."

So I think there's not only one, one answer, but like oftentimes the right answer is "Let's split out Engineering and make it its own like really dedicated function."

And like that person then becomes like the most important partner to me in the company.

Patrick Gallagher: Do you have any questions to help create that awareness? Because I think what stands out to me about that is, is sort of the humility to quote unquote, "give up power" in that situation. So like, are there questions that you're asking yourself prompt that reflection or things that you're paying attention to that help you know when that's the right time?

Jeremy Henrickson: Gosh. I mean, that's a great question. I don't claim to have any special insight here. I think I dunno, maybe I can thank my Mom. Like my mom drilled humility into me and like I've never cared about power actually. And so that helps.

I'm an introvert. I'm quite accidentally somebody who runs large organizations. And so I think all of that, at least for me personally, just adds up to I think about it. And I try to be honest with myself and not perfect by any means, but I do my best.

I mean, I think. I think the signals that anyone would listen to are just like burnout and getting overwhelmed with things and like acknowledging to oneself that's what it is. It's like, "No, you actually, I can't handle all of this on my own. So something is wrong. Something maybe it's just, I need to hire another person. Maybe it's I need to give up the power of running engineering..."

Like I think being willing to acknowledge that overwhelmness as what it is. Right. and to kind of consider the solutions to that problem is the important step that I kind of go through.

By the way I think there's a side point here that's really subtle, which is, I think it's actually really important for there to be things that are being dropped and that you're being overwhelmed by.

Right? Like, cause we were actually getting to even close to everything it means you're not optimizing correctly. And so I think there's a piece that's like you have to, be able to distinguish between like being willing to go through the pain of like knowing you're not getting everything done that you should get done versus having crossed that threshold where that's actually a problem for the company.

Right. And I

Patrick Gallagher: That seems like a gray area.

Jeremy Henrickson: It's a bit of a gray area. and it's like the kind of thing where I definitely didn't get it right at Guidewire. I did a little better at Coinbase and like this time around, I feel like I finally know exactly where it is. It's a hugely personal thing, right. About where my own head of personal tolerance are, what I enjoy or don't enjoy and

Patrick Gallagher: So speaking of you know, the different iterations between Guidewire Coinbase and now at Rippling, what are some of the things that you're doing differently to scale product and engineering at Rippling that's either the same or different from your previous experiences?

Jeremy Henrickson: Yeah, Rippling, the thing that's really different about this that I'm really having fun with is that it's incredibly entrepreneurial. Like Coinbase was incredibly innovative, right? And it was obviously entrepreneurial nature.

But at Rippling, we have eight products in market. We're building new ones all the time that I can't talk about. Right. And so each team is like really small.

And by the way, each of these teams is like doing battle against multi-billion dollar incumbents, right. It's like Payroll and like Core HR Systems and time that tends to these are all like wellness industries and words tackling them all simultaneously.

So the kinds of people that you need to do that are different than the kinds of people you would need to like have a single product with like 400 people. It It's just a different modality.

And that's a lot of fun. So I'm having a lot of fun figuring that out. Cause it's, it's new for me. It's like similar. But in specific it's, it's quite different. And so it's been a lot of fun to figure out what the right modes are there.

And by the way, it's evolving. Really rapidly as well. Because we're moving from a place, we had five products to eight to so on and so forth. And so the way in which we have to make that work repeatedly and well changes over time.

What to do if you want to pursue a career in product AND engineering leadership

Jerry Li: A lot of engineering leaders we talked to in the past they are either very curious or have the strong need to learn more about product. To be more effective. To be closer to the customer, to the business. And you have been doing that across multiple organizations already.

What's your recommendation for people to go and acquire proactively, about product, probably business as well. Do you think people should pursue a career transition from like engineering to leading both engineering and product in a a more intentional way?

Jeremy Henrickson: So I think if that's somebody's aspiration if they're like, "you know what, it'd be really interesting to lead both."

The first thing always is make sure you love customers, right. Go spend time with them. And truly understand like the nature of the decisions they're making, what they like and don't like.

Because if you can't get to a place where you empathize really strongly with customers and understand their pain, You can't really do the product function well. On the other hand, if you can, and you have the engineering background, then you're in a really exceptional position because not only do you understand like the engineering trade-offs that need to be made, but you will also understand the product ones because you can reflect the aspiration desires and the needs and the pains of the customer.

So I think that's, the most important thing. So if you're an engineer, Or an engineering manager or whatever, Go talk to your customers, whether they are like, whether you're a consumer product and you want to just go talk to people that are using your app or whatever. Or an enterprise product you know, walk into a big, like 50,000 person company and talk with the head of whatever, like take those opportunities.

And then the second thing I would suggest is Sit down and just chat, most product, people are pretty friendly. Like sit down with them and, ask to sit with them while they're going through whatever process they go through to like make decisions or to build a mental model on something, or you know, beyond just the building and iteration on the feature, which hopefully most engineers will have exposure to.

But the side of things that are like hidden, like behind the walls. Like, "How did you even come up with that list of stuff that maybe we could do? How come you did or did not exclude that thing? Why did you come up with this prioritization scheme? Why did you decide that this one is more important than that?"

And I think like, just sitting and like doing that gets you 50% of the way there. And then one day you wake up and somebody in your org says, "You know what, I really need somebody to go do this. And suddenly you're the most credible person to do it. It's just like the bus happens to drive by one day. You happened to have been like spending time doing something you love and suddenly you look like the person that's a match for a bus and you get on

And like that's probably the best advice I was ever given. It's like "When the bus comes, like, just get on it. It doesn't really matter if it's exactly right or whatever. It's like get on the bus because the bus will take you to these amazing places."

And I've been incredibly lucky, but I haven't gotten that advice 20 years ago, I wouldn't have gotten on the first bus. And like none of the rest of it would have happened. And so I just think that's so important.

Jerry Li: Incredible!

Patrick Gallagher: A couple of quick questions, Jeremy, before we wrap up our time together here.

How to get engineering and product aligned when they have misaligned expectations

We facilitate a couple of different peer groups of engineering leaders at various levels. And the last few conversations that I've been a part of have come up with a lot of challenges related to product.

One of the ones that come up is around misaligned expectations between product and engineering. And the engineering leader is sort of in a place where we're trying to broker relationships between the two.

So what advice would you have or how do you ensure both engineering and product are aligned and in sync in terms of decisions and prioritization?

Jeremy Henrickson: Yeah. So I think to be aligned and in sync, again, I'll come back to the having a consistent periodic planning process. Right? If you don't have that, then you don't have alignment. Right. Unless everyone's gotten in a room together and agreed on a list, like essentially a forced rank list of stuff. Like you don't actually have alignment. And so having that goes a long way.

I think there's a related question, which is if you aren't aligned, how do you get aligned? Right. And I think that starts with an acknowledgement that you're misaligned.

Oftentimes these conversations have started with like entrenched beliefs, like Engineering person's like dug in...And they're "I can't believe product. Isn't like doing this thing because they're..."

Whatever. Right? On the money it's on the product person's like, "God, that recalcitrant engineer just is refusing to, like, I think about the customer and building features, like, what do you do?"

And like if those two people or those groups of people can't come together on their own, you got to just force them into a room and say, "Okay, like, here's what I'm hearing on both sides of this. Here's a list of stuff we actually need to accomplish. Maybe it's impossible for us to get that done because actually we're being asked to do too much. And if that's the problem, let's get to that being the issue. Not like these entrenched positions."

And you just have to get to, like, you have to get to the root truth to get out of that vicious cycle.

It's painful. I've come home just like furious, right about these conversations. But ultimately they do pay off eventually. Or they don't and the company collapses, but those are the, those are the two options.

Patrick Gallagher: You mentioned you know, sometimes the product opportunity, like the bus comes and you can get on the bus and you have that opportunity.

So one of the engineering leaders in one of our peer groups, Basically a PM left and he sort of had to subsume their responsibilities or assume their responsibilities. And the big question was like, "I don't even know where to begin. I don't even really know what they've done..."

What should you look out for? Or if somebody is starting from zero and they're in engineering leader and they are now taking over some of the responsibilities of the PM that was helping out.

If they're starting from zero, what's your quick tips, where should they start?

Where to begin if you're an engineering leader who just took on product management responsibilities

Jeremy Henrickson: The first quick tip is if you can get ahold of that PM and ask them, "What did they care about and why?"

That context is gold, like it might be wrong. Maybe the PM wasn't any good or whatever. But at least you like understand where they were coming from. And then after that, I would say the most important thing is to go to talk with everyone individually, right. And say, "Okay You know, this person is now gone. What are the challenges we really have? Like, What do we need to focus on? And what are we doing that we shouldn't be doing? Right. What do we need most importantly, like, what do we need to get rid of that we're spending time on?"

And go have it with everyone individually. Not in a room because you do it in a room, there's going to be a group thinking and the rest, you got to do it individually. And then bring everyone together. And we'll say, "Okay, folks, this is what I've heard. Am I representing you correctly?"

And that both does the trust building piece, which is extremely important if you're going to kind of be thrust into that role. And hopefully it gives you a good sense of , at least a first cut, like "What's important. And where does the time need to go?"

Patrick Gallagher: Jeremy. Thank you so much for an incredible conversation together. This was a blast.

Jeremy Henrickson: Yeah, this was really fun. Thank you for having me. I hope we'll have the chance to do it again sometime.