Vox

Leitura de 36 min

Part 1: An Elegant Puzzle Book Discussion w/ Will Larson

Summary

In this episode of Developer Tea, host Jonathan Cottrell interviews Will Larson, engineering manager at Stripe and author of ‘An Elegant Puzzle’. The conversation begins with the origin of the book’s title, which emerged from promotional materials describing engineering management as solving interesting puzzles and patterns. Larson explains how the book evolved from a working title about engineering management systems to its final evocative name.

Larson discusses the book’s structure and approach, comparing it to Josh Kaufman’s ‘Personal MBA’ in its practical, reference-style format. He emphasizes that the book provides both recipes for common management situations and the underlying thinking behind them. The conversation explores how to read management books effectively, with both participants agreeing that skimming for key ideas and using books as references rather than reading every word cover-to-cover can be more valuable.

They delve into specific management topics including team sizing, where Larson explains that while there’s limited research on optimal team sizes, he uses benchmarking across companies and simple arithmetic based on time constraints. The discussion touches on reality-based decision making and how managers often ignore data in favor of conventional wisdom, using open office plans as an example where research contradicts common practice.

Larson shares insights about incident management programs, highlighting how they create valuable metadata that reveals trends rather than just addressing individual incidents. He emphasizes the importance of looking at distributions rather than singular events when evaluating performance or making decisions. The conversation concludes with thoughts on designing processes that handle exceptions thoughtfully while maintaining fairness and consistency.

Recommendations

Books

  • An Elegant Puzzle — Will Larson’s book on engineering management systems, described as providing practical recipes and underlying thinking for solving management problems.
  • Thinking in Systems: A Primer — By Donella Meadows, recommended as the number one book for managers to develop new ways of thinking about systems.
  • Peopleware — By DeMarco and Lister, described as a seminal work that has transformed many managers’ approaches to engineering management.
  • Accelerate — By Nicole Forsgren, Jez Humble, and Gene Kim, praised as a data-driven look at how management practices actually work.
  • The Personal MBA — By Josh Kaufman, mentioned as having a similar practical, reference-style approach to Larson’s book.
  • The Two-Income Trap — By Elizabeth Warren and her daughter, referenced as an example of research disproving common narratives about financial hardship.

People

  • Andy Grove — Referenced for his approach to team sizing using simple arithmetic about how much time managers can spend per team member.
  • Talina and Davin — Will Larson’s coworkers who helped him understand how incident management programs create valuable metadata for identifying trends.

Podcasts

  • Hidden Brain — NPR podcast mentioned in discussion about how humans imitate each other and accept conventional wisdom.
  • Freakonomics — Podcast referenced in discussion about human behavior and acceptance of narratives.

Topic Timeline

  • 00:00:00 — Introduction and gratitude for reaching 700 episodes — Jonathan Cottrell expresses gratitude to listeners for reaching 700 episodes and introduces guest Will Larson, an engineering manager at Stripe who recently published ‘An Elegant Puzzle’ through Stripe Press. He describes the book as full of practical resources and guiding principles for engineering managers.
  • 00:01:59 — Origin of the book title ‘An Elegant Puzzle’ — Will Larson explains how the book’s title emerged from promotional materials describing engineering management as solving interesting puzzles and patterns. The working title was initially ‘Systems of Engineering Management’, but the team realized ‘An Elegant Puzzle’ better captured the essence of the book’s approach to management problems.
  • 00:04:43 — Book structure and comparison to ‘Personal MBA’ — Jonathan compares Larson’s book to Josh Kaufman’s ‘Personal MBA’ in its practical, reference-style format. Larson explains that the book provides both recipes for common management situations and the underlying thinking behind them, allowing readers to either follow templates or understand the systems approach.
  • 00:05:55 — Recommended books for engineering managers — Larson recommends three key books for engineering managers: ‘Thinking in Systems: A Primer’ by Donella Meadows, ‘Peopleware’ by DeMarco and Lister, and ‘Accelerate’ by Nicole Forsgren, Jez Humble, and Gene Kim. He emphasizes the importance of reading for managers who may not have experienced colleagues to learn from.
  • 00:09:13 — Approaches to reading management books — The discussion explores how to read management books effectively, with both participants agreeing that skimming for key ideas and using books as references rather than reading every word cover-to-cover can be more valuable. Larson notes that unlike fiction, management books don’t require linear reading to extract value.
  • 00:15:12 — Team sizing and management ratios — Larson discusses team sizing principles, explaining that while there’s limited research on optimal team sizes, he uses benchmarking across companies and simple arithmetic based on time constraints. He references Andy Grove’s approach of calculating how much time managers can spend per team member to determine appropriate spans of control.
  • 00:19:26 — Reality-based decision making and conventional wisdom — The conversation explores how managers often ignore data in favor of conventional wisdom, using open office plans as an example where research contradicts common practice. Larson references Elizabeth Warren’s ‘The Two-Income Trap’ to illustrate how narratives can persist despite contradictory evidence.
  • 00:23:04 — Incident management programs and trend analysis — Larson shares insights about incident management programs, highlighting how they create valuable metadata that reveals trends rather than just addressing individual incidents. He explains that the most important function of these programs is generating data that allows organizations to identify and solve systemic issues rather than reacting to single events.
  • 00:27:05 — Handling exceptions in management processes — The discussion covers how to handle exceptions in management processes, comparing it to software architecture where you design for common patterns while making systems extensible to handle reality’s variations. Larson emphasizes that dealing with exceptions thoughtfully while maintaining fairness is a core leadership skill.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-07-05T09:00:00Z
  • Duration: 00:31:03

