The engineering mindset | Will Larson (Carta, Stripe, Uber, Calm, Digg)

1. 0:00 – 4:12

   Will’s background

   1. WLWill Larson0:00

      I think that we often treat engineers a little bit like children instead of giving them, like, the responsibilities and ability to actually thrive as adults. And so we're like, "Oh, the engineers won't want to do that work." You're like, well, that's actually not good for the engineers to kind of be sheltered from what is important. And so I, I actually, like, one of the, I think highlights is that I think we're coming back to this moment where we can actually treat engineers like our peers and put them into really senior leadership roles and not have this kind of baseline assumption that they'll go, we have to coddle them or hide them from the real problems and this is how they're gonna get the opportunity to grow as well.

   2. LRLenny Rachitsky0:34

      (instrumental music) Today my guest is Will Larson, one of the most requested guests I've had on this podcast. Will is currently CTO at Carta. He's been a software engineering leader at Stripe, Uber, and Calm. He's the author of two essential books for all engineers, An Elegant Puzzle and Staff Engineer. And he's releasing his newest book, The Engineering Executives Primer in February of next year. He also publishes regularly on his blog at lethane.com which is a must read for every engineer and eng leader. In our conversation, Will shares advice on developing your engineering strategy and strategy in general, how to improve the relationship between an eng manager and a PM, how he finds time to write while also working an intense full-time job, how he recommends approaching measuring engineering productivity, how to develop your company values, an amazing story about his time at Digg, and so much more. Will is such a gem of a human and leader and I'm excited to bring you this episode. With that, I bring you Will Larson after a short word from our sponsor. Today's episode is brought to you by DX, a platform for measuring and improving developer productivity. DX is designed by the researchers behind frameworks such as DORA, SPACE, and DevEx. If you've tried measuring developer productivity, you know that there are a lot of basic metrics out there and a lot of ways to do this wrong, and getting that full view of productivity is still really hard. DX tackles this problem by combining qualitative and quantitative insights, giving you full clarity into how your developers are doing. DX is used by both startups and Fortune 500 companies, including companies like Twilio, Amplitude, eBay, Brex, Toast, Pfizer, and Procter & Gamble. To learn more about DX and get a demo of their product, visit their website at getdx.com/lenny. That's getdx.com/lenny. Today's episode is brought to you by OneSchema, the embeddable CSV importer for SaaS. Customers always seem to want to give you their data in the messiest possible CSV file and building a spreadsheet importer becomes a never-ending sink for your engineering and support resources. You keep adding features to your spreadsheet importer, but customers keep running into issues. Six months later, you're fixing yet another date conversion edge case bug. Most tools aren't built for handling messy data, but OneSchema is. Companies like Scale AI and Pave are using OneSchema to make it fast and easy to launch delightful spreadsheet import experiences, from embeddable CSV import to importing CSVs from an SFTP folder on a recurring basis. Spreadsheet import is such an awful experience in so many products. Customers get frustrated by useless messages like error on line 53 and never end up getting started with your product. OneSchema intelligently corrects messy data so that your customers don't have to spend hours in Excel just to get started with your product. For listeners of this podcast, OneSchema's offering a $1,000 discount. Learn more at oneschema.co/lenny. Will, thank you so much for being here and welcome to the podcast.

   3. WLWill Larson3:40

      Thank you so much. Super, super excited to be here.

   4. LRLenny Rachitsky3:42

      So many people have suggested that I bring you on this podcast. You have a lot of fans out there and I am excited to be digging into engineering topics which we don't do enough of on this podcast. So thank you for making time for this.

   5. WLWill Larson3:54

      No, thanks. I, I'm ho- hope to, uh, be a good early engineering guest before we pivot entirely to engineering at some point, uh, in the future.

   6. LRLenny Rachitsky4:03

      (laughs) Wow. I love that. How cool would that be? I was an engineer actually when I started my career. How interesting would that be if we come full circle. Anyway,

2. 4:12 – 6:27

   Changes in the field of engineering

   1. LRLenny Rachitsky4:12

      I thought it'd be fun to start with just what is changing in engineering. It feels like there's been a lot that has changed over the past few years, especially from kind of the ZIRP, zero interest rate era to today's market, which is very different. What have you seen most change from an engineer's perspective and then just also what are you telling eng leaders about how to handle all this change?

   2. WLWill Larson4:32

      I think it's a pretty, a pretty strange time in the market. So I think that, you know, I, I started working in, you know, the, right before the 2008 kind of crash. And so the first two years there were, were not so good. When I joined Yahoo, there was a, a layoff basically every like four months there was a layoff of some sort. It's pretty chaotic. But then we got into the last decade and it was just smooth, right? And so, you know, numbers went up, revenue went up, headcount went up, and people started learning how to build really large teams. People started learning how to hire a lot. When I was at Uber, some days I would do like six, like interviews back to back. I would just be in a conference room and at some point you can't even remember who you're talking to because you talk to so many people one after another after another. You just have some like scrabble, scrambled notes you're trying to like decode afterwards. Pretty, pretty different now. Like a, a lot of engineering managers are spending half their time or more hiring like 18 months ago and now they're doing like two interviews a month or, or, or less. Maybe zero interviews a month. So there's a real shift in just the amount of time people are putting into hiring. Instead like all these different competencies that have kind of become more critical where a really great engineering director might have just been spending their time hiring, hiring really well and that could be like a, a top performer. Now that person can't actually demonstrate like what they're great at and so that person might be perceived as a, a low performer if they're not also like figuring out how to like lead the team, getting deeper into details and also like, you know, sometimes getting into the figuring out like what, what is the right allocation, like what is the right sizing of engineering teams, right? Like this is stuff that we weren't talking about much.... or maybe if you, uh, if you really pissed off the CEO, maybe in infrastructure, you just grew a little bit slower next year. But, but, you know, different, different ballgame at this point where teams are actually disappearing, teams are getting cut down, teams are getting consolidated and that, that's just something that we've kind of avoided for that sort of era, that now we, um, have become like a core part of a lot of the job.

3. 6:27 – 8:32

   We need to stop treating engineers like children

   1. WLWill Larson6:27

   2. LRLenny Rachitsky6:27

      It feels like also engineers have... They used to, they used to have a lot of leverage over companies, inside companies. I imagine that's also changed in a big way.

   3. WLWill Larson6:37

      I think that's true. Um, I think this actually has been bad for engineers in some way. Like one, one of my like hobby horses is that I think that we often treat engineers a little bit like children, instead of giving them, like, the responsibilities and ability to actually thrive as adults. And so like, "Oh, the engineers won't want to do that work," right? Well, that's actually not good for the engineers to kind of be sheltered from what is important. And so I, I actually like... One of the, I think, highlights is that I think we're coming back this moment where we can actually treat engineers like our peers and put them into really senior leadership roles and not have this kind of baseline assumption of like, oh, we have to coddle them or hide them from the real problems, and this is how they're gonna get the opportunity to grow as well. That- that- that's like a highlight for me in kind of the shift recently.

   4. LRLenny Rachitsky7:18

      I've definitely worked with that and experienced that where you don't want to piss off engineers. And so are you saying that because that's changing, leaders maybe don't have to worry as much about upsetting engineers? Plus you just generally think we shouldn't treat engineers that way?

   5. WLWill Larson7:32

      Well, I, yeah, I think a little bit of both, but I- I think there, there's been, you know, in this previous era where hiring and retention were kind of like one of the biggest ways you evaluated kind of middle management. Um, losing team members was huge, huge issue, right? And, and so you started to coddle a little bit, which is actually bad. Again, bad for the engineers, bad for the teams, bad for kind of everyone, bad for efficiency of the organization. But now like, something that I love is we get to like give engineers real hard problems and we get to, we get to actually hold them accountable, and that means we can put them in senior roles. So one of the things that I've been pushing on, I- I wrote my, my last book, Staff Engineer, about like what is the career path for senior engineers. One of the challenges is like if we aren't comfortable holding engineers accountable 'cause we just want to retain all the engineers, then we can't put them in senior roles. And so I think we're actually seeing a bit of a shift where we can actually hold them accountable, which means you can put them in senior roles, which means the engineers can actually get what they've been trying to get the entire time, but we haven't been able to because we've been coddling them a little bit too

