I want to take a moment at the beginning of this episode to thank everyone who listens to this show. Sincerely, we just recently reached 700 episodes this past week, and it's been such a wonderful experience to create this podcast for 4 and a half years now, and we have no plans of stopping, because the purpose of this show is inspiring every single day for me. And I just wanted to take a moment for thanking you for making this possible. But I also want to thank all of the wonderful guests, including today's guest, Will Larson. Will is an engineering manager at Stripe, and he recently published a book through Stripe Press called An Elegent Puzzle. This book is chock full of fantastic information, lots of practical resources and guiding kind of principles for engineering managers. So I encourage you to pick up that book if you're interested in the subject. My name is Jonathan Cutrell, I'm listening to developer TMI Goal on this show, and it's helped driven developers find clarity, perspective, and purpose in their careers. And I believe Will has similar goals in his day job and as an author, and as a guest on this show. Let's get straight into the interview with Will Larson. Will, welcome to the show. Thank you so much for having me. I'm very excited to talk to you, not only because of your experience at Stripe, but also because you just recently released a book, and I believe that this book is really going to kind of go into the classics pretty quickly for software engineer managers. And it loves to talk to you about the book, but first I want to ask you about the title of the book. The title is an elegant puzzle. Can you kind of explain where this title came from? So, so titling books is kind of an interesting process where you kind of basically the working title for a long time was kind of this like systems of entering management or engineering management systems. I knew systems was an important part and it's a book about entering management. So maybe we should acknowledge that. But really, really kind of knew it was a bad working title, but it wasn't quite sure what to talk about. So as we were starting to write up the promotional materials around it, like what did we want to tell people about when we talked about the book. One of the things that really came out was this idea that entering management really is about solving these interesting puzzles and kind of figuring out these interesting patterns and how to use these patterns to solve the day-to-day problems that we run into. And kind of as we started riffing on that idea, we someone actually just pulled it out this phrase out of this longer thing I had written kind of about promoting the book. And it's like why don't we just call it this. And it really stuck. I think it was one of those moments where we were just like this is what we've been missing. This is like this awesome thing. And it was just so much better than kind of the previous titles that we've been thinking about that we just kind of pivoted and went with it from there. And it's the title along with the cover are seemingly like you wouldn't imagine those are the most important parts of a book. But really when I think about what makes me so happy about the book, I think that the cover image and the title are really right up there. I agree. I have a copy of the book. And the kind of the texture of it and the weight of it, really the whole kind of the quality, the feel of the cover. Of course, you're not supposed to judge a book by its cover. But this one has a pretty good, I'm pretty good face, you know, that initial impression. And it should be, it should be noted that this was published through Stripe and that's where you work every day as an engineering manager. Is that correct? Yeah. So that this was the, I think the fourth or fifth Stripe press book and it was the first one to be written by a Stripe. So it was pretty exciting both to be the fifth book. This awesome kind of new publisher, but also to get the opportunity, the first Stripe to write one was pretty special as well. And when you say the first Stripe, you mean the first person who that's the internal noun for someone who works at Stripe, right? Yeah, exactly that. Cool. And the book is full of this very practical knowledge and I wrote down a note here before I forgot. This book really reminds me quite a bit of the personal NBA, I don't know if you've read it. It's by Josh Kaufman, excellent book and it does a very similar thing. It goes through and provides you some very practical knowledge about very specific things. But then it does, you do this thing where you kind of zoom back and you say, okay, I'm giving you kind of the practical knowledge, but there's a lot more here. There's a lot more that you can dive into, a lot more discussion to be had and here's the references. And the back of the book, you just have this huge glossary and index of references. And so I wanted to talk to you about that for a moment. Have you actually read all of this stuff? That's an amazing amount of material. Number one, and number two, for people who are interested in kind of learning these kinds of systems, do you have maybe a list, a top three of things that you would recommend for people to read once they've already, of course, once they've read your book, right? What are the next two or three books that you would recommend for someone who's interested in a career as an engineering manager? So I once, you know, a while ago got scolded for bringing up books that I had read too frequently. It was, you know, this book kind of raises this important point about something we're discussing now. And I think the CEO at the time was not amused, like stop bringing up books. We don't need that sort of stuff around here. So yeah, I actually have read all of those books, all of those papers. And really, I mean, for me, like reading has been like a lifelong passion and writing as well. But yeah, so much of what I've learned and so much of what I think many managers learn is from reading these books. If you're at a small company, there might be one other engineering manager. There might be no other engineering managers. Where do you go to kind of learn about the practice? And I really think these books that the handful I've selected and the kind of appendices, I think are ones I've really loved. But I think the ability to learn when like the specific environment you're in is not rich with experience is I think just this special property of kind of books and written material. The number one book I recommend to everyone that I talk to is I think thinking in systems of primer by Don Elamedos. It's just so, so good. It's just like an entire new way to think that I've really just found powerful. Another one I would think kind of a classic, but I think people wear is a, I think, Demarco and Lister is another kind of kind of seminal work. But just such a powerful thoughtfulness that has really just transformed, I think, so many managers. It's like the only book they've ever read about engineering management and it has a really special place in my heart as a result. And then another more recent one that I've really thought really highly of is just accelerate and that's by Nicole Forrest-Gran, I think Jean Kim and there is a third author who's I'm slipping from my head. But just again, a great data-driven look at how management and practices actually work. Those might be my three top ones to start with. Yeah, I've read people wear and I've read summary of the thinking and systems. I have not actually dove in and read the book, it's sitting on my shelf. Of course, I have way more books than I have actually read because that's just a bad habit of mine, I suppose. I find a book and I follow the rule that if there's ever a book that I'm considering buying, go ahead and buy it. It's probably not a bad investment, right? We have a fixed size bookshelf that my wife and I have to one book in, one book out. We've fought that because otherwise we would have literally nowhere to put things. We do not have such a rule in my house. Whatever flat surfaces are available, there may be a book on that flat surface at any even point in time. I think as a moment of advice for people who are like, man, I really wish that I could read as much as these people read. One of the things that was really liberating for me and maybe you have a similar experience that you can share was the idea that you don't have to read every last page of a book for that book to be valuable to you. Number one, and number two, you also don't have to put a book down forever. You can go back and read it in different portions, especially with management books. You can open up a book and it doesn't have to be read like a narrative. We were taught to read in grade school. You can use this book more like a reference, a source that you can jump through, jump around, pick up and drop different places that you want to pick up and drop. I think that was really liberating for me where before I felt like the only way that I can truly say that I've read a book is if I've devoured every single word in the book. But I think everybody has different styles. How do you have you found that you've found a similar approach to reading or do you read every single book and the introduction and the table of contents? I think what you just said resonates a lot with me. I think one of the challenges we're typically brought up as readers, as readers of fiction, and that's kind of the first thing we start reading. And fiction is not that much fun if you skip around. Fiction is not that much fun if you skip parts, you miss the plot. There's beauty in the description. I personally would know whatever told me when you're reading this other source of stuff, you just skip to the content. That is exactly as you said, something I've learned over the last five or six years was, for books I don't really like when I want the ideas, just skip to the ideas. It's usually pretty easy to find them. These books are pretty structured. And yeah, there's a lot of books now that I have read that I have really skimmed through, finding the nuggets. And 10 years ago, I had never even imagined that. But I think there's a book called Akada Reader Book or something, which I've been told is quite useful for learning how to do this. Yeah, it's really important to be able to do this. I mean, use whatever resources are available. If you get 10% of the value out of a book, that's better than 0%. And I think that's something that a lot of people, they never pick up a book because they feel like it's this daunting task to actually get through it. But there's so many ways to get value out of that. And just building on that real quickly, one of the realities of the publishing businesses and one of the reasons that I really love Stripe Press is that most other publishers have like target lengths where you need the book to be like 250, 300 pages. And then you fill it. You get the metric, right? But it doesn't necessarily translate to like a great book or a really readable book. And so I think even the authors aren't necessarily putting out the books they want to. And one of the things I really appreciated about my book is that I felt initially like it was a little bit short. I think it's 250 pages approximately. And I felt a little bit short when I held it. But like, no, this is fine. Like, if these are the ideas, and this is the amount of space you need, let's do that. And that was something really special as well. Yeah, I think your book specifically is another one of those books that it's not a book that you read to get all the ideas and then put down and put it in the archive. And this book is much more like an index of information and various systems, various kind of structures, ways of thinking that can be reused as kind of like templates or models in the future. And I don't see it as, you know, the same kind of thing as reading through, you know, a psychology or self-help book. It's much more... It's more like, and this is going to sound wrong at first. But it's more like a recipe book in the sense that, you know, you can reuse these pieces of content. And it's not something that you're going to hold in your mind per se. But it is something that is seated well in kind of research. Other people's research, your own experiential, like your path as an engineering manager at Stripe. And so, yeah, I don't see myself taking this book and saying, okay, yes, I have devoured the contents of this book and now I can move on. It's much more of a, you know, this is going to sit on the shelf as a reference. Something you said earlier is like when you're talking about it being similar to the personal MBA is I think really what you said just now kind of resonates, which is, there's a recipe. And this recipe is basically going to work for you most of the time. It's not perfect, it's not like the tastiest riorg you've ever eaten, but it's like, it's a passable riorg. But then, like, then kind of segwaying, it's like, it hears the way to think about this as well. And I think, you know, sometimes, sometimes you want the kind of the thinking and the approach behind this and like all the details. Sometimes you just need like a recipe to like run. And I think trying to give both, as always, a goal for me, kind of the different things that I write on my blog and also on this book. Yeah, I totally agree with that approach. I think it's important to understand kind of the system or the systematic way of arriving at a particular output. And then also saying, here is an output, right? It's kind of the both sides of that of the system, not just, you know, theoretically, this is what we should do. But also, here is an expression of how that would play out. Cool. So I'd love to ask you on that point, you know, a lot of these systems that you lay out, their explicit systems and their explicit, like even numbers, right? So for example, one of the things that you mentioned in the book is, you know, team sizing. And you know, this is kind of a fundamental concept when you're building and engineering organization. The size of the team and how many people a given person can manage. And all this is certainly from some of your experience, but I'd love to know, you know, what ratio would you say this is your experience versus this is kind of theoretically or at least, you know, backed by some kind of research, this is the way that you should go. How much would you say you've kind of had in your career versus what you believe based on, you know, some given research? There's not a ton of research on these topics and that's one of the reasons why I think accelerate is such a great book because it actually is research driven, but also people wear and slack are older books that had some research component in them as well. And I think that is part of the reason like these three books like resonate with me so much for my writing, I think it's generally been my experience that it's hard to find kind of conclusive information about like what size team should you have, but you do have I think in these fast growing companies and when I was at Uber was growing, you know, 400% year over year, when I was there for about a little bit over two years and I grew from 200 to 2,000 engineers in that period. And one of the really neat things about this hyper growth is that it's kind of this like petri dish of org experimentation. We get to see like so many different versions of so many different things. And then one of the things I've loved about coming to Stripe and being here the past three years is that it's growing quickly, but it's growing a little bit more slowly where I get to kind of recreate these different organizational experiments, but more meticulously and more thoughtfully. And I know kind of what's coming down the pipe. So both kind of working at these like fast growing companies, but then also reaching out across the industry to kind of folks and understanding how they work at their other companies, it calls like benchmarking, but just kind of understanding how do you like 10 similar companies like approach the same problem. I use this a lot for kind of as a general problem, solvent technique, but also specifically in this case, this is something I spoke with a bunch of folks, different companies as well. I unfortunately don't think there's a whole lot of great data about kind of this, but on the other hand, I think arithmetic is really powerful in these cases. And I think Andy Grove was talking about how to size, how he sizes teams and I think he comes to eight or might have come to five, but it has just like some very simple kind of rule of thumb, which is like you spend half a day per person. So you can't have more than 10. It was basically how he did it. And I think these like rules of thumbs based on observing like the actual kind of constraints of your time tend to be surprisingly powerful, even though initially they seem too simple. I've seen them outperform kind of any other approach that I've seen so far. Yeah, that makes total sense. I think sometimes we try to complicate these things and it's easy to think that our particular system is going to work just because we saw it work elsewhere. But sometimes we just need to look at kind of the size of the box, right? You can do your own kind of principles based understanding of the situation that you're in and derive some of the answers for yourself. And I think the book is really good at explaining that. And a lot of the topics that you cover are, you know, it's like, oh yeah, well of course, it's that way. And not like, of course, it's that way and we all talk about it. But more like, of course, it's that way. Why didn't why don't we talk about it more in this in this frame? Something I have like a kind of a stint a year or two ago about kind of reality based decision making, which is kind of this like thing I thought about kind of constantly, which is that it's strange to to your point. There's all these things we know are true that we don't act on. And I think the most obvious example is like the kind of open office floor plan. There's a lot of research showing that this is not in fact like a good way to make productive teams. But we keep perpetuating it and we keep explaining it with the same explanations, you know, like more collaboration, more communication, even as the data comes in kind of disproving it. We still we still keep focusing on it. A book that I read recently, which is not a technical book, but I read the two income trap by Elizabeth Warren and her daughter and they do a lot of work around research about kind of explanations for certain types of kind of financial hardship and kind of like how the narratives that we hear in kind of like written articles and then the actual science refuting those narratives. And I think what was so powerful about her book was just how much many of these narratives are things that I believe to historically and then seeing the data disproving them. And I think it's it's both powerful to know that you are wrong about a lot of your beliefs. Like a lot of your beliefs are actually not grounded. They just are reasonable and so they trick you with their reasonableness. But then there's other things that we actually do know and then just don't act on. And thinking about that I think is really important as we try to make these decisions that like impact kind of the lives that everyone we work with. Yeah, I heard a very interesting discussion on a similar topic recently. I think it was on Hidden Brain, the podcast Hidden Brain by NPR. And they talked about or it may have been on Freakonomics, one of the other. They talked about the difference in the way that humans and dogs domesticated dogs interact with our environment in the specific difference that they pointed out. Of course, there's a lot. The one they pointed out was that humans are very much so kind of copycats. And we imitate each other and we imitate what someone tells us to do. We're likely to kind of listen to them and we're likely to do things the way that we see other successful people doing them. And so it absolutely makes sense that we would have a reality around us that we ignore right on the one hand and then on the other hand, we're willing to take this kind of conventional wisdom or these narratives that we've heard over and over and over and assume that they're representative of some reality. And it's kind of this double-edged sword where we aren't really observing the reality around us. And on the other hand, we are also accepting some false reality and this can perpetuate into really bad decisions. What you said about sense-making or about reasonableness, fooling us, this is really critical for especially I think managers to understand because a lot of our retrospective practices, we can look at what went wrong. Well if we can explain what went wrong, then that explanation as long as it seems like it falls together and all the pieces of the puzzle fit, we're apt to believe it. And even if the explanation is actually, well, some set of random events occurred that we can't really explain and that's why we're apt where we are, that may be the real explanation but we're not very apt to believe that one. We're much more apt to believe the one that supposedly makes more sense. So one of the things I've learned the most about over the last year is incident programs. So these programs where you have incident and state company, you kind of remediate the incident and you write up like an after-action report or like a root cause analysis or whatnot and then you kind of review them and some sort of group together. And I think I really learned a lot from some of my co-workers, Talina and Daven in particular who have been just open my eyes to how these work. But how I used to think these worked was that you brought in a report, you talked to people about it and helped them improve kind of the quality of their analysis and maybe the quality of their medias and you were done. But what I've learned from working with them is that the most important thing these incident programs do is they create pristine data about what's actually happening and it's this metadata which then allows you to see trends that you can actually believe in and then it's the discussion of these trends and the metadata and you start solving the trends not just solving the incidents. It allows you to actually have the data you need to actually have that right conversation versus kind of the immediate conversation reacting to any given one which I never even realized was the goal of these programs until fairly recently. That would be an invaluable tool set for Developer To have and developers, engineers, managers. All of us are doing this kind of evaluation and this is a applicable outside of engineering of course. Anybody who is doing work and trying to improve on it, trying to iterate on it and kind of improve their working processes makes total sense to be able to evaluate trends rather than one of the things kind of an anti-pattern in engineering management is the idea that a given incident is representative of some larger reality. The trouble is that humans are much better at remembering individual incidents especially if there's something extraordinary about that incident. It's easy for a single failure to stick out above all of your successes. So this visibility of a particular moment in time can be really a bad metric to use. Well it is a bad metric to use to evaluate somebody's overall performance certainly but it's also kind of the easiest one. We use these signals as our brains are able to process the world. We don't really process it in total. We process it one piece at a time and we try to take the most salient pieces and that just so happens that the more extraordinary ones are the ones that we're likely to take. Absolutely. I think it's flame graphs for debugging and performance and production. If you take any one slice you don't necessarily get something good but as you take many different slices they still start coming together. You get an accurate sense of what's actually happening. If you only take a couple samples then it's almost always going to focus on kind of fixing the wrong problem and being really careful to be looking at the distribution not just the singular event is one of the most important things that I have done to improve the quality of my thinking and decision-making. So we allow these extraordinary events to act as landmarks for our evaluation of what our direct reports have done even what we have done. We can look back and see the moments of failure very easily but sometimes we don't see those consistent moments of success. I think something interesting here is there's kind of two different scenarios that are interesting to think about for how you handle outliers. One of them is the sort of thing you're talking about like a failure and how we think about how do we avoid over indexing on the rare failure. Then conversely when we think about process we actually want process when we design a promotion process or we design a hiring process. We actually want those processes to handle all the exceptions in a really intentional way. Maybe make those exceptions not be exceptions but actually handle them in the norms of the process. I think getting better at making decisions of all of these different varieties is definitely one of the hardest parts as being a leader of any sort and kind of improving your toolkit. When do I need a distribution? What does significance actually mean? How many data points do I need to actually understand if this is improving or getting worse? That kind of fundamental is of your statistics. Then thinking about how with process it's not about statistics it's about every single case getting handled thoughtfully. All of these pieces are really interesting pieces of the toolkit that you have to bring to it. Yeah, I don't think a good prescription would be to just ignore those exceptions. I think that finding that proper balance is incredibly important and process is a way to enforce a balance there. Good process, I think I was talking to someone recently about good process and one of the things that makes good process good is the consistency of application. One of the things that makes good process or bad process bad is the needless urge to force everyone with the same exact system and ignoring the circumstances. I really do think there's dealing with exceptions is core leadership skill and dealing with exceptions as you design process and figuring out how do you find it's sort of like architecting software. How do you find the common patterns and how do you make them extensible to kind of handle what reality brings you? It is a really powerful topic to think about particularly when you think how do you also make this a fairer and kind of just system, not just one that kind of gives the results that people wanted to have all the time. Thank you so much to Will Larson for joining me on today's episode of Developer Tea. If you don't want to miss out on the next two parts, this is a three part interview with Will. We had so much ground to cover. If you don't want to miss out on those two parts and encourage you to subscribe and whatever pie casting app you're currently using. And here's why I think you should subscribe. You hear all the time that if you put your investments, your savings on an automated schedule, you're much more likely to save more than if you were to try to remember to do that yourself. The show isn't necessarily a financial investment in your career, but I do believe that Developertate other shows on the spec network and the other wonderful podcasts that are in the kind of developer podcast ecosystem that those are investments into your career. Subscribing doesn't mean that you have to listen to every episode and in fact I encourage you to pick the ones that you think are most relevant and spend your time with this podcast strategically. But I do believe that spending regular time thinking about these subjects is important to every developer's career. By the way, we wouldn't be able to make this podcast happen without spec. Click is a content network that is built specifically for designers and developers who want to level up in their careers, go and check it out, spec.fm. Thank you to today's producer, Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.