Will Larson: preference

Transcript context

…First, I start to question whether any function has a strategy at most companies. My general experience is that there's very rarely a written strategy for any company. Sometimes it's a value statement. It's like we build the highest quality products and you're like, "Good. Okay. What do I do with that?" You're like, "Build a high quality product." You're like, "Okay. I don't don't know what that means." Engineering often has this problem where I think people will make comments in their culture amp or their quarterly surveys or whatever. It's like, "Hey, the strategy is not clear or where's the engineering strategy?" And the biggest thing I tell people when they complain and then engineers complain about the product strategy. The PMs don't have any strategy or the business has no strategy. And the reality is product eng and business always have a strategy. It's just often not written down. And so the first thing I want to do is I push people not to get caught up on the fact that there's no template out there, which is product strategy that someone has forked and filled in. It doesn't mean you don't have a strategy. You do have a strategy. It's maybe a little bit hard to articulate and maybe it's applied inconsistently across different layers of the product reporting chain because it's not written down. But it's never true that there's no product strategy. There's always a product strategy. Sometimes it's bad, but there's always one. And true for engineering as well. There's always an engineering strategy. Just sometimes it's bad. The first rule of strategy is that if you write it down, then you can improve it. If it's not written down, it's hard to say if this PM is just not a good PM or if they're trying to apply the strategy that they've misunderstood or if they actually are correctly applying the strategy from the head of product that's just not appropriate to the problems they're working on, how do you debug any of that? If you have a written document, even if it's not a super compelling strategy, at least you can start debugging. It's like, "Hey, the head of product should improve the clarity of this document. Hey, this DM actually isn't applying it correctly. Hey, the strategy actually isn't appropriate for this one business unit where it makes sense for the others." So that's the first thing I think about. But the second big theme on strategy I think about is that often good strategy is so boring. It's hard to talk about. For example, on the engineering side of thing, a common strategy that's really good but very boring is we only use the tools we have today. So a lot of times you'll get engineers that want to introduce new programming languages, new databases, new cloud providers. And a really good strategy for almost all companies is like we just use the standard kit we already have today. And at Carta, when I joined one of the engineers, Eric Vogel wrote the standard kit and that is our strategy of the tools we use. And you know what? we just use the standard kit we already have today. And at Carta, when I joined one of the engineers, Eric Vogel wrote the standard kit and that is our strategy of the tools we use. And you know what? Some people are really frustrated by that and I feel for them. It feels like they're losing control, but the power of these boring strategies is that it focuses people's energy on the problems that we value as a company. And so it is painful coming into alignment if you're kind of slightly misaligned over time, but boring strategies that tell you what actually matters and aligns you with what the company actually caress about are really good for you even if they're a little bit annoying at a time. And I can expand on this idea a lot, but I won't ramble indefinitely on it. Well, maybe what might be helpful is what are some other examples of engineering strategies that you've seen just to give people even more just like, "Oh yeah, maybe this should be part of our strategy."…

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