4. 8:32 – 13:23

   Systems thinking

   1. WLWill Larson8:32

      much.

   2. LRLenny Rachitsky8:33

      Okay. So there's a few directions I want to go and I'm just gonna poke around and see where we go. The first is your big advocate of systems thinking. We were chatting about this before. I think a lot of people have heard this term systems thinking, and there's books about it. It's like sounds great. I want to be a systems thinker. What does that actually mean? How do you find you apply it in your work? How do people get better at this way of thinking?

   3. WLWill Larson8:57

      A lot of the least successful but smartest people I've worked with were really strong systems thinking advocates. And so I- I do want to say like every, every kind of like framework has like a lot of downsides. There's no framework that people can apply consistently, universally and get good results. And so briefly on this one, I- what- what I see is like often people will find a spot where their system and reality are in conflict and they'll be like, "Reality's wrong." And so what- what's a concrete example? At- at Stripe, we worked on incident management. And so Stripe, um, pretty important company where our API is available. If the API is down, you lose money. And if you lose a lot of money, you- you leave Stripe because you're pretty upset about that. Like the number one thing businesses need to do is like to collect money successfully for- for the- the service that they're selling, right? Stripe's super important. And so we did a lot of analysis on incidents trying to understand why things weren't working, you know, what we could do better. But we got like so caught up in the analysis that we sort of lost track of whether we're actually improving things. It took us a while to- to figure that out because we were so stuck in the systems thinking model and it's not like, oh, the team was wrong. It's like, I was wrong. Like, I was- I was caught up in that model myself to realize like, hey, we weren't actually prioritizing improvements. We were just prioritizing measurement. And- and you can't- you can't keep measuring, you know? There's like measure twice, cut once. Like sure, but you don't measure in- infinite time- infinite times and never- never get to cutting. You do have to cut at some point to actually make impact. But- but we just got caught a little bit there. And I think a lot of people who get too far in systems thinking make the same mistake where they- they think reality is wrong and reality is never wrong. Reality is always right. Your model is always wrong if it's in conflict with- with reality. But that- that conflict, that- that gap is really interesting and that's where you can learn. And so I have this model. It's- it's really clean. It represents, um, you know, your hiring pipeline, that moving through different steps. It represents your- your incidents and how you remediate incidents. It can- it can- can model, um, almost anything pretty quickly when you get good at it. And then understanding how reality is in conflict with that, you start to understand where your mental model is wrong. Then you can go educate yourself and improve the model and just keep doing that. And at some point, like the model is close enough a- and you can stop doing that and go like actually do the work. So the- the- the biggest thing I tell people is this is a great way to learn, but you also have to do things. You can't just learn. That's not our entire job.

   4. LRLenny Rachitsky11:25

      To make it a little more concrete, how would you best describe this idea of systems thinking? What's a good way to just like, okay, I get- I get what you're talking about?

   5. WLWill Larson11:32

      This is probably a better place to start, right? Versus a- a rambling, uh, anecdote about using it.

   6. LRLenny Rachitsky11:37

      We can- we can go backwards. It'll be great. (laughs)

   7. WLWill Larson11:41

      Uh, systems thinking is basically you try to think about stocks and flows. So stocks are things that accumulate and flows are kind of the movement from a stock to another thing. And so what's a simple example of a stock? A- a stock could be the number of fish in a lake. A stock could be the number of people fishing in- in a lake. And so a flow between those two could be the- the number of fish in a lake will decrease at some rate based on the number of people fishing in that lake. So if there's a ton of fishers, then the- the stock of fish will go down faster. If there's only a couple of fish, it will go down slower.... but also then there's these flows which kind of dictate that, where if, if you know you've got much more efficient fishermen, uh, the flow of, of fish out might go down. But also the... fish do reproduce so then there's another flow going back. So based on the current number of fish and the rep- reproduction rate, the current number of fishers and their fishing rate, you start to see how these can evolve over time. And a l- a lot of this... So first always recommend, uh, Thinking in Systems by Donatella Meadows. Um, really phenomenal book and a lot of her work is also kind of referencing the work in Silent Spring by Rachel Carson which talks about how, um, small amount of kind of carcinogens or something low in the ecosystem, or the food chain rather, as they get consumed by predators further and further up get concentrated, and that, that's like a, a kind of a classic systems thinking problem to think about, where you wouldn't think a small amount of carcinogens in like a small fish actually matter. But as they go up the, the food chain they start to concentrate it and an unexpected change can happen. Um...

   8. LRLenny Rachitsky13:14

      So then going back to your example of the hiring pipeline, let's come back to that to help connect this definition, which I've never heard which is awesome, very clear, to how you actually implement it, say, in

5. 13:23 – 16:32

   Implementing systems thinking in hiring

   1. LRLenny Rachitsky13:23

      hiring.

   2. WLWill Larson13:23

      The first thing to do is to get a model out there of any sort. And so you think about your, your stocks, and so in a hiring, hiring pipeline you might have, um, you know, potential candidates, and this could be kind of basically in- infinite, and then you have a couple of inflows. So you could have, like, source, you could have, like, outreach, you could have referrals, and then you have, like, the, you know, candidates. And, and those, you know, how many people get sourced is probably a function of number of sourcers you have dedicated to a role, so you could have another stock of, like, how many sourcers you have and then that would impact the, the rate going from potential candidates to actual candidates you, you've sourced. And then from candidates that you have in that box you have like a conversion rate for people who pass the first recruiter screen, and that would move into step two of your process. And then from step two you have maybe, like, a hiring manager screen and that would be another conversion rate. So you can see, like, over time how the candidates of... the infinite potential candidates, like, wandering around LinkedIn, uh, posting about their deep thoughts kind of convert, convert into actual people your first, your second, your third, and... but then as you get deeper into it you start to actually see interesting things. And so for a lot of candidate or a lot of pipelines the, the biggest issue is hiring managers don't want to extend any, any offers 'cause the hiring managers can't get to confidence on any candidate, and you'll see in this pipeline, you'll see a ton of candidates getting to offer stage but almost none of them converting from potential offer to, to actually offer. And then you can say like, "Hey, hey, here's the problem. You need to go work with the recruiter and the hiring managers on, like, getting conviction about who they should hire." Classic problem with early, early managers, right? Here's a second problem. Manager wants to extend a ton of offers, they do extend them, and none of them actually accept. And so that focuses you on the second problem. But there's a, a third potential world where actually you're just, like, not getting enough candidates in, you're actually doing a great job of making decisions, great job of closing candidates. There are just not enough candidates coming in. And so by looking at this... and you can, you can build this model and you can go to your, your applicant tracking system like Greenhouse or, or whatever and pull the, the historicals and you can just see how the historicals work versus how you'd expect it to work and you can see the drop-offs. And this helps you figure out where should you go try to fix things first. I, I think we've all worked in companies where you roll out kind of, like, big changes with no data behind them 'cause, like, oh, it feels like we're not n- not hard enough in how we evaluate candidates or something. You go change a bunch of stuff. But, but often the real problem might be that the hiring manager is, like, making offer extensions to ca-... people who never passed the loop anyway. It's just the, the managers are issuing too many offers because they're, they're panicking. And man, less true now, but a decade... or not a decade, like, two years ago, like, hiring managers panicking to get offers out, that was a real thing that, that happened a lot. And this just helps you take a, a complex kind of abstract problem and turn it into something you can actually, like, work in a systematic way.

   3. LRLenny Rachitsky16:17

      I feel like product managers will na-... either naturally do it, things this way already because a lot of them think in funnels, uh-

   4. WLWill Larson16:23

      Thank you.

   5. LRLenny Rachitsky16:23

      ... and it's interesting to hear this version of it, of this idea of just, like, following the stock through the flow of the different steps. Uh, awesome.