References

Podcast Info

Transcript

[00:00:00] I want to take a moment at the beginning of this episode to thank everyone who listens to this show

[00:00:08] sincerely. We just recently reached 700 episodes this past week and it’s been such a wonderful

[00:00:17] experience to create this podcast for four and a half years now and we have no plans of stopping

[00:00:22] because the purpose of this show is inspiring every single day for me and I just wanted to

[00:00:29] take a moment for thanking you for making this possible. But I also want to thank all of the

[00:00:34] wonderful guests including today’s guest Will Larson. Will is an engineering manager at Stripe

[00:00:41] and he recently published a book through Stripe Press called An Elegant Puzzle. This book is

[00:00:49] chock full of fantastic information, lots of practical resources and guiding kind of principles

[00:00:56] for engineering managers. So I encourage you to check it out.

[00:00:59] I encourage you to pick up that book if you’re interested in the subject. My name is Jonathan

[00:01:04] Cottrell. You’re listening to Developer Tea and my goal on this show is to help driven developers

[00:01:08] find clarity, perspective and purpose in their careers. And I believe Will has similar goals

[00:01:14] in his day job and as an author and as a guest on the show. Let’s get straight into the interview

[00:01:21] with Will Larson. Will, welcome to the show. Thank you so much for having me. I’m very excited to

[00:01:29] talk to you not only because of your experience at Stripe but also because you just recently

[00:01:37] released a book and I believe that this book is really going to kind of go into the into the

[00:01:45] classics pretty quickly for software engineer managers. And I’d love to talk to you about the

[00:01:53] book but first I want to ask you about the title of the book. The title is An

[00:01:59] Elegant Puzzle. Can you kind of explain where this title came from?

[00:02:04] So titling books is kind of an interesting process where you kind of basically the working title for

[00:02:12] a long time was kind of this like systems of engineering management or engineering management

[00:02:17] systems. I knew systems was an important part and it’s a book about engineering management so maybe

[00:02:22] we should acknowledge that. But really kind of knew it was a bad working title but it wasn’t

[00:02:28] quite sure what to talk about. So I think it’s a good book. I think it’s a good book. I think it’s

[00:02:29] a good book to talk about. So as we were starting to write up the promotional materials around it

[00:02:34] like what did we want to tell people about when we talked about the book. One of the things that

[00:02:40] really came out was this idea that engineering management really is about solving these

[00:02:45] interesting puzzles and kind of figuring out these interesting patterns and how to like use

[00:02:50] these patterns to solve the day-to-day problems that we run into. And kind of as we started

[00:02:55] riffing on that idea we someone actually just pulled up a book and said hey I want to talk about

[00:02:59] this. And I pulled it out this phrase out of this this longer thing I had written kind of about

[00:03:05] promoting the book. And it’s like why don’t we just call it this. And it really stuck. I think

[00:03:10] it was one of those moments where it was like this is what we’ve been missing. This is like this this

[00:03:13] awesome thing. And it was just so much better than kind of the previous titles that we’ve been

[00:03:17] thinking about that we just kind of pivoted and went with it from there. And I’m it’s it the title

[00:03:23] along with the cover are seemingly like you wouldn’t imagine those are the most important

[00:03:28] parts of a book. And I think it’s a really good book. And I think it’s a really good book. And I

