Jeremy Henrickson: evaluation

Transcript context

…I think there's a lot of different answers here, and I think a lot of them are very specific to the nature of the business that someone's in, like different businesses can maintain velocity in different ways. I think there's kind of a universal truth that you want small teams with clear missions. Right? If there's 300 people trying to work on one thing, the just sheer 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 sufficiently small bits that small groups can attack wholeheartedly and minimize horizontal communication, I think 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 a clear platform, it reduces the decision-making complexity for everyone who's working on the domain part of the problem. And so a clear like a platform with a clear interface [inaudible 00:10:12] easy to use in all the ways that both engineers and product people want it to be easy to use, simplifies the space in which people have to think about these problems. And that's not always easy. Platforms are not, you can't just write a platform and hope it's going to 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, I think is really important. The third thing, just from a leadership point of view is diving deep. Right? It's very, very tempting to float up here as a leader and say, "Hey, you take that hill over there, you guys do this over here." When in fact where you really learn where the challenges are or the problems or the successes is by just being there with the people in the trenches on one of the things, 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 a lot by going through that detailed exercise. And I think the last thing is it's just making sure that teams have the right distribution of experience and seniority. Sometimes you get a team started and the team is perhaps doing something that's zero-to-one and they're amazing at all this zero-to-one stuff. And then two or three years later, those same people are trying to scale the product to 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 [inaudible 00:11:40] constantly look at the team and make sure that a people are doing things that they love and if they're not like, Hey, we've tried this other thing instead and recalibrate the team and make sure the right kind of skill sets are there. ake sure that a people are doing things that they love and if they're not like, Hey, we've tried this other thing instead and recalibrate the team and make sure the right kind of skill sets are there. And I found if you do all of those things and then have product leadership where we're saying this is what we need to do and very, very clear and precise on what needs to be done, then you can usually actually even 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. Okay, let me dig into a couple of these. These are really great.…

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