6. 16:32 – 20:21

   Engineering strategy

   1. LRLenny Rachitsky16:33

      Another thing that I know that you are very passionate about and spend a lot of time thinking about is engineering strategy. I think you have this, uh, kind of feeling like engineers don't think enough about the eng. strategy. Every other function has a strategy and engineers often don't. Talk about what you find there and what your advice is around that.

   2. WLWill Larson16:52

      First, I start to question whether any, any function has a strategy in most companies. I, I... my general experience is that there's very rarely, like, a written strategy for any company. Sometimes it's, like, a value statement. It's like, "We build the highest quality products," and you're like, "Good. Okay." Like, "What does..." (laughs) "What, what, what do I do with that?" You're like, "Build a high quality product." You're like, "Okay. Uh, I don't know what that means." Engineering often has this problem where I think people will make comments, like, in their, kind of their, their culture app 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, I tell people when they complain, um, and then engineers complain about the product strategy, like, the, the PMs don't have any strategy or the, the business has no strategy, and the, the, the reality is, like, product, eng., and business always have a strategy. It's just often not written down. And so I really... like, the first thing I want to do is, like, I push people, like, not to get caught up on, like, the fact that there's no template out there which is, like, product strategy that someone's, like, forked and, like, filled in. It doesn't mean you don't have a strategy. You do have a strategy. It's maybe, like, a little bit hard to, like, articulate and maybe it's, like, implied inconsistently across different, like, layers of the, the product, like, reporting chain because it's not written down. But, like, it's never true that there's, like, no product strategy. There's always a product strategy. Sometimes it's bad, but there's always one. And, and, and true, true for engineering as, as well. There's always an engineering strategy, it's just sometimes it's bad.And the, the first rule of strategy is that if you write it down then you can, like, improve it, right? If it's not written down i- it's hard to say, like, if, if this PM is just, like, not a good PM. Or if they're trying to apply the strategy but they've misunderstood. Or if they are actually are correctly applying the strategy from the, the head of product that's just not appropriate for the problems they're working on. How do you debug any of that? If you have a written document, um, even if it's, like, not a super compelling strategy, at least you could start debugging. It's like, "Hey, the, the head of product should improve the clarity of this document. Hey, this PM actually isn't applying it correctly. Hey, um, this strategy actually isn't appropriate for this one business unit where it makes sense for, for, for the others." Um, so, so that- that's, like, kind of the, the first thing I think about. But the, the second kind of big theme around strategy I think about is that often good strategy is so boring it's, like, ha- hard to talk about. And so f- for example, on the engineering side of thing, uh, a common strategy that's really good but very boring is we only use the tools we have today. So, you know, a lot of times you'll get engineers, um, that want to introduce new programming languages, new databases, new, 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, when I joined we... You know, one, one of the engineers, Eric Vogel, wrote the standard kit and that is our strategy of the tools we use. And you know what? P- some people are really frustrated by that. And, and I, I feel for them. Like, it, it feels like they're losing, 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, like, slightly misaligned over time. But boring strategies that tell you what actually matters, um, and aligns you with what the company actually cares about a- are really good for you, e- even if, even if they're a little bit annoying at a time. And, and I can expand on this idea a lot, but I, I won't, I won't ramble indefinitely on it.

7. 20:21 – 25:08

   Examples of engineering strategies

   1. WLWill Larson20:21

   2. LRLenny Rachitsky20:21

      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"?

   3. WLWill Larson20:31

      So first, what is the definition of, of strategy? And the, the best one I've ever seen is from Richard Rumelt. Um, he, he wrote Good Strategy/Bad Strategy.

   4. LRLenny Rachitsky20:40

      He's coming on the podcast.

   5. WLWill Larson20:42

      Amazing. Uh, he also wrote The Crux, I think came out, like, this year sometime, which, which I also read and I think both, both great. And just, like, a phenomenal thinker who has so much depth. I, I think one of the challenges of, of writing about strategy is you're, like, I've seen two things and I, I write the book, but I think the thing that's impressive about Richard Rumelt is he's seen so many different scenarios that he's able to really operate from both, like, the, the particular but also, like, the general and data set in a really interesting way. Another book with similar characteristics is, uh, How Big Things Get Done by, I forget the, the authors, but, but really amazing data set of how mega projects kind of succeed and fail. But anyway, um, Richard Rumelt definition of strategy is basically three components. There's a diagnosis, like, what is the current status quo? Like, what are the things that are real today? There are guiding p- policies which are basically based on the diagnoses, like, how do you want to address them? And there's actions. And actions are, um, how are we gonna implement those guiding policies? And he talks a lot about actions 'cause he's concerned about this idea of, like, inert strategy where you have, like, like, we're going to deprecate our old product features we don't use, but no one deprecates any of them. So he's really concerned about this, like, non-implementation kind of, like, useless strategy that doesn't do anything. On engineering I'm a little bit less worried about that. Yeah, I think strategy is more, more interesting on engineering in terms of kind of clarifying how we make future decisions. And so what, what are a few examples of that? At, at Uber we only used our own data centers. We didn't use the cloud. And, and this has changed since, since the era I was there, but in the, like, 2014 era ev- no cloud and we had a, a strict no cloud policy. And this was annoying 'cause we had to invent everything ourselves or run copies of everything ourselves. But it also meant that we were able to spin up in China in, like, literally three months. And some, like, surreal stories from that. Um, we, we couldn't fit our racks into the data centers, so we had to, like, take the roof off the data center and, like, lift, like, the racks in with a crane.

   6. LRLenny Rachitsky22:43

      Holy shit.

   7. WLWill Larson22:43

      There's just, like, tons of stories. And, like, all this got done in three months, um, and, and truly, truly phenomenal. And Uber wasn't in China for very long, so in, in some ways you're like, "We did all that just to leave?"

   8. LRLenny Rachitsky22:54

      Mm-hmm.

   9. WLWill Larson22:54

      But, but they left with, like, a, a nice, a nice stake of ............................ and not, not, not a, not a bad outcome, um, overall. But I think that strategy, we run everything in data centers, we don't use the cloud, meant we were able to move in and out of different geopolitical constraints. And companies that relied on cloud presence simply can't. They're, they're fully, um, constrained by where AWS or Google Cloud or, or Azure have built out. Um, so that- that's one good example. Um, another good example at, at Stripe was this idea of we run a, a Ruby monolith and, and that's, like, that's what we did. And that, that's evolved a bit since then. There, there's more, there's more Java in, in the Stripe of 2023 than there was in the, the Stripe of, of 2016 or the 2012 or whatnot. But that, that policy, um, really focused the, the engineers on building innovative features for our users rather than building kind of different tooling to support different programming languages. And so in both cases, both the Uber policy around, like, running our own data centers and the Stripe policy around, you know, Ruby monolithSs, a lot of engineers hated these. But the goal of good strategy is not to, um, appease everyone. The goal of good strategy is to dictate how we invest the limited capacities we have or the limited capabilities we have into the problems we care about, and I think both of them were really effective towards, towards that end.

   10. LRLenny Rachitsky24:17

       A common theme across all these examples is essentially constraint. Deciding we will constrain our o- options to move faster and focus on things that really matter.

   11. WLWill Larson24:27

       And solving the constraints is, to me, I think the most interesting thing that, that strategy really does. And I think when we talk about bad strategy, u- usually it's because the diagnosis is bad. And it's usually because people are, are sort of exerting what they want to be true on, on constraints. Where it's like, "Hey, we can do all these projects at once." And often that's just not true. But, but it's hard to convince people of that when they're, um, the CEO or, or they are really committed to believing it. But almost all bad strategies basically come down from a, um, willful disbelief of what an accurate diagnosis is. Which means then your, your guiding policies are kind of incoherent to begin

8. 25:08 – 26:48

   How to get good at strategy

   1. WLWill Larson25:08

      with.

   2. LRLenny Rachitsky25:08

      Awesome. I'm excited for that episode with Richard where we're going to go real deep into strategy. But maybe just as a lasting topic around there, if someone listening wanted to get better at, say, end strategy specifically or strategy in general, is there anything you recommend they do? Is it read these books? Is there anything else?

   3. WLWill Larson25:26

      If people want to get good at strategy, there, there's a lot of different types of strategy, right? But here, here are some things that I'd really recommend. First, I think the, the Richard Rumelt book. I think Good Strategy/Bad Strategy is probably the right starting point. I think The Crux also, also quite good, but, but maybe I would read that one second. Great overview of how to think about strategy. I also think Thinking in Systems, I mentioned that before, related to systems thinking. A big part of strategy is being able to model the reality so you can improve your diagnosis. And so I think that, that one's really quite good as well. If you get into the engineering side of things, there's a lot of interesting books here. Um, there's Technology Strategy Patterns by Evan Hewitt. There's The Value Flywheel Effect by, um, Andersen, McCann and O'Reilly. The, The Phoenix Project by Kim, Burrage, Spafford which is kind of a modern rewrite of The Goal by, um, Goldratt. But I think there's like still the missing canonical book is kind of missing on this one. So I, I took a stab at strategy and my upcoming book, um, which is coming out, the Engineering Executives Primer, coming out early next year. Also took a stab at it in Staff Engineer, my previous book, but I still think there's like a missing book here. So I, I sort of am like dreaming of writing like a, a engineering strategy book for my, my next project. Although, we'll, we'll see, we'll see if, if that actually comes together.