[00:03:29] think it’s a really good book. But really when I think about what makes me so happy about the

[00:03:32] book I think that the cover image and the title are really right up there. I agree. I have a copy

[00:03:38] of the book and the kind of the texture of it and the weight of it really the whole kind of the

[00:03:45] quality the feel of the cover. Of course you’re not supposed to judge a book by its cover. But

[00:03:52] this one has a pretty good pretty good face. You know that that initial impression. And you

[00:03:59] know it should be it should be noted that this was published through Stripe. And that’s where you

[00:04:04] work every day as an engineering manager. Is that correct. Yeah. So this was the I think the

[00:04:10] fourth or fifth Stripe Press book. And it was the first one to be written by by a Stripe. So it was

[00:04:18] pretty pretty exciting both to be the fifth book this awesome kind of new publisher. But also to

[00:04:23] get the opportunity the first Stripe to write one was pretty pretty special as well. And when you

[00:04:29] look at the title of the book it’s like a person who that’s that’s the internal noun for someone

[00:04:34] who works at Stripe. Right. Yeah exactly that. Cool. So the book is full of this very practical

[00:04:43] knowledge. And I wrote down a note here before I forgot this book really reminds me quite a bit of

[00:04:51] the personal MBA. I don’t know if you’ve read it. It’s by Josh Kaufman. Excellent book. And it does

[00:04:57] a very similar thing. It goes through

[00:04:59] some very practical knowledge about very specific things. But then it does you do this thing where

[00:05:05] you kind of zoom back and you say OK I’m giving you kind of the the the practical knowledge. But

[00:05:10] there’s a lot more here. There’s a lot more that you can dive into a lot more discussion to be had.

[00:05:17] And here’s the references in the back of the book. You just have this huge glossary and index of

[00:05:23] references. And so I wanted to talk to you about that for a moment. Have you actually read all of

[00:05:28] this stuff.

[00:05:29] That’s an amazing amount of material. Number one and number two. You know for people who are

[00:05:37] interested in kind of learning these kinds of systems. Do you have maybe a list a top three of

[00:05:44] things that you would recommend for people to to read once they’ve already of course once they’ve

[00:05:50] read your book. Right. What are the next two or three books that you would recommend for someone

[00:05:55] who’s interested in a career as an engineering manager.

[00:05:59] So I once you know a while ago got scolded for bringing up books that I had read too frequently.

[00:06:07] It was you know this this book kind of raises this important point about about something we’re

[00:06:13] discussing now. And I think the CEO at the time was not amused like stop bringing up books.

[00:06:21] We don’t we don’t need that sort of stuff around here. So. So yeah I actually have read

[00:06:29] all of those books all those papers and really I mean for me like reading has been like a lifelong

[00:06:35] passion and writing as well. But but I so much of what I’ve learned and it’s so much of what I think

[00:06:41] many managers learn is from reading these books. If you’re at a small company there might be one

[00:06:46] other engineering manager there might be no other engineering managers. Where do you go to kind of

[00:06:51] learn about the practice. And I really I really think these books that the handful I’ve selected

[00:06:57] and the kind of dependencies.

[00:06:58] I think are ones I’ve really loved. But I think the ability to learn when like the specific

[00:07:03] environment you’re in is not rich with experiences, I think it’s just this special property of kind

[00:07:08] of books and written material. The number one book I recommend to everyone that I talked to

[00:07:13] is Thinking and Systems of Primer by Donella Meadows. It’s just so, so good. It’s just like

[00:07:20] an entire new way to think that I’ve really just found powerful. Another one I would think kind of

[00:07:28] a classic, but I think Peopleware is a by I think DeMarco and Lister is a another kind of

[00:07:35] kind of seminal work, but just such a powerful thoughtfulness that has really just transformed,

[00:07:41] I think, so many managers, that’s like the only book they’ve ever read about engineering

[00:07:46] management. And it has a really special place in my heart as a result. And then another more

[00:07:52] recent one that I’ve really thought really highly of is just Accelerate. And that’s by

[00:07:57] Nicole Forsgren.

[00:07:58] I think Jean Kim, and there is a third author who’s I’m slipping from my head. But just again,

[00:08:05] a great data driven look at how management and practices actually work. Those those might be my

[00:08:11] three top ones to start with.

[00:08:13] Yeah, I those I’ve, I’ve read Peopleware. And I’ve read a summary of the Thinking and Systems.

[00:08:22] I have not actually dove in and read the book. It’s sitting on my shelf. Of course, I have way