9. 26:48 – 32:40

   The importance of writing about things that excite you

   1. WLWill Larson26:48

   2. LRLenny Rachitsky26:48

      Well, let's actually follow that thread of writing, something I was definitely hoping to chat about. You write a lot. You've written two, three, four-ish, you're writing a new book. How many books... You've published two books and there's a third one coming out?

   3. WLWill Larson27:00

      So I, I have two books. The first one, first one was Stripe Press.

   4. LRLenny Rachitsky27:03

      Yeah.

   5. WLWill Larson27:03

      The second one self-published and the third one at O'Reilly coming out in like two months effectively.

   6. LRLenny Rachitsky27:08

      Okay. And then also, uh, many, many blog posts, uh, for many, many years. And I asked a few people what to ask you and this came up a lot. Uh, Gergely Orosz and, uh, Alex Zhu from BytebyteGo both asked just this question. Just how do you make time to write as much as you do? And then I also, uh, I'll ask this too and just answer it either first or second is just what impact has writing had on your career? Why has it been... Why do you keep doing it?

   7. WLWill Larson27:37

      I feel really strongly that you can write a lot more if you write what you want to write. And so-

   8. LRLenny Rachitsky27:42

      Mm-hmm.

   9. WLWill Larson27:42

      ... this is one of the reasons I don't, I don't write for, for financial gain. And I don't write, um, I don't write very much on like, on a schedule. So I've done like a few pieces for, for magazines, et cetera. But I, I find that actually really draining to be... You have a topic, you have to agree on the topic. If, if the topic starts like miss- missing, like your, what you want to write about, you can't fix it a lot of the time.

   10. LRLenny Rachitsky28:05

       Mm-hmm.

   11. WLWill Larson28:05

       And you're also like on this deadline. You're like, "Oh, I'm like, I'm screwing up. I need to ship this. It needs to be done tomorrow." And I, I just find that really draining. Um, where conversely like when I, when I own the schedule, when I get to like write about, hey, like I'm writing about something... So I started writing this infrastructure engineering book a couple of years ago and I just like, it just wasn't there. I just couldn't get it to come together. And so I just stopped and I'm not writing it anymore. Maybe I'll come back to it at some point, but probably not. To me, um, the, the biggest, the biggest strength of writing what you want is you get to write where there's energy and you don't have to write where there's no energy which takes you like really, really negative. And this, this also ties into how I write books, which is that I, I basically write the entire thing before I start working with a publisher. And if you are I think diligent and good at anticipating what their concerns are going to be, you can, you can mostly reuse the content that you're trying to write. This is also easier in the sorts of books I write. I think harder to do in like a really technical introduction to like, uh, MySQL or something. It... You can't just like re-sequence those chapters and pretend it's going to work. Those chapters are built in like a different way than the sort of business book that, that I write does. But yeah, that... Writing the stuff that's energizing and just giving up on the stuff that's not energizing, that, that's how I write a lot and how I've been... You know, I've been writing for 16 some years, um, and, and the way I keep doing it is just by writing what's energizing and what I'm thinking about now. And I don't write what I'm not thinking about, and I don't write for any audience. I just write, write what is interesting to me and you know, that, that means some people don't like it and, and that's great. Like that's, that's totally fine. It's, it's not, it's not really for them. It's, um, for, for people who want to follow the ride and, and that, that's where I focus.

   12. LRLenny Rachitsky29:57

       This episode is brought to you by Vanta, helping you streamline your security compliance to accelerate your growth. Thousands of fast-growing companies like Gusto, Calm, Quora, and Modern Treasury trust Vanta to help build, scale, manage, and demonstrate their security and compliance programs and get ready for audits in weeks, not months. By offering the most in-demand security and privacy frameworks such as SOC 2, ISO 27001, GDPR, HIPAA and many more, Vanta helps companies obtain the reports they need to accelerate growth, build efficient compliance processes, mitigate risks to their businesses, and build trust with external stakeholders. Over 5,000 fast-growing companies use Vanta to automate up to 90% of the work involved with SOC 2 and these other frameworks. For a limited time, Lenny's podcast listeners get $1,000 off Vanta. Go to vanta.com/lenny. That's V-A-N-T-A dot com slash Lenny to learn more and to claim your discounts. Get started today.Okay. There's a lot more I want to dig into here. How many posts have you written, do you think, over the 16 years?

   13. WLWill Larson31:00

       I would guess about 1,000. Like that, that would roughly be my, my assumption. I, I think, um, there were a few years where I wrote, you know, h- hundreds of, of posts. And so if you do that like three years, it's not that hard to get to 1,000 from there.

   14. LRLenny Rachitsky31:16

       That's incredible, especially because you've had intense jobs for all of those years or most of those years, very high pressure, fast-growing, hyper-growth companies. Somehow you find time to work. So first, let me just double-click/cosign your advice here around paying attention to what gives you energy and working on things that you're actually curious about. This is exactly the advice I give to people. A lot of people start at this like full-time writer creator life, and they're like, "What do people want? What do people want me to write about? What's popular? What's gonna, uh, go viral?" And that's easy to do like a couple of times, but then you end up creating this job for yourself that you, you don't want. You don't want to be spending all your days writing about AI if you're not that excited by AI or whatever's hot these days. And I find that... What I find is important is almost like 80, 90% of what you have to... what you write has to be stuff you're excited about, and then maybe there's a bit of, "Here's what I know people really want. Here's what I know is gonna do really well." Because otherwise, you just burn out. You create a job for yourself that you don't want. Why would you do that?

   15. WLWill Larson32:13

       Yeah, I just 100% agree with that, and I think, um... The, the other thing is that like everyone converges on the same thing that they think people want. So it's like, it's crypto two years ago, it's like AI right now, or it's like counter-AI, like AI is gonna like ruin the world. It, it's just like, it's hard to say something very novel, uh, because one, like everyone's trying to like say something about it. Two, like, it's almost certainly not what you're that knowledgeable about, um, where if you just stick in your lane,

10. 32:40 – 35:24

    The biggest risk to content creation is quitting too soon

    1. WLWill Larson32:40

       I think the biggest risk to writers is quitting. A little bit like the 40-year career idea, the biggest risk to content creation of any sort is quitting soon because you get burned out. The, the biggest risk is not that you, um, grow too slow initially. It... There's this, there's always a sense that like you've missed the wave, like it's too late to join Substack. There's already... The top writers are already there. You'll never be a top writer. It's too late to podcast. There's too many podcasts. You'll never make it. It's too late to join Medium, like you'll never make it. There's too many Medium writers. But it, it's just like not true. If you just like keep writing good stuff, you'll build an audience over time and you can take that audience from platform to platform. What really matters is finding something you can actually keep doing for the next decade. That's way harder than, um, doing it for one year.

    2. LRLenny Rachitsky33:25

       We have the same exact advice on this. This is exactly the things I tell everyone. When I joined Substack, I thought it was too late. I was like, "Man, it's over." And when I started this podcast, like, "Oh man, there's a billion podcasts. How is there ever gonna work?" So I so agree, and I also so agree on the fact that this whole thing is such a... It's a long game. There's a lot of people. I always say, it's easy to start a newsletter, hard to keep it up. Nobody actually keeps it up 'cause people are gonna come and go. The thing that really separates success from not succ- from failure is just people that can keep at it. And there's not like an end game to this, right? It's an infinite game, and it's about being able to sustain that over long term.

    3. WLWill Larson34:04

       And, and you're not competing with other, other content creators. If you think of it as an infinite game, right, like you're all, you're all working together, you can all like help each other grow. There's no like maximum number of product writers or thinkers who can like be doing something, like you're not less successful 'cause Shreyas exists or something like that. Like there's no, there's no competition there. It's like a false, false dichotomy.

    4. LRLenny Rachitsky34:27

       Yeah. I totally agree with that. Unless there's so many, and then all of a sudden what happens is the bar just gets higher, which is good 'cause then people get better stuff, and that's fine. And that's happening anyway. Just the bar continues to increase because there's more and more content out there. And to me that's like the ultimate thing you gotta get right, is just the bar... You just gotta be at a high bar for anyone to care about anything you're writing about. And to your point, to do that well, you have to actually be excited about writing a bit about it and have background and have something to contribute. The way... I'm just ranting here, but, uh, the way I think about this is you need to add something new to the conversation for anyone to pay attention 'cause there's so much fluffy superficial stuff, and to get anyone to care is you need to say something new that no one's heard before or share new information they haven't seen anywhere else.

    5. WLWill Larson35:15

       Totally, I totally agree. I just, uh... I could keep ranting about this for, for the entire time. (laughs) I don't wanna derail on this, but I, I totally agree.

    6. LRLenny Rachitsky35:23

       We'll control

11. 35:24 – 37:41

    How to make time for writing

    1. LRLenny Rachitsky35:24

       ourselves. So then getting very tactical, I think this is what a lot of people are always wondering, how do you, how do you make time? What's your workflow? How do you make time for writing so that you keep at it with knowing you have an intense full-time job?

    2. WLWill Larson35:34

       I used to do things differently before, before I had a kid. So I have a three and a half year old, and, and just your, your timing, your, your life just like really shifts a lot once, once you have kids. Um, but the, the biggest thing that I found is finding things to write about that also directly relate to what I'm working on, and this is where I can do something that helps me at work and helps me write at the same time, 'cause I think it's, it's, it's incredibly hard to find time to write about stuff that has nothing to do w- with your work 'cause it's all... and just distracts you from, from your work 'cause the... these, you know, particularly if you're in like a, a senior role, like these can be like pretty demanding jobs. But they're not demanding because you're responding to an urgent DM on Slack like every, every five or six minutes. They're demanding 'cause you need to make some really difficult decisions really well. And I think writing about like related topics is a great way to refine your thinking and improve your performance. It's not like a... not like a conflict in... or you do one... you either write or you do your job. Well, I, I think you can find a way to like align. And so a lot of podcast folks, um, do interviews with folks who are related to what they're thinking about at work, and that's a great way for them to like learn, to build their network, to refine their thinking, to test their thinking against experts in the field. It's not like in conflict with the work. It's, it's, it's in alignment. So th- that's like one piece.But, but yeah. I've played around with my schedule a lot. Before, before I had a kid, often like Saturdays would be, like, the writing day and so, like, you know, morning and early afternoon would just be, like, writing. I can't, I can't do that anymore, so, so now I, I mostly write at night which is tricky from an energy, energy management perspective. But the, the biggest thing I, I would say is just, um, if you're actually excited about something, you will find time and energy for it. If you're not excited about it and it's 9:00 p.m., you're just gonna get asleep. And, and so like I, I really think that this is where you have to schedule a little bit deliberately, but the first thing we talked about around energy management, like they, they really come together. Wh- when your schedule gets tight, if you're not energized, you just won't get it done. And why would you? Like, it just doesn't make sense.

12. 37:41 – 41:18

    Tips for aspiring writers

    1. WLWill Larson37:41

    2. LRLenny Rachitsky37:41

       Just to close out this thread, for someone that wants to do more writing, knows that it's gonna be valuable, but just hasn't, any one tip that you would leave them with to get on this train?

    3. WLWill Larson37:51

       It depends why people wanna write. I tell people if, if you just wanna, like, write something that is gonna help advance your career, you should really focus on writing, like, two or three really good things and spend a ton of time drafting, revising, getting feedback. You just focus on making, like, one great artifact or two or three great artifacts. You don't need to create, like, a, a long running blog where you publish every week. Like, there's really no need to, like, do that if your goal is just to, like, create some artifacts that show you're, like, a deep thinker, that kind of, like, help position you in, in the industry. Don't, don't start a newsletter if you just wanna, like, advance yourself in the industry a little bit. Just write, like, two or three really good things. So that- that's the, the first thing I'd say. But if your, if your goal is to write, like, a lot consistently over time, my, my biggest advice would be just, like, just publish. And so I... There's a lot of people out there with, like, stuff that, you know, hundreds of drafts and they've, like, not published anything and, and my thing is, like, I publish almost everything I write. If there's something that I'm not gonna publish, I, like, don't start writing it 'cause I just, I have, like, a, a, you know, a quick check in my head like, is this something I can write and publish? And if, if my answer's like no, I just don't even start. And my accuracy has gotten higher, like, o- over time as I've written more. But I publish pretty much everything I write. That's why, like, some of it's, like, not that good. And, and, like, and that's okay. Like, I, I'm like, again, like, I wanna write, I wanna get these ideas out, I wanna show, like, what I'm focused on and my evolution as, like, a thinker, um, trying to learn how to, like, operate in these different roles and these different companies. I'm not writing trying to create, like, a polished, perfect thing. And also, like, I'm not writing to, like, maximize a reader's experience of reading it. And, and some people don't like that and I think that's, like, a totally reasonable thing not to like. But I think what I can bring you is, like, my experience as an operator who's, like, actively learning and thinking through. I think that's really valuable to other operators in the industry. In terms of, like, giving you the perfect writing, like, I try to do that, closer to that. I don't know if I ever hit perfect writing. But that's where my books are. Like, the books are taking, like, a collection of thoughts over, like, a couple of years, cleaning them up a little bit, packaging them. They're, they're way higher quality than my typical writing. But yeah. I would just publish. Publish a lot. Don't worry about the quality. Sometimes people will send you, like, silly feedback and, like, I just don't respond to that stuff anymore. And, and, like, you know, you never know why people send you something like that. I think trying to debug people you don't know is, like, a bad use of time. It's just kind of like, thank you. Move on to the next. Like, d- don't even, don't even spend time worrying about it.

    4. LRLenny Rachitsky40:18

       I like that term debug people. Uh, I think people way overestimate how much anyone cares about what you put out. Most people are gonna look at it for three seconds and be like, eh. Like, that's the worst case scenario basically is just like, I don't care about this. Not like, oh, Will is such a fool. What a dumb thing to say, right? No one's... No one has time for that.

    5. WLWill Larson40:38

       A- and if they do, like, that's, like, that's a them problem, right? Like, it, it's like there, there are... The internet's a big place with a lotta people and there are people who are gonna be having, like, a really bad day when they encounter something you do-

    6. LRLenny Rachitsky40:49

       Mm-hmm.

    7. WLWill Larson40:49

       ... and they're gonna be, they're gonna channel that anger at you or that frustration at you. But that's, like, that's not about you. That's just, like, you happened to be there when they engage with it. Like, you don't have to take that on. That- that's, like, that's not your situation. Like, it's okay.

    8. LRLenny Rachitsky41:03

       Also, when you're just starting out, that's gonna be the least stressful time to write 'cause nobody knows it or sees it. So that's when it's like take all the crazy shit, just do stuff. Like, it only gets more stressful as you build a audience over time.

    9. WLWill Larson41:15

       Yeah. Absolutely. Absolutely true.

13. 41:18 – 43:45

    Building productive relationships between product managers and engineers

    1. WLWill Larson41:18

    2. LRLenny Rachitsky41:18

       Okay. Shifting topics. There's a lot of product managers that listen to this. Something PMs often wonder is how to have better relationships with their engineers, their eng managers. What advice could you give to product managers to build more productive, happy relationships with their engineers and eng managers?

    3. WLWill Larson41:37

       So the, the core problem in most of the EM/PM pairs that I've worked on... Oh, there, there's two core problems. Um, so one, sometimes the incentives are misaligned and, and that's, that's hard to navigate. But if you can just be, like, honest with each other and understand the incentives, sometimes you can find a compromise. But sometimes the EMs and PMs will be misaligned 'cause just their, their incentives are so far apart that there's no way to get to the bottom of it. And so this might be, like, timeline related or saying yes to sales related where the engineer's like, "Hey, we definitely can't say yes to that," and the PMs are like, "Actually, like (laughs) we're gonna say yes to it 'cause it's really important for me getting promoted," or something like that. And that... I- is it ever this simple? It's really never that simple. People create, like, simplistic narratives to, like, find villains that they work with. There, there are no villains in the workplace. They're just people with, like, complex incentives that are doing complex things. But, but sometimes, like, I talk to EMs who think, like, oh, that their product manager's just saying yes 'cause they want to get promoted because the salesperson will review their promotion or something. I... The reality is never as simple. The reality is, like, the business needs to sell stuff to remain functioning. You can't just, like, say no and, like, have the business succeed. That doesn't work either. So, so one, understanding the incentives. Um, the other piece though, and I think this is the more common case, where just the, the EM or the PM just don't understand the other person's needs.... and they start arguing before understanding. And so my biggest advice to both the EMs and the PMs is before you try to solve the conflict, it's like pushing to ship this feature, pushing to change the approach, just make sure you actually understand what they care about. There is this, like, idea that, um, you have to make trade-offs and that there are tons of hard trade-offs to be made in, in kind of the, the, the field. But my, my experience is if you really deeply understands what everyone wants, there's usually like a, a compromise solution that gives everyone exactly what they want that doesn't take more time. You just have to be willing to dig deeper into it and understand, like, the true needs for each party, which is often, like, not what they're saying, by the way, which is part of the confusion.