[00:08:27] more books.

[00:08:28] than I have actually read, because that’s, that’s just a bad habit of mine, I suppose, I find a book,

[00:08:34] and I follow the rule that if there’s ever a book that I’m considering buying, go ahead and buy it.

[00:08:40] That’s, it’s probably not a bad investment, right?

[00:08:43] We have like a fixed size bookshelf that my wife and I have to like one book in one book out. So

[00:08:50] we’ve sort of fought that, because otherwise, we would have literally nowhere to put things.

[00:08:55] Yeah, we have, we do not have such a rule in my house.

[00:08:57] Yeah, we have, we do not have such a rule in my house. Yeah, we have, we do not have such a rule in my house.

[00:08:58] So whatever flat surfaces are available, there may be a book on that on that flat surface at any

[00:09:05] given point in time. So I think, as a moment of, I guess, advice for people who are like, Man, I

[00:09:13] really wish that I could read as much as these people read. One of the things that was really

[00:09:18] liberating for me, and maybe you have a similar experience that you can share, was the idea that,

[00:09:24] you know, you don’t have to read every last page of a book,

[00:09:28] for that book to be valuable to you. Number one, and number two, you also don’t have to put a book

[00:09:34] down forever, you can go back and read it in different portions, especially with management

[00:09:40] books, you can open up a book, and it doesn’t have to be read like a narrative, like we were

[00:09:45] taught to read, you know, in grade school, you can use this book more like a reference, a source

[00:09:52] that you can jump through, jump around, you know, pick up and drop different places, and you can

[00:09:58] pick up and drop. And I think that was really liberating for me, where before I felt like the

[00:10:04] only way that I can truly say that I’ve read a book is if I’ve, you know, devoured every single

[00:10:09] word in the book. But I think everybody has different styles. How do you, you know, have you

[00:10:13] found that that’s, that you found like a similar approach to reading? Or do you read every single

[00:10:19] book and the introduction, and the table of contents?

[00:10:23] I think what you just said resonates a lot with me. I think, you know, one of the challenges

[00:10:28] like we’re typically brought up as readers, as readers of fiction, and that’s kind of the first

[00:10:33] thing we start reading. And fiction is, fiction is not that much fun, if you skip around. Fiction

[00:10:38] is not that much fun, if you skip parts, you like miss the plot. There’s like beauty in the

[00:10:43] description. And I personally, no one ever told me, like, when you’re reading this other sorts

[00:10:49] of stuff, you just skip to the content. But that is exactly, as you said, something I’ve learned

[00:10:55] over the last five or six years was, for books, I don’t read, I don’t read, I don’t read, I don’t

[00:10:58] really like, but I want the ideas. Just skip, skip to the ideas. It’s usually pretty easy to

[00:11:03] find them. These books are pretty structured. And yeah, I, there’s a lot of books now that I’ve read

[00:11:08] that I have really skimmed through finding the nuggets. And, you know, 10 years ago, I would

[00:11:14] have never, never even imagined that. But I think there’s a book called like how to read a book or

[00:11:18] something, which, which I’ve been told is quite, quite useful for learning how to do this.

[00:11:22] Yeah, it’s really important to be able to do this. I mean, use whatever resources are available,

[00:11:28] right? I mean, you know, if you get 10% of the value out of a book, that’s better than 0%.

[00:11:35] And I think that’s, that’s something that a lot of people, you know, they never pick up a book

[00:11:40] because they feel like it’s this daunting task to actually get through it. But there’s, there’s so

[00:11:45] many ways to get value out of that. And just like building on that real quickly, like one of the

[00:11:51] realities of the publishing businesses, and one of the reasons that I really love Stripe Press is

[00:11:55] that most other publishers have like target lengths, where you need the book to be like 250 300

[00:12:01] pages. And then you fill it, you get the you get the you hit the metric, right? But it doesn’t

[00:12:08] necessarily translate to like a great book or a really readable book. And so I think even the

[00:12:13] authors aren’t necessarily putting out the books they want to. And one of the things I really

[00:12:18] appreciated about my book is that I felt initially like it was a little bit short, I think it’s

[00:12:22] 250 pages approximately.

[00:12:25] And it felt a little bit short when I held it, but like, no, this is fine. Like,

[00:12:29] if these are the ideas, and this is the amount of space you need, let’s do that. And that was

[00:12:33] something really special as well. Yeah, I think your book specifically is another one of those

[00:12:38] books that it’s not a book that you read to get all the ideas and then put down and, you know,