14. 43:45 – 48:24

    Giving the same performance rating to EMs and PMs

    1. WLWill Larson43:45

    2. LRLenny Rachitsky43:45

       On the incentives piece, is there anything you've seen work to fix that problem? Because if PM performance reviews are based on impact engineering, performance reviews are based on interesting projects, there's uptime, do you just work to change those latter definitions? Do you... what actually can help that situation?

    3. WLWill Larson44:05

       So my biggest thing has been trying to force this idea that like EM-PM pairs are pairs and they generally have the same performance rating. And there's exceptions here, right? Like it, it could be the EM is clearly not performing, and then it's not, it's not the PM's fault if the EM is like, you know, can't show up to work, like the team, like doesn't respect them. You know, sometimes there's a clear non-performance. But generally, like hard situations are not situations where one person's like obviously terrible. Th- those are easy to diagnose. Those are the easy ones. But in cases where there's two folks who seem to be like pretty good but just like the e- the overall execution's not working out, I think this idea that like same perf- same perf rating for both drives like a, a level of, one, pain, but the, the right sort of perspective. A- and also, you know, something that I think Carta has experimented a little bit with over time, um, Henry, our, our CEO has a blog post about trifectas in doing that, but not just for EM and for, for PM, but also for the business leadership as well, where you, you all get graded the same score based on your ability to, um, evaluate and solve for the entire set of constraints, not just your functional constraints.

    4. LRLenny Rachitsky45:20

       Wow, that's so interesting. So your recommendation, something you're doing, it sounds like, is the engineer manager and the PM get the same performance review rating, and so they're discussed in the same... in the same meeting.

    5. WLWill Larson45:31

       So yeah, the head of the... our chief product officer, um, Vrushali and I like spend a fair amount of time like calibrating together and making sure-

    6. LRLenny Rachitsky45:38

       Wow.

    7. WLWill Larson45:38

       Like again, there's cases where there's like an exception-

    8. LRLenny Rachitsky45:41

       Right.

    9. WLWill Larson45:41

       ... 'cause there's like clear, clear issues happening for someone. But on average, um, that, that is what's happening. And I, I think people know that's what's happening 'cause we've told them that. Um, and, and I think that, that's pretty powerful.

    10. LRLenny Rachitsky45:55

        That is so interesting. I've never heard of that approach. That is definitely solving that problem of EM-PM or, uh...

    11. WLWill Larson46:01

        Yeah. The incentives... The incentives are shared now, um, wh- which doesn't... which isn't perfect. It's still hard to balance them. They can still like make the wrong trade-offs, but at least they understand the incentives are shared, which I think is a pretty powerful idea.

    12. LRLenny Rachitsky46:15

        That is really interesting. Uh, and imagine some companies might even wanna include, uh, design managers in that, take it another step.

    13. WLWill Larson46:23

        You know, the role and the, the primacy of different functions in different companies like varies so much that it's hard to have like a one size. Like you could also imagine where you want like the... a staff engineer in that or, or not. And so I think very company specific. But, but yeah, I think design could absolutely be involved, particularly for like a design-led company like, uh, an Airbnb or something like that.

    14. LRLenny Rachitsky46:43

        Wow. So interesting. Maybe just as a final thought there, if a PM is having challenges with their EM, what do you think PMs maybe don't think o- don't realize their engineering managers are finding important or maybe or stressed about that they're just like, "Oh, wow, I never thought about that"?

    15. WLWill Larson47:00

        I think one of the biggest challenges I've historically seen, uh, particularly in the last like decade is this idea that engineering managers have the job of giving their team interesting work. And, and I think that that can put... You know, you often see this in like growth teams where the growth team's like, "Hey, we just need to do like a ton of experiments." And the engineer's like, "I wanna build something brand new." And the, the eng managers in between those try to figure out like need to ship 50 experiments that are pretty boring and they wanna do something brand new, like, "I don't know how to do... solve this." And so they... it, it's a tricky, a tricky moment. And good, good EMs kind of like find the way to balance. But that, that's like the biggest source of kind of ongoing friction where the EMs have been told by their teams they need to do something that the PMs just have no visibility into, and it makes the EM seem like totally on unreliable partners because they're trying to solve these in... little bit of these invisible constraints. And that's where I think pushing further to understand like, "Hey, like you keep prioritizing this like rewrite into a new programming language. To me that seems like completely, um, idiotic thing to be doing, like what's going on?" And then once you understand, you might not agree with them, but at least you can have an honest conversation about how to navigate those constraints versus just like, "Man, you won't believe what my EM partner did today. Like this, this bozo did like blah, blah, blah." And having like sort of this like victim villain kind of mindset about your peers.

15. 48:24 – 55:53

    Measuring engineering productivity

    1. WLWill Larson48:24

    2. LRLenny Rachitsky48:24

       An adjacent topic that I wanted to spend some time on is measuring engineering velocity, productivity. I think it's probably one of the most common and also maybe the most annoying questions eng leaders get is just how do I know if my engineers are moving as quickly as they can? How do we help them move faster? What advice do you give to eng leaders for... and eng teams just for how to measure productivity well?

    3. WLWill Larson48:44

       This is a question that's coming up even more, right, in, in a moment when we're kind of reducing a lot of the size of teams, when the industry... when the, the venture capitalists that are on the board for these like venture-backed companies are pushing on the efficiency of engineering. Engineers are trying to figure out like how do we like how do we represent this? Um, how do we prove that we're appropriately productive for the amount of headcount and funding that, that we have as an organization?... and man. That's hard. And, and so the, the first way that people kind of focus on trying to answer these questions is just like benchmarking by like the amount of funding that you have. And that's pretty straightforward to do as a mechanical exercise. You look at like you get a data set from your, your, your venture capital funds or, or whatnot and you figure out like, okay, how much should we be spending on R&D? How much should we be spending on engineering? How much should we be sending on, you know, infrastructure engineering in R&D? And you can like benchmark this all out and, and figure out what the correct numbers are there. The problem is this is like a very mechanical and not very like insightful driven way. Like it will get you a defensible answer. It's like the old, like no one gets fired for buying IBM, which definitely hasn't been true in my, my career ever. But, you know, this idea that if you just have the right benchmarks, like VCs won't judge you for spending too much on engineering. But this doesn't actually help you get to the right place, it just helps you get, um, your board to be less angry at you. That's... which is useful 'cause it's hard to do good work when your board is angry at you. But it's not useful in the sense that it doesn't actually help you run your, your, your organization effectively. So then there's like the, the much harder and meatier problem of how do you actually know if your R&D team or engineering team is like effective? And, and what I find is a couple of things. Um, first, if you're a good leader and you talk to the engineers, they will tell you. Like the engineers know if their teams are effective or not. And if they're not, they, they'll also tell you why not. And their diagnosis can be wrong. But there's like a, a crumb you can start like picking up and you can trace, trace the crumbs to figure out what's wrong. Like often you'll have more experience to analyze the, the, the complaints to figure out what kind of the contributing causes are, uh, to, to them. But, but yeah, if you just go talk to the team on an ongoing basis, y- you will know if they're effective or not and you can go work to, to solve those specific problems. But again, you can't tell like your board, "Oh, like it's fine. I talked to the teams that they're good. Uh, my intuition's spot on." 'Cause how do they know if your intuition's good or not, right? They're, they're dealing with like a huge portfolio and some of their leaders they're talking to are good and some of them have terrible intuition. How do they actually assess? I think it's tricky. Um, and, and what I've, what I've tried to do is basically two things. One, aligning engineering evaluation so that the business and product goals... So I want us to be wholly accountable with the product goals, not a, um, "Well, we're, we did a good job. Product's like screwing up over there." I, obviously a lot of companies find comfort doing that. But like really we're here to support the products to support our customers in doing like something interesting. We're, we're not here to like build novel systems unless it supports the customer and, and the product. Um, and so first try to align heavily there. Second, I think just like s- showing the roadmap of the valuable things you've done in the last six months is really powerful. 'Cause I, I think sometimes people are like, "I don't have anything to put there." And you're like, "Yeah. That's, that's a real issue." Um, or if you have a ton of stuff to put there, that's great. And, and I, I really find that if you just commit, show the number of meaningful, meaty, meaty things that have impact that you're doing and you can explain the impact, people will kind of step back and give you space. If you can't populate that list, people will have concerns and like rightly so. Like they, they should be, they should be concerned about that.

    4. LRLenny Rachitsky52:36

       Is there any metrics or tools or anything like that that you find useful too? 'Cause these are all awesome piece of advice, but I imagine everyone's always just like, "Give us this number we're tracking. Give us this dashboard. See what engineers are doing."

    5. WLWill Larson52:49

       So one of the most influential books in the last decade, um, in kind of software engineering leadership and, and kind of infrastructure is Accelerate by Nicole Forsgren, um, Gene Kim, and I believe there's a third author on that one, but I'm forgetting right now. Really, really phenomenal book and it, uh, kind of comes up with these like four, four metrics. Um, it comes up with like lead time, it comes up with like incident, um, remediation time. It comes up with failure rate and, and, and the fourth one of some sort. And there's like a, at least 50 different startups out there that are selling you dashboards that kind of instrument the- these, these pieces of data. And they want you to just evaluate your team on them. The, the challenge is these are really good diagnos- diagnosis metrics. And so, Hey, our deployments are slow. Why is that? How do we speed them up? But your deployments being slow doesn't make you a good company or a bad company. It just tells you where you should focus on improving. It doesn't actually change how, how, how you are. And similarly, if your lead time is quick or slow, it tells you where you should invest. It doesn't actually tell you if you should like fire your engineers or something like that. It... that's like way, way more detail specific. So people do like to see these metrics just like they see uptime metrics. A lot of engineers report on like sprint points or stuff like that to their board, which are just like totally, totally fake thing to be like reporting on. But, but people get some comfort on it. So my, my biggest thing here is, um, when people measure things, this isn't an engineering only problem, but when people measure, they, they take on the perspective of an expert and they can tell you why not to measure everything. They can tell you why every measure is wrong or inaccurate and they rule everything out. And so they measure nothing and they go to someone who's not an expert and they're like, "Well, actually there's no accurate measure to give." They're not an expert as like you are- you don't know what you're doing. Really? And so you just have to get comfortable measuring something that's not perfect, but you can actually measure and reporting on it. And then the measure that's imperfect, as people ask questions, that's like an, an opportunity to educate people on like why the measure is imperfect, what are some things it misses or kind of the lies from the conversation. Metrics are about educating the people consuming the metrics about the reality of the rich data underneath. They're not about this perfect dataset that shows everything. Starting with something mediocre and the DORA metrics are really helpful for diagnosis. But if you have to, they can also be-... a good enough starting place to start reporting to your board or your CEO or to the other executives. And then you're like, "Oh, there's all these problems with them." Yes, there are all those problems with them, but that's the place you start and you educate people up from there to help them understand the nuances and that's how they become more sophisticated at understanding engineering, not by refusing to give them anything they can possibly measure.

    6. LRLenny Rachitsky55:36

       Awesome. I'm glad that was your answer because we had Nicole on the podcast and she talked through DORA and all the frameworks that she recommends and she even actually s- shared some benchmarks that she points people to that give you some sense of just like are you in a good place roughly or not. So we'll point people to that episode to dig deeper. Awesome. I'm glad

16. 55:53 – 1:02:10

    Defining company values

    1. LRLenny Rachitsky55:53

       that you're a fan. (laughs) Okay, just a couple more questions before we get to a very exciting lightning round. One is around values, company values, org values. Do you have some really good advice for people for how to think about coming up with values? What do you share? What do you recommend to people that are trying to figure out what values they should define for their org and their company?

    2. WLWill Larson56:14

       I mean, values are really interesting, right? And different companies talk about values in different ways. I once worked at a company where the execs went to visit the Facebook campus. They saw the values written up on the wall and they took the Facebook values and wrote them up on our walls. And, and that, that didn't do a whole lot. It, it, it maybe undermined people's confidence in the critical thinking of the executive team that just took these written up on Facebook walls and, and replicated it. But I think those values did work well for Facebook and those values were meaningful for Facebook. And so it's... First thing you can't do is just, like, steal values, right? C- value cargo culting. Yeah. Users first. Great Amazon value, right? A lot of companies aren't users first. A- and that's okay, but what's not okay is when you put, "Hey, we're users first," and then you actually show, like, the decisions you're making and you clearly aren't users first. And so one of the things I think about is just, like, honesty. And so good values have to be honest. And so any value can be honest or just... There's no universally honest values, right? Like, you can say something like, "We're thrifty," or we can say something like, "We spend as much as we need to get the best value." Those are totally different and good companies are run both ways. So the first rule I think about a lot is honesty. You actually do what you claim you do in the value. The second one is, like, applicability. Like, you have to have values that you can actually, like, figure out how to apply to, to your work. And so one of Stripe's values was, um, n- no longer a value, I, I believe, but it's, like, optimize globally. And so optimize globally is a really interesting problem 'cause sometimes you'll have something you want to d- or, uh, interesting value. Sometimes you wanna do something and you're like, "Hey, I want to introduce a new programming language 'cause that's better for my team," but, like, for the organization overall, this is actually much worse for the organization so I'm not gonna do it. Uber didn't have this as a written value, but implicitly Uber's, Uber's value was do what's good for your team and ignore everyone else because that will slow us down. And so the two different companies had opposite values, but they're both very applicable. It's like how should we navigate decisions? Should I optimize for my team or for the organization? And then... So those are applicable to real problems and they were honest. Where Uber was just like don't worry about other people. Like, make it work for your team. And that's how they moved so fast 'cause they just didn't worry.

    3. LRLenny Rachitsky58:32

       Wasn't there a value of no... of toe-stepping, encouraging toe-stepping or something like that?

    4. WLWill Larson58:36

       Let builders build, uh, toe-stepping. There, there were a number of values that, that could be interpreted in different ways and, and sometimes they got weaponized (laughs) in various ways as, as, as all values do. But, but these, these are both interesting in different ways. And so number one is honest and then two is applicable. Um, three is I, I think the last thing for a good value is this idea of reversibility.

    5. LRLenny Rachitsky58:59

       Mm-hmm.

    6. WLWill Larson58:59

       So there's some values that aren't actually, like, usable. And so here's a good example on... We build good software. Like, okay, but, like, why would you ever not build good software? Like, that, that doesn't, that doesn't make sense. Or, um, we solve customer problems that matter. Like, good. What, who would ever say they're c- like, what, what company doesn't think they're solving customer problems that, that matter? And so there, there's certain, like, values that just you can't apply. And so, like, I think of these as, like, identity values. Like, these are really just you describing, like, who you want to be or, like, we care about our customers. Like, g- great, but, like, who would say they don't care about that? There are just, like... There are certain values that I think of it just, like, identity values and, and they're not, like, they're not wrong to have identity values, they just aren't very useful. You can't actually use them for anything. And so I just always push people not to spend too much time on these 'cause they, they feel good when, when you're an executive team kind of debating like what are these identity values. It's like we're, we're kind to other people or, like, you know, sure, that, that sounds good. Like, we're a family. Like, sure, that, that sounds good. Um, that one I guess is a little bit reversible 'cause, you know, there's Netflix which is like we're a team, like a sports team, we're, we're not a family. And so-

    7. LRLenny Rachitsky1:00:17

       Definitely.

    8. WLWill Larson1:00:17

       ... a little bit reversible but, but not perfectly. But yeah, th- these are the three that I found really useful for any value. Like is it honest, is it applicable, and can you reverse it? And if not, it's probably actually not helping the team make decisions.

    9. LRLenny Rachitsky1:00:30

       These are great. It reminds me a lot of... I was there during Airbnb's period of coming up with values. Something that I would maybe add that maybe fits into one of these buckets is it needs to be clear who doesn't. Like, there needs to be a group that doesn't quite fit because if everyone fits, then some- you're not doing anything useful. What's the point? Which feels weird to say, like, right? Why would not, not everyone fit in our big group of awesome company? But it's clear, like, who is not a good fit, who doesn't belong basically. It's kind of like a cult a little bit. Like, who's not in our cult? Who doesn't belong?

    10. WLWill Larson1:00:59

        But I agree. Like if, if, if it doesn't apply to anyone, then, like, why bother saying it? It's like... It doesn't, it doesn't mean anything. And you could say it's actually like a hiring filter where there are people who you've explicitly chosen not to hire 'cause this wouldn't apply to them. Then I think it's useful 'cause it helps you actually, like, figure out who to, who to, like, bring in.... but if it doesn't apply to anyone you're hiring or anyone that you have in the company, then it just sort of like isn't worth having 'cause you already have too many values. You're, you're already trying to get rid of values 'cause you have like 17 and you need to get down to like four, where people can remember them. So if it doesn't apply to anyone, like why, why bother having it at all?

    11. LRLenny Rachitsky1:01:32

        Yeah. Like integrity is a common one. Integrity. Like everyone has that. Nobody wouldn't want integrity. Like what does unique-

    12. WLWill Larson1:01:37

        Yeah.

    13. LRLenny Rachitsky1:01:37

        ... especially-

    14. WLWill Larson1:01:38

        We're the non-integrity company. Like we-

    15. LRLenny Rachitsky1:01:40

        Yeah. Exactly.

    16. WLWill Larson1:01:40

        ... we're the company that like thinks integrity is bad. Like that, I thought, "That's like not a real thing."

    17. LRLenny Rachitsky1:01:44

        (laughs) The other one I'll s- I'll add too is, uh, honest. So at Airbnb we had six values initially. One of them was simplify. And a year or two later everyone just realized, "We're not actually good at this. We want to simplify, but we're not great at this skill." And value should describe who you are, not who you want to be and aspire to be. So they cut two values, including that one, and they're just like let's just do these four 'cause this is actually who we are. Let's be honest with