[00:12:45] put it in the archive. You’re, this book is much more like an index of information and

[00:12:53] various systems.

[00:12:55] Various kind of structures, ways of thinking that can be reused as as kind of like templates or

[00:13:02] models in the future. And I don’t see it as, you know, the same kind of thing as, as reading

[00:13:08] through, you know, a psychology or self help book, it’s, it’s much more, it’s more more like, and

[00:13:17] this is gonna sound wrong at first, but it’s more like a recipe book in the sense that, you know,

[00:13:22] you can reuse these pieces of content.

[00:13:25] And it’s not something that you’re going to hold in your mind per se, but it is something

[00:13:30] that is seeded well in kind of research, other people’s research, your own experiential,

[00:13:39] like your path as an engineering manager at Stripe.

[00:13:44] And so, yeah, I don’t see myself taking this book and saying, okay, yes, I have devoured

[00:13:49] the contents of this book and now I can move on.

[00:13:52] And it’s much more of a, you know, this is going to sit on the shelf as a reference.

[00:13:58] Something you said earlier is like when you’re talking about it being similar to the personal

[00:14:01] MBA is I think really what you said just now kind of resonates, which is there’s a recipe

[00:14:07] and this recipe is basically going to work for you most of the time.

[00:14:11] It’s not perfect.

[00:14:12] It’s not like the tastiest reorg you’ve ever eaten, but it’s like, it’s a passable reorg.

[00:14:18] But then like, then kind of segwaying, it’s like, and here’s the way to think about this

[00:14:22] as well.

[00:14:23] And I think, you know, sometimes, sometimes you want the kind of the thinking and the

[00:14:27] approach behind this and like all of the details.

[00:14:30] Sometimes you just need like a recipe to like run.

[00:14:32] And I think trying to give both is always a goal for me and kind of the different things

[00:14:37] that I write on my blog and also in this book.

[00:14:40] Yeah, I totally agree with that approach.

[00:14:41] I think it’s important to, you know, understand kind of the system or the systematic way of

[00:14:47] arriving at a particular output.

[00:14:50] And then also saying, here is.

[00:14:52] Is an output, right?

[00:14:53] It’s, it’s kind of the both sides of, of that, of the system, not just, you know, theoretically,

[00:14:59] this is what we should do, but also here is an expression of how that would play out.

[00:15:05] Cool.

[00:15:06] So I’d love to ask you on that point, you know, a lot of these systems that you lay

[00:15:12] out, they’re explicit systems and they’re explicit, like even numbers, right?

[00:15:18] So for example, one of the things that you mentioned in the book is.

[00:15:22] Team sizing and, you know, this is kind of a fundamental concept when you’re building

[00:15:27] an engineering organization, uh, the size of the team and how many people a given person

[00:15:33] can manage.

[00:15:33] And all of this is certainly from some of your experience, but I’d love to know, you

[00:15:38] know, what ratio would you say?

[00:15:40] This is your experience versus this is kind of theoretically, or at least, you know, backed

[00:15:46] by some kind of research.

[00:15:47] This is the way that you should go.

[00:15:48] Uh, how much, how much would you say you’ve, you’ve kind of.

[00:15:51] Yeah.

[00:15:52] In your career versus what you believe based on, you know, some, some given research.

[00:15:59] There’s not, there’s not a ton of research on these topics.

[00:16:03] And that’s one of the reasons why I think accelerate is such a great book because it

[00:16:08] actually is research driven, but also, um, people where, and slack are, are older books

[00:16:15] that had some research component in them as well.

[00:16:18] And I think that is part of the reason, like these three books, like.

[00:16:22] It does resonate with me so much for, for my, for my writing.

[00:16:26] I think it, it’s generally been my experience that it’s hard to find kind of conclusive

[00:16:32] information about like what size team should you have?

[00:16:35] But, but you do have, I think in these fast-growing companies and.

[00:16:39] When I was over, it was growing, you know, four four, 400% year over year, or when I

[00:16:44] was there for a little bit over two years and it grew from 200 to 2000 engineers in

[00:16:49] that period.

[00:16:50] And one of the really neat things about.

[00:16:51] Well.

[00:16:52] growth is that it’s kind of this like petri dish of org experimentation, where you get to see like

[00:16:58] so many different versions of so many different things. And then one of the things I’ve loved

[00:17:02] about coming to Stripe and being here the past three years is that it’s growing quickly, but

[00:17:07] it’s growing a little bit more slowly, where I get to kind of recreate these different organizational