17. 1:02:10 – 1:11:05

    Failure corner: the Digg rewrite

    1. LRLenny Rachitsky1:02:10

       ourselves. Okay. Final question. I wanted to visit, uh, failure corner, something that I've added recently to this podcast where people share a story of failure. And you have this amazing post about your, uh, experience with Digg and the rewrite that you all went through. I think it was the version four of Digg. Can you just tell that story and what happened and how much of a mess it ended up being?

    2. WLWill Larson1:02:33

       Yeah. Digg V4 is, is, uh, I mean, still, still something I have a lot of like fond memories for. There, there's, uh, one picture that I, that I've kept. It's a picture of a lot of the engineers around this table in the middle of this giant office, and they're like serving like sushi. We had like waiters, caterers come in that day. They were serving like sushi. There, we had like, uh, you know, plates with like champagne flutes on it. There was a full bar. They were all around this table 'cause the site's not up. And so Digg V4, uh, essentially what Kevin Rose or, or the board, or some combination there realized is that Digg was losing, was losing to the social networks, and that this idea of kind of aggregated news was gonna be out-competed by the Twitters, the Facebooks, et cetera if we didn't find a way to move to have a social component for it. Even out-competed by Reddit long term was kind of the, the fear, although at the time that, that was far from, from obvious. And so we needed to move to support kind of social functionality. In the previous version we simply couldn't get it to work. And so the decision that was done, like two and a half years before I joined, um, and, and this, this shipped about six months after I joined, was they needed to do a complete rewrite in order to get there. This is a decision that never works out for anyone, um, and so I think like, uh, as someone who's more experienced I could've predicted this wasn't gonna work out. But I was early in my career. My, my PM counterpart at, um, Yahoo, Josh Gopinath, he, he went to, to Yahoo and he's like, "Come to Digg. Uh, worst case you'll make couple 100,000 in a year. Worst case, uh, probably really great outcome." Anyway, that, that's not what happened. The worst case was a little bit optimistic. Um, but, but so we go and, you know, the, the CEO got fired, um, two days before I joined, so, uh, the current CEO left and then Kevin Rose came back for, for about six, six months, something like that. And we're just on this death march trying to get this thing out. And so we, we pushed really hard. This is before the cloud for the most part, so we, we wiped all of our, pretty much all of our existing servers to re-image them to the new, the new software, and we tried to bring the site up, it just keeps crashing. And so it basically takes us a month to get it fully functional again. And so that, that day sitting around that table with like champagne and, and sushi, that, that's just like day one. And, and by, you know, 30 days in most people aren't even trying to get the site back up anymore. There, there's maybe like five of us who are still trying. And, and, you know, we did. And, and I think like that, that was like a really powerful moment for, for me. And I think in the first two days, like, uh, myself and, and Rich Schumacher, like one of the other engineers, we, we had to write like a, a caching system from scratch, which got, got us like half the way up. Really a terrible way to do software on a side note. Like, I'm not recommending this to anyone. This was like a, a series of anti-patterns, um, kludged into like a, a launch. But we, we got it partially up, but we had to restart it every 12 months, basically every server... Sorry, every 12, 12 hours every server had to be restarted even with the caching mechanism. And then, um, you know, about three weeks after that, like I finally figured out what the, the core bug was that was bringing us down every 12 hours, and it was this incredibly simple issue that had just been hard to debug basically related to the way that Python initiates variables used as default parameters. And it's sort- something like super, super silly, um, and we just had someone who hadn't written Python before who was working on the, the API code, so he didn't realize this. Gotcha. Then no one else caught it when, when it was reviewed and, and it just took a long time to debug 'cause it was like such a non-obvious... It didn't break anything. It was just doing a lot of extra, extra load on, on the servers. And, and we finally, we finally figured it out. And, and it was just really remarkable experience pulling through. And, and you know what? The company still, still went to zero. (laughs) And so we, we had this bad launch. Think we did this heroic, heroic stretch to get it working. A couple weeks after that, like a new CEO came in, did a round of layoffs. This is back in I think like 20, 2012. The team, um, nine months after I started was down to like 30 people from about 100. And it just went, it went downhill from there, um, from a, from a business perspective. But we launched a lot of functionality, as really learned just a tremendous amount, and, and it kind of shaped like what I think about in terms of early in your career getting learning, and going into a company that is maybe having a rough time. Like I, I became a manager like two and a half years into my career-... three, basically running the entire engineering team there, 'cause everyone who had a lick of sense quit or got laid off. And it was just like complete idiot me like trying to like be the manager for, for the engineering org and wasn't qualified and no one would have given me that job, but I was the only one dumb enough to take it at that point. And, and I learned so much and I really like... That, that's like the, the kernel that like turned into like my entire career was, was that opportunity, even though at the time it was, uh, it was pretty, pretty grim.

    3. LRLenny Rachitsky1:07:49

       That's an amazing story. I feel like a lot of these experiences where in the moment it's just like, "What is going on? This is so bad and hard," end up being the most interesting in looking back, end up being the most biggest teaching experiences, the ones you like bond over with people you work with. Like Apple, uh, always comes to mind where it's just like Steve Jobs would joke with people like crazy and then they look back and that was, that was the best part, moment of my career.

    4. WLWill Larson1:08:12

       You would never like voluntarily take on a lot of these really challenging things, but sometimes like when they show up, like you're with a group of people you really respect, you, you love working with, and you like wanna overcome together and that- that's like, that's really powerful experience. Even if... Uh, Uber China was similar where like if someone had been like, "Hey, do you want to go work on this Uber China migration?" I would have been like, "Absolutely not." But like no one asked. They were just like, "Get this done." And so, so we did. And, and I think the- these things are like pretty, pretty remarkable.

    5. LRLenny Rachitsky1:08:39

       And just to be clear, so Digg was down for a month basically during this period? Is that...

    6. WLWill Larson1:08:43

       So i- it basically didn't work properly for, for much of the month. It, um, it was, it was like read-only was back up in like about three days, but the vast majority of the actual like user functionality just wasn't working properly for, for pretty much an entire month. And it was, um, uh, not, not that good. I mean, like not, not great. Um, but, you know, that wasn't the biggest problem, uh, Digg had at that point. But it was one of the biggest problems it had at that point and, and it wasn't, it wasn't a real sign of, uh, of things likely to go well for us. But, you know, like I said, you, you learn from those and I'm really proud that like Digg and the team like got it working, got it, got it running, even if like ultimately like we still went to zero and like ran out of money and kinda sold, uh, sold for parts.

    7. LRLenny Rachitsky1:09:32

       Do you think Digg could have made it? There is a world where Digg would have been a hugely successful business or do you think it's just way too late and it was the wrong product?

    8. WLWill Larson1:09:39

       The thing that really killed Digg is the, the change... It was an SEO-driven, like... So monetization was from ads. Digg was the f-... Well, many companies, including Digg, claimed that it was the first, uh, in kind of stream, in feed like advertising company, like where Twitter has like ads within like the tweets or Facebook does. But, but Digg did that before Facebook or Twitter really innovated kind of the ad format. Um, but the vast majority of our monetization was on these like we called them permalink pages which is page 40, then like article we crawled. And the vast majority of traffic for that was driven by Google search. And so there was an SEO change which really is like the, the thing that started creating the urgency for us to launch this migration. SEO change, traffic started going down, monetization was driven by that. And so we, we, we were already on fire by the time we tried to launch this, but I, I do think that I still want something like what Digg was trying to become today. Social news based on like what my friends are actually reading and liking, merged with like a global index of kind of similar users who are interested in similar topics. So it's still a product that I think Google Reader had, has some kind of similar components to it. These were both interesting products solving interesting problems that have not, for whatever reason, been successful as businesses and I do think there's a gap there still, but there's a lot of people trying unsuccessfully to fill it and, and there must be a reason why people struggle to fill it despite so many people trying.

18. 1:11:05 – 1:12:04

    Will’s upcoming book, The Engineering Executive’s Primer

    1. WLWill Larson1:11:05

    2. LRLenny Rachitsky1:11:06

       Awesome. Will, is there anything else you wanna share or leave people with before we get to our very fast lightning round? 'Cause I know you have to run in about five minutes.

    3. WLWill Larson1:11:15

       Uh, I think we've covered a lot of it. Uh, new, new book coming out, new book coming out in February. Uh, Engineering Executives Primer, O'Reilly, but that, that's probably it.

Episode duration: 1:16:53