[00:17:12] experiments, but more meticulously and more thoughtfully. And I know kind of what’s coming down

[00:17:16] the pipe. So both kind of working at these like fast growing companies, but then also

[00:17:22] reaching out across the industry to kind of folks and understanding how they work at their

[00:17:26] their other companies. It was like benchmarking, but just kind of understanding how do you like

[00:17:31] 10 similar companies like approach the same problem. I use this a lot for kind of as a

[00:17:36] general problem solving technique, but also specifically in this case, this is something

[00:17:40] I spoke with a bunch of folks, different companies as well. So I, I unfortunately don’t think there’s

[00:17:45] a whole lot of great solutions. I don’t think there’s a whole lot of great solutions. I don’t

[00:17:46] think there’s a whole lot of great data about kind of this. But on the other hand, I think

[00:17:50] arithmetic is really powerful in these cases. And I think Andy Grove was talking about how to size

[00:17:57] how he sizes teams, and I think he comes to eight, or might have come to five, but he had just like

[00:18:02] some very simple kind of rule of thumb, which is like you spend half a day per person. So you can’t

[00:18:07] have more than 10. It was basically how he did it. And I think these like rules of thumbs based on

[00:18:12] observing, like the actual kind of constraints of your time.

[00:18:16] Yeah, that makes total sense. I think, you know, sometimes we we try to complicate these things.

[00:18:30] And it’s easy to think that, you know, our, our particular system is going to work just because

[00:18:39] we saw it work elsewhere. But sometimes we just need to look at kind of the size of the box,

[00:18:45] right?

[00:18:46] You can, you can do your own kind of principles based understanding of the situation that you’re

[00:18:53] in, and derive some of the answers for yourself. And I think the book is really good at explaining

[00:18:58] that. And a lot of the topics that you cover are, you know, it’s, it’s like, Oh, yeah, well,

[00:19:05] of course, of course, it’s that way. And not like, of course, it’s that way. And we all talk

[00:19:11] about it. But more like, of course, it’s that way. Why didn’t? Why don’t we talk about it?

[00:19:16] More in this in this frame?

[00:19:19] Something I had like a kind of a stint a year or two ago about kind of reality based decision making,

[00:19:26] which is kind of this like thing I thought about kind of constantly, which is that it’s strange to

[00:19:32] to your point, there’s all these things we know are true, that we don’t act on. And I think the

[00:19:37] most obvious example is like the kind of open office floor plan. There’s a lot of research

[00:19:42] showing that this is not in fact, like a good way to make productive teams. But we

[00:19:46] we keep perpetuating it. And we keep explaining it with the same explanations, you know, like

[00:19:52] more collaboration, more communication, even as the data comes in, kind of disproving it,

[00:19:57] we still we still keep focusing on it. A book that I read recently, which is not a technical book,

[00:20:04] but I read the two income trap by Elizabeth Warren and her daughter. And they do a lot of work around

[00:20:10] research about kind of explanations for certain types of kind of financial hardship, and kind of

[00:20:15] like how the narratives that we’re talking about are, you know, kind of, you know, kind of, you know,

[00:20:15] kind of, you know, kind of, you know, kind of, you know, kind of, you know, kind of, you know,

[00:20:16] we hear in kind of like written articles, and then the actual science refuting those narratives.

[00:20:23] And I think what was so powerful about her book was just how much many of these narratives

[00:20:27] are things that I’ve believed historically, and then seeing the data disproving them. And I think

[00:20:32] it’s, it’s both powerful to know that you are wrong about a lot of your beliefs, like a lot

[00:20:37] of your beliefs are actually not grounded, they just are reasonable. And so they trick you with

[00:20:42] their reasonableness. But then there’s other things that we actually do know, and then

[00:20:46] just don’t act on. And thinking about that, I think is really important as we try to make these

[00:20:51] decisions that like impact kind of the lives of everyone we work with.

[00:20:55] Yeah, I heard a very interesting discussion on a similar topic recently, I think it was on

[00:21:00] Hidden Brain, the podcast Hidden Brain by NPR. And they talked about, or it may have been on

[00:21:04] Freakonomics, one or the other, they talked about the, the difference in the way that humans and

[00:21:10] dogs, domesticated dogs, interact with our environment, and the specific difference that

[00:21:16] they pointed out, of course, there’s a lot, but the one they pointed out was that humans are

[00:21:21] very much so kind of copycats. And we, we imitate each other, and we imitate, you know, what someone

[00:21:31] tells us to do, we’re likely to kind of listen to them, and we’re likely to do things the way that

[00:21:37] we see other successful people doing them. And so it absolutely makes sense that we would have

[00:21:43] a reality around us that we ignore, right?

[00:21:46] On the one hand, and then on the other hand, we’re willing to take this kind of conventional

[00:21:50] wisdom, or these narratives that we’ve heard over and over and over, and assume that they’re

[00:21:56] representative of some reality. And it’s kind of this, this double edged sword where we aren’t

[00:22:02] really observing the reality around us. And on the other hand, we are also accepting some false

[00:22:09] reality. And this can perpetuate into really bad decisions. You know, what you made, what you said

[00:22:15] about sensemaking,

[00:22:16] or about, you know, reasonableness, fooling us, this is really critical for especially, I think,

[00:22:24] managers to understand, because a lot of our kind of retrospective practices, we can look at, you

[00:22:31] know, what went wrong? Well, if we can explain what went wrong, then that explanation, as long as it

[00:22:36] seems like it falls together, and all the pieces of the puzzle fit, we’re apt to believe it. And

[00:22:44] even if the explanation is actually,

[00:22:46] oh, well, some set of random events occurred, that we can’t really explain. And that’s why we’re at

[00:22:52] where we are. That may be the real explanation, but we’re not very apt to believe that one.

[00:22:58] We’re much more apt to believe the one that supposedly makes more sense.

[00:23:04] So one of the things I’ve learned the most about over the last year is kind of incident programs.

[00:23:10] So kind of these programs where you have incidents in your company, you kind of remediate the

[00:23:15] incident, and you write up like an after action.

[00:23:16] You write up a report, or like a root cause analysis or whatnot. And then you kind of review

[00:23:20] them in some sort of group together. And I think I really learned a lot from some of my co workers,

[00:23:25] Talina and Davin, in particular, who have been just opened my eyes to how these work.

[00:23:30] But how I how I used to think these worked was that you brought in a report, you talk to people

[00:23:37] about it and helped them improve kind of the quality of their analysis, and maybe the quality

[00:23:41] of their remediations, and you were done. But what I’ve learned from from working with them

[00:23:46] is that the most important thing these, these incident programs do is they create pristine data

[00:23:53] about what’s actually happening. And it’s this metadata, which then allows you to see trends

[00:23:59] that you can actually believe in. And then it’s the discussion of these trends and the metadata,

[00:24:04] and you start solving the trends, not just solving the incidents. And it allows you to actually have

[00:24:09] the data you need to actually have that right conversation versus kind of the, the immediate

[00:24:14] conversation reacting to any given one, which to me, I think is really important. And I think it’s

[00:24:16] I never even realized was was the the goal of these programs until fairly recently.

[00:24:22] Yeah, that, that would be, I think, an invaluable tool set for developers to have. And I think,

[00:24:29] developers, engineers, managers, you know, all of us are doing this kind of evaluation. And,

[00:24:35] you know, this, this is applicable, outside of engineering, of course, anybody who is doing work

[00:24:42] and trying to improve on it, trying to iterate on it, and kind of improve their working processes.

[00:24:46] And I think, you know, this is applicable, outside of engineering, of course, anybody who is doing work

[00:24:47] makes total sense to be able to evaluate trends, rather than, you know, one of the things kind of

[00:24:53] an anti pattern in engineering management is the idea that, you know, a given incident is

[00:24:59] representative of some larger reality, right, that, and the trouble is that humans are much

[00:25:06] better at remembering individual incidents, especially if there’s something, you know,

[00:25:12] extraordinary about that incident. And so it’s easy for a single failure,

[00:25:16] to stick out above all of your successes, right. And so, you know, this, this visibility of,

[00:25:23] of a particular moment in time, can be really a bad metric to use. Well, it is a bad metric to use

[00:25:33] to evaluate somebody’s overall performance, certainly, but it’s also kind of the easiest one.

[00:25:39] It’s, we use these signals as, as our brains are able to process the world, we don’t really process

[00:25:45] it in total, we process it in a way that’s, you know, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s,

[00:25:46] it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s, it’s,

[00:25:47] one piece at a time, and we try to take the most salient pieces. And that just so happens that

[00:25:53] the more extra, extraordinary ones are the ones that we’re likely to take.

[00:25:58] No, absolutely. And I think it’s, you know, like flame graphs for debugging and performance and

[00:26:05] production. It’s like, if you take any one slice, you don’t necessarily get something good. But as

[00:26:10] you take many different slices, they slowly start coming together, you get like an accurate sense

[00:26:14] of what’s actually happening but but if you only if you only take a couple samples then it’s almost

[00:26:19] always you’re going to like focus on kind of fixing the the wrong problem and being really

[00:26:24] careful to be you know looking at the distribution not just the the singular event is one of the most

[00:26:31] important things that i sort of have done to improve the quality of my my thinking and decision

[00:26:36] making so we allow these um these extraordinary events to kind of act as landmarks uh for for our

[00:26:45] evaluation of what uh our our direct reports have done even what we have done we can look back and

[00:26:51] see you know the the moments of failure uh very easily but sometimes we don’t see those consistent

[00:26:59] moments of of success i think something interesting here is there’s kind of like two

[00:27:05] different

[00:27:06] scenarios that are interesting to think about for how you handle kind of outliers and one of them

[00:27:10] is kind of the sort of thing you’re talking about like a failure and how we think about oh how do we

[00:27:15] avoid over indexing on the rare failure and then conversely when we think about process we actually

[00:27:21] want process when we design like a promotion process or we design a hiring process we actually

[00:27:26] want those processes to handle all the exceptions in like a really intentional way maybe make those

[00:27:31] exceptions not be exceptions but actually handle within the norms of the process

[00:27:35] i think

[00:27:36] getting better just at making decisions of kind of all of these different varieties is definitely

[00:27:42] one of the hardest parts as being a a leader of any sort and kind of improving your toolkit when

[00:27:47] do i need a distribution when what does significance actually mean like how many data points do i need

[00:27:53] to actually understand if this is improving or getting worse like that kind of fundamentals of

[00:27:58] your statistics um and then thinking about how with process it’s not about statistics it’s about

[00:28:03] like every single case getting handled thoughtfully like all of these different varieties are going to

[00:28:06] all of these pieces i think are um really interesting pieces of the toolkit that you

[00:28:11] have to kind of bring to it yeah i don’t think a good prescription would be to just ignore those

[00:28:16] exceptions uh and and i think that you know finding that proper balance is is incredibly

[00:28:22] important and process is a way uh to to kind of enforce a balance there and good good process i

[00:28:30] think um yeah i was talking to someone kind of recently about good process and you know one of

[00:28:36] the things that makes good process good is kind of the consistency of application but one of the

[00:28:40] things that makes good process or bad process bad is kind of the needless urge to kind of force

[00:28:47] everyone with the same exact system and ignoring the the circumstances and so i i really do think

[00:28:55] there’s kind of dealing with exceptions is kind of this like core core leadership skill and

[00:29:00] particularly dealing with exceptions as you design process and figuring out how do you find

[00:29:06] it’s a little bit like architecting software how do you find the common patterns then how do you

[00:29:10] make them extensible to kind of handle like what reality brings you it is it is a really powerful

[00:29:15] topic to think about particularly when you’re thinking how do you also make this a fair and

[00:29:20] kind of just system not just one that kind of gives the results that people wanted to have

[00:29:25] all the time thank you so much to will larson for joining me on today’s episode of developer t if

[00:29:31] you don’t want to miss out on the next two parts this is a three-part interview

[00:29:36] with will we had so much ground to cover if you don’t want to miss out on those two parts i

[00:29:40] encourage you to subscribe and whatever podcasting app you’re currently using and here’s why i think

[00:29:45] you should subscribe you hear all the time that if you put your investments your savings on an

[00:29:53] automated schedule you’re much more likely to save more than if you were to try to remember

[00:29:59] to do that yourself now the show isn’t necessarily a financial investment in your career but i do

[00:30:06] believe that developer t other shows on the spec network and the other wonderful podcasts that are

[00:30:12] in the the kind of developer podcast ecosystem that those are investments into your career

[00:30:19] subscribing doesn’t mean that you have to listen to every episode and in fact i encourage you to

[00:30:24] pick the ones that you think are most relevant and spend your time with this podcast strategically

[00:30:31] but i do believe that spending regular time thinking about these subjects

[00:30:36] is important to every developer’s career by the way we wouldn’t be able to make this podcast happen

[00:30:42] without spec spec is a content network that is built specifically for designers and developers

[00:30:47] who want to level up in their careers go and check it out spec.fm thank you to today’s producer

[00:30:52] sarah jackson my name is jonathan cattrell and until next time enjoy your tea

Visão de gráfico