Will Larson Reflects on Staff Engineer

Will Larson (00:00)

my experience has kind of been one, it, the industry is rarely going to just give you what you want. That's my rule one. But rule two is like, you can almost always like create the thing you want.

Carter Morgan (00:19)

Hey there, you're listening to Book Overflows, the podcast for software engineers by software engineers where every week we read one of the best technical books in the world in an effort to improve our craft. I'm Carter Morgan and I'm joined here as always by my cohost, Nathan Toops. How are you doing, Nathan?

Nathan Toups (00:31)

Doing great. Hey, everybody.

Carter Morgan (00:32)

Well, there's another special episode of Book Overflow. We have to interview our authors whenever we get the chance. And we have a great one for you this week. This is Will Larson, author of many books, including a new one, Crafting Engineering Strategy. But this episode, he's reflecting on Staff Engineer, which we read a couple of weeks ago. Fantastic book, fantastic interview. Such a pleasure to have him on. Nathan, you want to give them a sneak peek of what they're about to hear?

Nathan Toups (00:54)

Yeah, Will Larson's just, I his interview was the same sort of like conversational style that you'll see on his blog or in his books. Just real straightforward. It was just a great conversation. I don't know. I learned a lot out of it. I think you will too. It's been, it was really, really cool elaborating on Staff Engineer.

Carter Morgan (01:16)

Yeah, Will Larson is absolutely one of the, he's definitely one of the better known thought leaders in our industry. And for good reason, because he is incredibly thoughtful and measured. And you're going to see that in this interview. Lots of careful considerations around all of those different challenges you can encounter when either as a staff engineer or trying to become a staff engineer. So please enjoy the listen. This is Will Larson, as he reflects on his book, Staff Engineer.

Carter Morgan (01:44)

Well, well, thank you so much for joining us. It's a pleasure to have you.

Will Larson (01:48)

Thank you so much, super excited to be here.

Carter Morgan (01:51)

Well, awesome. We like to start at the beginning of every interview with just basically asking you, describe the computer science industry at the time you wrote the book. When was this published again? This is fairly recent.

Will Larson (02:03)

So I want to say I wrote this mostly in 2020 and then I got published in early 2021.

Carter Morgan (02:06)

Okay.

Okay, great. So only a couple of years old at this point. ⁓ So maybe describe the industry at the time. I know that was pretty recent, but what about the industry and about your experience kind of motivated you to write this book in particular? Cause you have authored several others.

Will Larson (02:21)

So in kind of like the 2010s, there was this like the Zerp era, like zero interest rate phenomenon. And it was just, there's a ton of high rent.

Carter Morgan (02:26)

Good times.

Will Larson (02:31)

They were nice while they lasted sort of, as I've shifted a little bit since then, but a lot of what was happening is you saw these companies growing really, really quickly and they started kind of coming up to having these staff engineering roles, but they often wouldn't really have anyone that had worked in a true staff engineering role before. Cause only, only a few companies really like have true staff engineering roles. So you have a lot of small companies that might have like 20 engineers, but might have like four staff engineers. And those are like.

Those are titles, right? But the actual like work that those folks are doing typically like, isn't that different than like what a senior engineer on the team is doing. Maybe they just have like more experience in the senior engineers, they get the different title. So what I was seeing at Stripe, which is where I was when I came up with like most of the idea for the book, was really talented people whose idea of being a staff engineer was just, I'm a senior engineer, but like more senior. And I just had so many conversations with them where I was like, Hey,

Carter Morgan (03:02)

Right.

Will Larson (03:28)

If you want to be promoted to the next level, you have to understand like what leadership needs. And if your idea is that as a staff engineer, you get to ignore leadership because you'll be more senior. So you have like more agency. So you get to do less of what like the more senior folks want. That's just like not how these senior roles work. And so I really wanted to figure out how do I, how do I package this in a way where it wasn't just me saying that, but I found folks who from a number of different companies.

who had found different really senior roles, but I wanted to find some of the commonalities, particularly this idea that the more senior you get, it's true you have more authority, but your actual ways you can use that authority that are valid instead of invalid and getting you in a lot of friction are actually smaller and smaller. It's like, I'm a CTO now. The things I'm allowed to do, from an authority perspective, I can do anything, but from the number of things that won't get me fired, it's extremely limited.

Carter Morgan (04:24)

Hahaha.

Will Larson (04:25)

And so I really wanted to help tell that story and give like real examples of how people had found these roles. And none of them were, I just stopped doing what leadership wanted. And I just kind of showed leadership what they should do instead. That's just like an archetype that doesn't really exist. But you can't convince people of that. You sort of have to show what people do do and then try to generalize from that.

Carter Morgan (04:48)

You mentioned in the book, I think we read Slow Productivity by Cal Newport. Have you ever read that? Yeah. The idea is basically about like doing work that actually moves the needle. And he talked about this term pseudo productivity, which is like you're, technically working and you're doing things, but like, it actually contributing any meaningful way? And then you

Will Larson (04:59)

No.

Carter Morgan (05:15)

touching the same concept in your book, but you bucket into kind of two different types. You're talking about preening, which is doing high visibility, low impact work, and then snacking, which is, is it fair to call that low visibility, low impact work? Or how would you describe that?

Will Larson (05:31)

Yeah. So snacking is a term I stole from Hunter Locke, think. But, but yeah, I think that's what you said is basically right. Where sometimes snacking happens to be high productivity, but really like the most important thing is it's like rewarding and usually there's nothing stopping you from doing it. In a really small company, sometimes there's really valuable things that no one's done that you can just do. But in larger companies, there's usually very few things that are high productivity that just no one's done for no reason.

Carter Morgan (05:48)

Mm-hmm.

Will Larson (06:01)

Usually they haven't done it because of some reason, like maybe there's someone who thinks it's someone senior thinks it's a terrible idea. It's actually really hard to do. It's easy to start, but to finish the migrations hard. You see that for like all sorts of projects where like starting to roll out a new database is easy. Getting everyone off the old database is incredibly hard. And so like the first part of it's snacking. The last part of it's definitely not. And that's what people start.

Carter Morgan (06:05)

Right.

Will Larson (06:26)

Declare victory and then like bounce before they actually have to do the hard part, which you see kind of all over the place.

Carter Morgan (06:33)

What do you think it is about the engineers who succeed at avoiding the pre, avoiding the snacking and kind of digging in to do the hard part? I love that example you gave, like everyone loves building the new database. They love building the new system. That's the fun part. And then actually seeing the migration through to the end, that's where it's difficult. What separates the engineers who actually do that?

Will Larson (06:58)

I think, you know, something that I think is really important is I think about what makes a good senior leaders on the engineering and on the management side. There's sort of like a resistance to like the, how things are perceived instead. They have such a strong point of view about how things work that even if you tell them something that they don't think is true, they just don't believe you. And so I think on the database side on that, that's example, like migrating to new database.

There's engineers out there who are like, know the migration and getting people onto the hard part. Cause at my last job, we had three databases. We hired a new head of engineering. came in, they added like a fourth database that they liked the most. Then we had four databases, like three of which were deprecated and like only, but only one of the deprecated ones that actually worked at scale or something like that. And the problem is for a lot of these companies, like the thing that is valued, like the preening work.

is actually like what gets you promoted, but it's actually bad for the organization. So like the value systems are kind of like misaligned because the people who are evaluating the work are often new sort of thing different to the realities on the ground. We just don't understand the details very well. And so you actually need like engineers and managers who are so fixated on doing what they believe is right, that they're willing to like disregard the value system around them in some cases.

And so it's kind of funny because those are also people who get fired for being like difficult, for not being flexible, for not aligning up. And so it is like this interesting kind of piece where sometimes the people who have such confidence in reality that they can ignore kind of the optics also can then fail in terms of getting promoted into these senior roles because they're too rigid. And so finding people who are really successful, you both have to able to see reality, have conviction that what you believe is true and still up

like align upwards with folks who have a different worldview. And that's just like a hard combination. Like not many people are able to do both sides of it.

Nathan Toups (09:34)

Since we're diving straight into anti-patterns and pitfalls, it seems like we just like jumped right into some juicy stuff ⁓

Carter Morgan (09:41)

We say we love a good anti-pattern and pitfall chapter. That's our favorite chapter.

Nathan Toups (09:43)

Actually, anytime a

book lacks a section on these, I'm always disappointed. And so this book was great. ⁓ I wanted to bring up one of my favorite ones, which is The Chasing Ghosts, which I think kind of you alluded to a little bit maybe. ⁓ I had also heard this maybe, and maybe this is a misunderstanding on my side, or maybe it's a good other way of describing it. There's this thing called the frozen caveman problem, which is another ⁓ way of like, you've had some scar tissue from the past, and so maybe you over-engineer protection. ⁓

But yeah, I would like to ask you, is it an aesthetic thing? Is there actually a method to an understanding? What's a bag of tricks where you're like, yeah, actually I'm awesome and this is a good thing to apply in this new job, or actually I'm chasing ghosts?

Will Larson (10:30)

think there's a few different ways to think about it. And I think there's a few different ways that things can be like ghosty. And like one way is like your knowledge is just out of date. And so I think if you look at like MySQL Aurora or Postgres Aurora on AWS, there's a lot of like MySQL scalability stuff that people just know is true. That is not really true anymore in terms like the modern, like MySQL providers. But if you came up in like 2005, there's these things that you just like know are true.

They just can't, you can't be convinced without just like seeing it not be true in production that they're not still relevant. And so that's like one bucket where it just like, have like prior experience that like seems like it's still very relevant. That just isn't relevant anymore. And like a lot of like optimization work kind of falls into this bucket where it's incredibly important to like optimize, but then like when CPUs get cheaper or memory gets cheaper or whatever, it just like, isn't that relevant in some cases if the data size is small.

So that's like one bucket. And I think in general, there, just have to have like a good sense of like the, you know, what, what are the conditions where this matters in that kind of like general debugging mindset of like, is this like a bottleneck? And if it's not a bottleneck, it doesn't really matter. Or, you know, a lot of times for like vendors, you'll have like the same amount of rigidity or like a vendor, a bill's up like two, 2000%. But if it's going from like $500 to like, five, you know, $5,000 or

50,000 to like 2 million, they're like really different. And like, it doesn't actually matter if a bill goes from like 500 to like 5K that much. But if it goes from like 50 to like 500 or 5 million, it matters. Like it matters quite a bit. And I think just sometimes people don't have like good calibration. Like, does this actually matter? Is this actually relevant in the situation? That's like one bucket. The other bucket though is I think for reasons that I still don't wholly understand, like a lot of leaders just don't.

don't really like understand that their new situation is different than their old situation. And maybe part of it is if you're just like in like a company long enough and the things that are true there just become like axiomatically true everywhere in your head, because there is nothing else. And maybe that's one of the perks of like changing jobs like relatively frequently is you never like fixate on like the one way things are true. But I see that a lot where particularly folks who are in like

elite institutions like your Googles or whatnot, just kind of come out and they're like, this is just how things work. And that's not, that's just not true. It is how it worked there, but it's not necessarily true at your startup, small startup. It's not necessarily true at your AWS or GCP native like startup. There's just like a lot of things that you would assume are true that aren't. And that's to me, the source of like most ghost chasing is just things that have changed underneath them. And for whatever reason, people just aren't.

Carter Morgan (13:04)

Right.

Will Larson (13:27)

paying attention to the fact that they have.

Carter Morgan (13:30)

I struggled with that a bit when I was at AWS for a couple of years and then left. And AWS does a lot of things very well and especially like certain things around like incident response and just deploying at scale. ⁓ but I kind of came out of AWS feeling like, yeah, this is how real engineering is done. And it's like, well, it's, it's very good for what AWS is doing. When you have a product that generates a billion dollars in revenue and impacts a billion people and the

prime directive is don't let the product go down, then yeah, there's a lot of, ⁓ I think all those procedures and that tooling and the maturity around the infrastructure makes sense. And now I'm at a startup of 30 people, right? And I had a job in between here and there. And so I got, I learned some of my hard lessons at that job. But I mean, if I were to come into this job and try to implement everything we're doing at AWS, it'd be a disaster.

Will Larson (14:24)

And the funny thing is like in the first moment, that's like probably not obvious to you. Like the first time you leave, like if your first jobs at AWS, then you come to like that small startup is like, you can't perceive, but you sort of expect for senior leaders like that. have the ability to perceive. You sort of assume that they like switched contexts enough that they can like realize intuitively, like, this is like a 10th the size. Of course it's going to be different. But the thing I just find surprising is that.

Carter Morgan (14:36)

Right.

Will Larson (14:50)

for a lot of senior leaders on the management side. But also like why I wrote this book on the staff engineer side is like, they just don't perceive things that you would from the outside would assume or just like completely obvious, but they just can't perceive them until you hit them, hit them with a book a couple of times.

Carter Morgan (15:08)

I've had relatives and friends remarked to me, our industry is just very unique in that, like, if you've been at a company for five years, people are like, whoa, you've been there. You know, we in the industry are like, wow, that's a long time, right? If you've been somewhere for 10 years, it's like, holy cow. Um, just by nature, we're in our industry. We switch around every three or four years. Do you think that's a good thing? One for the industry and two for the individual.

Will Larson (15:34)

I ⁓ so when I wrote my first book, An Elegant Puzzle, know, one of the frequent complaints people would write, and I've gotten this complaint to a lesser, but ongoing degree for everything I've written, which is like, that's not how it works in the real world because in, you know, where I am, which is the real world, it's different. And so I think, so I went to college in Kentucky. And so a lot of people ended up like working on like very small, like software companies and like Lexington, Kentucky or something.

And what's true for them is like literally nothing in common to like what's true for even the smallest startup in like San Francisco or in like Salt Lake or something like that. It's just like completely different realities. And so I think, you know, the first thing is like, maybe it's not true that most people switch as frequently. Like I think it's, like very like context dependent in terms of like which sort of environment you are, like SLC has like a huge like booming like tech ecosystem now.

But probably like 15 years ago, like my guess is like job tenure was like really long. And actually a lot of companies that hire an SLC hire there because they think people don't switch jobs there because they think that people there can't find other jobs. And I think that's like less true on the tech side. But if you look at like the customer support, like agencies that are getting spun up there, I think it is true that the retention there of employees is higher. And so.

Carter Morgan (16:33)

Right.

Right, right.

Right, right.

Will Larson (16:56)

You know, it's hard to generalize what's true about the ecosystem. It's just so large, but in general, I do think like job switching is pretty valuable for us as individuals. A couple of times in terms of just like seeing different views, I think particularly early on, just seeing how it works a few different places. It makes it so you can be like, like this is working poorly. But I tried the same thing at this place where it worked well. So first it helps you like not invalidate techniques as like good or bad.

from like just conditionally good or bad. And second, just have like a broader like bag of stuff to pull from. But I do think that the flip side though, kind of goes back to the preening discussion where if you don't stay long enough, you don't see the consequences of your decisions. And so like something as I've gotten deeper into my career, I've been thinking about more as like finding the places where you really could keep learning for like 10 years. And I just, there's only...

Especially in startups, there's just only so many companies you can predict like three years out, let alone like seven or 10. And so it is hard to figure out where those places are. And I was at Stripe for four years, but the Stripe when I joined was about 500 people, about like 115 engineering. When I left, it was like, think two and a half or 3000 people. And so it was just like a radically different company. At Uber, I was there for two years, but engineering went from 200 people to 2000 in the two year period.

Nathan Toups (17:54)

frame.

Wow.

Carter Morgan (18:19)

wow.

Will Larson (18:19)

It's

just like, I don't know, it's like they change so much that they're almost like they're different companies themselves, even though like the titles, the offices are in the same place and like the names are the same, but the companies aren't the same, like even, even if they technically are at the same corporation.

Carter Morgan (18:34)

It's a real ship of theses thing, right?

Nathan Toups (18:39)

So one more section, one thing that I wish had been in anti-patterns and pitfalls sort of section was something that touched on maybe around the Peter principle, which we've seen this like the promoting into incompetence, ⁓ especially in management. But I was wondering like, where's this moment where, let's say I get into a staff position, I'm like, you know what, this is not the right fit actually. ⁓

Have you seen this happen where you've put someone into a staff position and you're like, this just isn't right? ⁓

Will Larson (19:16)

think there's like a few different examples of that. So first I've seen a lot of people who are senior engineers and they're like, I don't want to do that. They're like, they look at the next level and they're like, I don't, I don't want to do that. And they, they have like the self-awareness where there's more like coordination, there's more conflict. There's more like you have to make the final decision and piss people off. And so I've seen like a good number of people, not like a high percentage, but I'd say like maybe like one in 10, like senior engineers is just like, I...

I absolutely don't want it. And they tend to be people who are like actually quite good. And they're just like, I don't want to do it. And so I think you definitely see that. You don't see as many people on the flip side who hit staff and then are like, yeah, I don't really care. So I've had a few people and like sometimes you like hire someone from a company where like a staff engineer means one thing into a role where it means something else.

And so particularly for really small companies where you have like a principal or something, it's like, like, you know, like whatever, it's just like a title, right? It's like, or chief architect. It's like, sure. Like that, that could mean like kind of anything. There's no like real agreement on what a chief architecture role means anywhere. And so I have seen people kind of get down leveled across companies. I haven't done it often within a company. Typically when I've done it just a few times, it's been someone gets hired and in the first like six months it's just like.

They're obviously not at the level, but they're like actually doing great work. They're just like at the wrong level. And there's something where you think they just can't ramp into it. So, and that could be like, ⁓ sometimes communication is just like really poor. You're like, the actual work is very good, but the communication is just quite poor. And you're just, you can't serve at the level of seniority we want in this company. Cause like, you can't communicate the way we need.

And sometimes it's just the attention is wrong or it's like, actually are maybe very talented communicator and a very talented engineer, which is like what you want to work on is like not that valuable. And, know, this is one of the things when I wrote this, ⁓ I was thinking about it, Stripe is there was like a big focus on wanting to more open source and I'm going to be staffed because I want to do more open source. it's like, well, objectively, I don't think this is useful for the company at all. Like, I think this is actually like distracting us as slowing us down.

preventing us from working on stuff, think would be significantly more valuable for us. Not in every case, but in many cases. And so I think that was one where sometimes just people's energy gets pulled in the wrong way. And that one, that one's hard to fix because you even if you down level them, they they're still wanting to work on the wrong things. And so I do think on that one, it's typically like a fit with a company issue. It is, it is an interesting one though. I definitely.

You know, people want progress and they, I think they misunderstand what progress means in a lot of cases. And so I think the, you know, I was talking to someone recently about like executive roles and like one of the pros of executive roles is you have like a lot of freedom. One of the cons is when something's going really wrong, you sort of have no freedom because like you have to, you have to be there. And so like I've been, you know, at this company since I started, I've been like the last tier of on call for like every rotation.

which I put in place. ⁓ and when I was at Uber, was like the much less senior role at Uber, but I was still the last year of escalation for every on call. And there's certain things that like, you know, are necessary to actually accomplish goals. I was actually the second to last because the next was the CTO. So at Uber, every, everything I was like, I don't get it. It's going to the CTO and he's going to come yell at me. So I can't let a single thing through. And I think in like, in two years, I didn't let a single thing through.

because I knew like I really didn't want it to go through. And so I do think sometimes people want senior roles to have no downsides, not only upsides. And that's just like not my experience for people for whom senior roles are successful. Like there's a lot of downsides to senior roles. And if you don't think that's true or fair, like then I don't think you'll be that effective in senior roles.

Nathan Toups (23:28)

That's cool to hear ⁓ on the on-call. The best team I'd ever been on, like high functioning team. I was a senior site reliability engineer on the team and we had a primary and secondary, we're pretty small ⁓ FinTech company, but it would escalate to head of engineering. And we always just played this game of it should never go to him like ever. And it was, it just kept us honest. It was actually like a really, I mean,

It was a high stakes game, but it was also like a fun game to be like, okay, I just never want this to wake him up at three in the morning. That's our goal is build the system the right way.

Will Larson (24:04)

I honestly think

it's kind of like how it should work though, in the sense that, if you're the head of engineering and things are falling through, you really want to know it's falling through. You really don't want to like not know it's falling through. And then like the site, you get like a call because like a customer is complaining or whatnot. You really want to know. So I do think this is like a pattern I wish like was just standard for every head of engineering that it just kind of fell through. I think I haven't seen it too often.

Nathan Toups (24:14)

Yep, absolutely.

Will Larson (24:33)

I've only seen it a couple of times, but I've been copying it because I think it's a great pattern.

Nathan Toups (24:35)

Yeah.

Yeah, you know, I've used it elsewhere, or at least advocated depending on which role or position I was in, just because, yeah, it makes you really honest about the process and you can't fake that. ⁓ It's gonna escalate. So to take things to a more positive note, and I think that this is another thing that stuck out to me and I actually was able to immediately apply it. I was in a...

My title was software architect, but it really was a staff position sort of in this company. And I was in a position to mentor, but I hadn't really thought about sponsorship. And this changed my thinking. I was, why do we think that maybe, and maybe it's my blindness here, but why is sponsorship maybe valued less as like, I hear a lot of people talk about mentorship all the time, but not sponsorship.

Will Larson (25:34)

It's a good question. And I find mentorship, so mentorship is interesting because I think mentors, some people have really great experience being mentored or mentoring and some people just don't. And what I've come to believe is like the thing that makes mentorship work is like the pairing, like the right person who's the mentor and mentee, like incredible, but like the wrong pairing just like not much happens, like a little bit transactional, then they kind of stop. So, and this is like the challenge with a lot of like...

planned mentoring kind of programs within companies is you kind of like, it's hard to get the right matching because usually there's like two people that everyone wants to be their mentor. You can't like map like everyone to those like two specific people. And so it just gets like a little bit watered down. I think the sponsorship one is, under, under emphasized for, for a lot of reasons. First, like, you know, it's, it's vocabulary. So some people are going to be mentoring and really sponsoring while they do it. So it's try not to get too caught up on like the

definitions and these things. I do think, I do think a lot of folks don't think about their role. And part of this is maybe back to Carter's point about like the, you turn over in companies frequently enough, the idea of like fostering the next generation can kind of get lost sometimes. And you don't actually see the consequences of not fostering the next generation and then the next generation, if you're moving quickly enough.

So this is one place where I just think seeing the consequences can be challenging. So what I've seen is a lot of mentorship is actually cross company, kind of like company independent, kind of happening outside of that. I do see, I see a lot of it, but I just think it takes, it takes a long time to build. I think there's some places, I mean, this is my, just my experience personally, like some places there's so much density of folks who are in the industry.

And we're really like actively engaging that it's pretty easy to find kind of those relationships. But I imagine in some places, like much harder to do outside of the context of like a company that you're working in. And I've just not seen them. I've not seen like a whole lot of proactiveness on it in general. I don't, I wish I had like a better answer, but I, I've not seen, you know, for, for managers, like you're occasionally held accountable for like how you nurture that your team.

Often you're not like, be totally honest, but as a staff engineer or any engineer, you're rarely held accountable for not nurturing. I mean, you're mostly held accountable for shipping. And so I think that's like, like if you're really going to get fired, it's not going to be cause you didn't mentor someone, but it might be because you like messed up executing and yet it. Sequence of really terrible on-call shifts where you like lost some work or something. And so I think it's just like under-emphasized because people are like a little bit short-term, but you know, not just.

other people, I've definitely made this mistake myself a number of times.

Carter Morgan (28:28)

But that idea of sponsorship, I mean, that's something I've had to learn in my career and in some ways the hard way, which is that like, you've got to learn where your bread is buttered, right? And you need to kind of attach yourself to a manager or a director or someone who's going to fight for you. But there's, I've had kind of two problems with it in my career. And I think it's common across other people. One, some of the bigger companies like AWS, and I don't know if Google is still doing their team matching, but it's very common that you don't even interview with the person who ultimately manages you.

⁓ maybe if you're lucky, you get to do like a 30 minute call with them before officially joining. That was my experience joining AWS. The other thing is, so I was at kind of like Silicon Valley, Feng companies for a little over three years. And in that time I had seven managers. Right. And so it's just like, it wasn't even possible to like latch onto someone and be like, you're gonna. You and I, know, we're, we're going to do this together. I mean, if you find yourself in a.

situation like that? I guess this is a two pronged question, which is like, one, how are you setting yourself up for success when you're looking to move to another job and making sure that you are partnering with someone who you think is going to be able to sponsor you? And two, if you happen to find yourself in say my situation where you just have this carousel of managers, like, is there anything you can do to get yourself out of that situation? Or is this just kind of like, you know, luck of the draw thing?

Will Larson (29:50)

Yeah. mean, the joke I tell people about Uber is like, had five managers and like none of them were longer than three months and they all got fired or pushed out of management. And so like that was just kind of the environment that was in. And I think a lot of these really fast growing companies are like that. Cause just like, ⁓ particularly if you're in a more senior role, there's just like a ton of like mobility. And then I think at like a thing, like a Google can be like, there's a ton of stability in Google.

Sometimes, but there's also been like a ton of reorgs recently in the last like four or five years, then ton of like reductions. So even, even places that seem super, super stable or a little bit less stable than you might imagine them to be. So, so my experience has kind of been one, it, the industry is rarely going to just give you what you want. That's my rule one. But rule two is like, you can almost always like create the thing you want.

And so as like a really concrete example.

When I, when I left Stripe, well, before I left Stripe, I started interviewing for kind of head of engineering roles. And I, and I got one that I kind of left once I, once I got that. And I was like, Hey, I don't really have like a great like head of engineering network, right? Like I have a bunch of like middle managers and engineers and so on, but I don't know many people who've actually been in these like head of engineering roles. And so I reached out on Twitter and tried to find like people who want to join like the learning circles.

And then like I got a ton and it was, you know, some of the folks were like really amazing and some were very random, which is like kind of what you'd expect to have happen when you like reach out online. And then I filtered it down to like three different groups that actually met. then like one of the groups that I personally led, like it's still running to this day. It's been meeting like every other week for, you know, five, five, five plus years.

And the membership has changed and I've learned a lot about running learning circles. And I think I work with Uma Chingande who worked with at Stripe, she co-runs it with me now. And so we've like shifted how we operate it. We've added probably three to four times the number of people we've added to it over time as people kind of like drifted away and then like backfill new people in. But this is something like I didn't have that network at that point. And so I, you know,

Nathan Toups (31:38)

Cool.

Will Larson (32:06)

did the work to create it. And I think for so many of these things, and just thinking about like this podcast you're running, right? Like by running this, you create a community. And then as you have that community, can like use, bring that community together to like learn together. You can, can be useful to each other. There's all sorts of things that you can just, you can just like create by putting time into it. And I think for a learning circle, it's like just fixating on my example. If you, if you just put the people together,

It doesn't really do anything. It like falls apart pretty quickly into the groups. I wasn't running fell apart like within a couple of months, but instead you actually have to organize it, like figure out like, is it going to be a Slack group or a signal group or whatever? Then you have to like manage the topics. have to, you have to kick people out of a learning circle, like to make it be effective because the people who aren't in it are just as important as people who are in it in terms of like a group being like a good learning community. That's like, hi, like trust each other and has like good discussions.

But to me, like that's really like what I've learned about mentorship and I don't want to generalize it, but you can create these communities if you're willing to put time into it. And there's a lot of other people who wish they had the thing that you also want, but they just haven't put the time in. And so I think, you know, you can make these things be real and then put time into it and they'll be really great for you and for the other people that participate. So that's, that's what I found effective. Cause I just think within companies it,

Nathan Toups (33:12)

Yeah.

Will Larson (33:32)

And like my manager when I left Stripe, David Singleton, I think he was fantastic, but he was only my manager for like two years, something like that. And I'll probably never work with him again directly, right? Like maybe I will, but it's relatively unlikely. So when you rely on your company to find your like mentor, it's just like, it's so transient and it's so hard to get the right match.

Nathan Toups (33:54)

I'm not familiar with the term learning circle. This is intriguing. I'm like leaning in. What motivated you to find this and how did you learn about this pattern? What is this?

Will Larson (34:05)

Yeah. man, great, great question. I don't even know where I really picked the term up from, but like in a lot of companies, there'll be like a, like informal learning circles, kind of groups of people come together to learn from each other. And then you kind of have some like operating rules. And so like the way the circle that I would lead runs, and I found it pretty effective is that we start out by each person and typically we'll have like six to 10 people on, on a given, a given.

session has like one minute to be like, what is the top thing you're working on that you're challenged by in a topic you want to discuss, discuss with the group. Then like the leader of that session, like me or Uma, depending on who's leading it, we'll pick like three or four of those topics. And then like, we're going to talk about these three or four as a group. And then there's like variations. Like sometimes they have like a speed round for like really small topics where I could do like three or four questions and like just two minutes of just like quick thoughts from folks.

And then we have like a bunch of like operating rules where we try to tell stories about our own experiences rather than give advice. Cause I think when people give advice, it's like often like not that hopeful, but when people like share here's, was in a similar situation and here was my challenge and here's what I did. Then it's like an honest story. And so that's like, Hey, you need to do this, which is like, I don't think people respond to super well to be like, totally Frank where like, when you hear a story, decide to take away from it. And so that.

Yeah, I honestly don't remember where I learned about it. I'm sure there's like a rich, like academic background to the concept of learning circle, but, this is, this is what I've done. And, you know, the biggest challenge to these being successful. As you really need a moderator that will like cut people off. And so if people like take too long, you just have to like cut them off. And I think only, only some people are comfortable managing conversations to that level of precision, but I I've gotten comfortable over the years.

Nathan Toups (35:49)

Amazing.

Carter Morgan (35:51)

Ha ha ha.

Nathan Toups (36:02)

Well, thank you for sharing that.

Carter Morgan (36:06)

You mentioned in the book about being a staff engineer, that one thing that can be really challenging about the role is that you, and we've alluded to this in this interview, it's like, it takes a long time to see if what you did was ultimately correct and to see the payoff of that. ⁓ So one, you talk in the book about kind of like having good intuition and making sure that you are setting out.

to do the right thing. So I guess my first question around that would be what strategies should prospective engineers ⁓ be using to be developing that good intuition? And two, as a staff engineer, is it kind of the nature of it that you're putting a lot of eggs in relatively few baskets or are there tactics you can choose to maybe diversify and then if initiative A doesn't turn out so hot, that's good because at least initiative, or that's fine because at least initiative B is doing really well.

Will Larson (37:03)

I so. My first thought is like the number one, like underutilized tactic. I genuinely don't understand why people don't do it. It's just like asking. And so like when you started your job, you're like, Hey, I think I need to work on this. It is shocking how often that person will just go decide to do it. It won't ask anyone who's already there, whether or not like, Hey, is this, is this a good idea to go do that? Or

Carter Morgan (37:13)

you

Will Larson (37:28)

It seems like such an obvious idea to me that we need to work on continuous deployment, but no one's doing it. Is there something I'm missing that makes this a worse idea than it seems like? And just like, just like a few questions like that to like a few different people, usually you'll be like, we fired the last principle for like working on that problem. Usually you'll find something right. And so I think, when people, when people don't ask, they just like miss out on this like huge opportunity to learn.

Nathan Toups (37:48)

Yeah.

Carter Morgan (37:51)

You

Will Larson (37:57)

Cause like not everyone will tell you like, they're usually there's like a decent number of outspoken people that will just like tell you what they think. And they sort of like can't not tell you what they think. And those people are kind of annoying when they disagree with you all the time. But when you just need like perspective, they're like, you're your best allies in terms of just like, tell me what I'm doing that's wrong. So that's like the first bucket. If you literally just ask, ask your manager, ask like a senior peer, ask another manager, like people will just tell you, but I'm shocked how often people just like never ask.

It's like the first kind of piece of it. The second piece is like increasingly in my career, I believe in this idea that you do want to have like a small number of big things, but you don't actually have to like take big risks most of the time. You just have to figure out a sequence carefully. And so for example, we're rolling out, like we're improving our continuous integration, continuous deployment stack at imprint. And like one way to do that is like layer by layer.

The problem is like if you do later by layer, it's like extremely hard to evaluate if it's working until the very end, kind of the whole like DevOps concept of like you want to ship each stage, ship the entire thing. And then if then you can get feedback and improve it. But if you just like ship pieces, get kind of waterfall to get no feedback. And if you're wrong, like it's going to take you like months or quarters to figure out that you're wrong.

So what we're doing there is we just focused entirely on the front end, kind of the static front end assets, like the single page apps as like the first piece to get working end to end. And we're shipping those. And then like we find the problems and then we can iterate there. And then when we expand out, we will have already improved it. So it's a likely to work or if it sucks for some reason that we haven't figured out, it's going to fail quickly. And so that's like, to me, like the biggest thing is like learning how to restructure your projects where they can, if they're going to fail.

They're going to fail fast. And I, I've just seen so many projects, you know, one that gives me a lot of grief at, at Carta. We, we worked on like changing how we did role-based access control. I'll you, Gazanzebar inspired model and the technical work we did there was extremely good, but we didn't really solve the power would companies or how would the internal like business units integrate their software with it. And so the actual like expansion of the rollout got really, really, really, really challenging.

even though the technology work was like extraordinarily good. I think a different way to have done it would have been like trying to model with a terrible internal implementation, but just like the interfaces and figuring out how to model and then seeing if they can make that work on the hard cases. I wrote a post about migrations years ago and the biggest thing is start by migrating something easy, then migrate something really, really hard.

don't do all the easy's and then the first hard because if it's gonna fail, you actually want it to fail early. And I think, know, if when you avoid that, because it creates the optics of progress, you usually end up like screwed in a way where it's really, really hard to recover. But in a lot of companies, the optics of progress could still leave you in a better place than failing correctly early on. So it is, this is part of why ignoring.

Optics is part of the necessary to be really successful. Like the optics will mislead you like nine out of 10 times on the right way to do problems if that's too important.

Nathan Toups (41:15)

Hmm.

Carter Morgan (41:22)

We, I've just had migrations on the mind, because we are stuck on a tech stack at my current place, which no one likes. It's kind of a relic of some of the founding decisions, but we're just at the point, like, just for example, like GraphQL, none of us like GraphQL. We don't think it's serving our needs properly, but it's the foundation of our whole backend. And if we could wave a magic wand, we'd get rid of it and just switch the rest. But you can't wave a magic wand. And we just can't justify.

Nathan Toups (41:23)

What, ⁓ go ahead.

Carter Morgan (41:51)

all of this effort to migrate and geez Louise, I'm sure the number of regressions we had introduced over the course of migration. And so I get that this isn't strictly related to the staff engineer book, but selfishly, one thing I like to do when we have authors on the podcast is just get their opinion on the problems I'm having, which is that ⁓ as far as migrations go, I mean, how do you evaluate when a migration is necessary and the juice is worth the squeeze versus when it's a little more of like a vanity?

Will Larson (42:22)

Yeah, it's funny. ⁓ One of my good friends is the head of engineering at Apollo GraphQL. I think it's sort of like inevitable, like in the industry, every product or every company, including the ones you're competing with, all have like people you know, and generally like, so it's a very small industry. But I think it's like real question. And so when I went into COM, I...

Carter Morgan (42:42)

you

Will Larson (42:49)

I did what I'm about to describe. did the same thing at Carta. I've been a little bit less militant about it at imprint just because the needs were different. But when I came into com, there was a huge microservices decomp project going on, moving from Node.js monorepo, moving to TypeScript monorepo to Go. But they were like a year and a half into it and there were zero meaningful production things running on Go.

The most important technical project is like moving off, off to go. And I was like, we're, we're not going anywhere. And so, so I canceled it as like, it's just, it's literally not working. Um, and so we just refocused on the monolith. And I think the, you know, at, at Carta, we, we also had done like this decom project, but I think similar problems. was a, the migration was like, you can't stay in the mono repo.

But there wasn't like, need to go to this pattern. It was just like, get out. Like we were evicting software from the monorepo, but we weren't like, yeah, was like, yeah, exactly. Right. And so people were just sort of locally inventing stuff. And I think it was, you just can't run a migration. You can't run a complex migration this way. But, but they, but they were trying and it didn't go well. So I paused that.

Carter Morgan (43:56)

It's like a bar closing. You don't have to go home, but you can't stay here.

Will Larson (44:18)

I was like, if you've already moved out, cool. But if you haven't moved out, don't move out. we won't, nothing will move out until we know where we want to go. And the reality is like, we, never, it never became a priority. Like moving out, like was not, was not really what the business cared about. At Uber, we did decomp. And so we were in a giant Python, like Flask app and we did decomp into

Python and go and node into like a bunch of like a mix of like larger services and smaller services. And that worked well because Uber again, that Python monolith was written for like, when there were like 20 engineers and then it was scaling when there were 200 engineers. By the time we got to 2000 engineers, like getting that build to complete and getting it to be reliable, particularly in like non-typed Python, kind of like that, that was like 2014, 2015 era.

It was just incredibly challenging to do. And so I was like, this is, so I learned how to do that. I led that project. I came to Stripe and I'm like, y'all idiots are in this mono repo. And my first thing was like, we need to move out of this. But as I started testing the idea, everyone there was like, you're an idiot. And we never did. We never moved out. never tried. At least until after, after I left there, there was like a bit of an attempt to exit. And then I think they came back in. And so, you know,

Carter Morgan (45:31)

You

Nathan Toups (45:32)

Thank

Will Larson (45:41)

Context dependent every time, but like in general, like my thesis would be it's super detailed dependent for a lot of migrations. I don't think they're worth doing. I think the status quo and improving it is almost always better than trying to do giant migrations unless you have like a really concrete problem you're solving. Like if your scale is increasing by like a hundred X, like a hundred, absolutely. Like what you're doing probably doesn't make sense anymore. If it happens like

pretty quickly, but for a lot of migrations, I'm just not a believer in, in companies' abilities to actually successfully migrate off. And there's a few things to think about there. I think one thing that companies like undervalue a lot is domain context. And so a lot of the domains we work in is that I think there's like, like sort of like a simplistic view over what we do, which is like, you just like write some like simple code, like your code is not even that complicated.

And that's like true. Like a lot of software, right. It doesn't have like high like concurrency, like constraints or something like that. But the actual complexities of how like healthcare works or how like FinTech works or how even ACH works in detail and representing that correctly. There's just like a lot of detail and there's so many ways to get wrong, particularly like FinTech where people are scamming you and trying to like break your systems. And, you know, I think people just like under respect, like how complex the software is.

And so to me, the big thing is usually if it's not important enough that you're willing to put like one of your best engineers on a problem for like six to 12 months to actually do it right. Big migrations are like underrated, but there's also like designing for like extensibility that I think is like huge. so one of the big things is like good interfaces that are like properly designed, I think allow you to change things under the hood.

really cheaply and really quickly. It can even do like parallel implementations that can run against each other, depending on the type of work you're doing. And so the other piece is I think, as we get better at the industry to the extent that the industry's improved, at least we can get better at it, like ourselves as technologists, it's just designing for like decoupling of the interfaces from the implementation a little bit better and better over time. And that goes like such a long ways in terms of, and GraphQL is like in its defense, I think actually pretty good at trying to support this sort of thing.

Nathan Toups (47:55)

Hmm.

Will Larson (48:03)

Or it is like a really convoluted complex, sophisticated router, right? That can do like kind of anything, which is like one of the challenges of it. It's just like incredibly capable. but it means you can like rip out a lot underneath and you could start like narrowing the actual parameters and fields you allow into like a more and more restricted version such that moving over to like a something else would be doable. Cause it's gotten so rigid over time by you're adding constraints.

It can actually do it. That's like probably how I think about it. Just dropping more and more functionality out such that eventually you can actually get there without having to do like the full massive migration up front.

Carter Morgan (48:44)

I think from my perspective, the book is obviously very focused on Silicon Valley, fang style companies. ⁓ Do you feel like there's value that a non-Silicon Valley fang engineer

can get out of this book or do you think that it's like you mentioned up top, like, yeah, a lot of people have the title staff engineer, but that's not exactly what it, it's not a one-to-one mapping of what you're talking about in this book. Do you think there's value you can get out of this book if you're not quite in that situation or preparing to be in that situation?

Will Larson (49:19)

So one of the goals of having it be like more story-driven or more like personal story-driven from a variety of different folks, is I think there's different scenarios of like what situation they were in. And some of those are more Silicon Valley-esque and some of them are a little bit less. Also like staffeng.com, we actually had like a number of people submit stories that are like absolutely not in Silicon Valley. They're just like doing pretty different things. And so I think...

Many people have gotten like stuff out of it. And in general, like I think that there's stuff there for someone who is far away from Silicon Valley, at least in terms of seeing like different models of how different people work. But to your point there, when you, there's no like real rule book in terms of like how everything works. And like to me, like what I'm most proud about in terms of staff engineer.

Is that I think a lot of people now have like at least a model to debate about. So I've seen a lot of jobs where they have like, we're looking for like a solver type. Like staff engineer, things like that, where it's given us like a little bit more clarity on as an industry, like how to talk about some of this. And that's, that's pretty cool. It's actually like shaping the industry in some ways. And that that's kind of the most interesting thing I think we can do in our work long-term. But no, I think, I think there's something in there for folks, but if obviously like the further you are away from the sort of environment.

Like if you're like one of my classmates from Kentucky, ⁓ he went to go work in like a gambling software company for horse racing. I think we're like three engineers there or something. And I think they had only ever worked like at that one startup, ⁓ or I don't know if you want to call this startup or not. And so like, yeah, if you, try to apply too much from that book or any book to that circumstances, it's just like such a particular thing.

You can't do it, but I don't know. My hope is, sort of what I've heard from folks is that it's been relevant to them, even if it's not been like perfectly like applicable and because of the size, the location, the job market or whatnot.

Carter Morgan (51:18)

You have, ⁓ sorry, go ahead, Nathan.

Nathan Toups (51:19)

⁓

no, no. I, I wanted to touch on briefly one of my, so I loved the structure of the book, but it was a real treasure to read all the stories at the end when I actually got to see like real, cause there is, I think one of the big arguments you make in the book is that, this, this role is very different across the industry and look at all the different ways it manifests itself. And, ⁓ it really helped have these like concrete examples.

⁓ What was it like trying to gather up these stories? And are there any that you maybe in retrospect wish you had been able to include in the book?

Will Larson (51:58)

I think, I think the stories are like what made the book, right? Like, I think if you take away the stories, the book basically doesn't exist. And I think, but it was also like the premise of the book was like, let's go. Cause I, I'd been again, like I was talking about is that then at Stripe, I've been telling folks like, Hey, like if you don't want to align with other leaders, like you can't get promoted. And they're like, no, no, no, no, that's just your opinion. I'm like, well,

I mean, one, like I'm your manager. So like my opinion is like very relevant to this conversation, but like even ignoring that it's like, I think I'm right. But I was like, okay, me telling you that I'm pretty sure I'm right. Isn't that helpful? Cause they were already like, I think you're wrong, Will. And so it's like, okay, I'm going to go take the stories of a bunch of folks and then grounded in that. So it's not just like me saying it. It's actually not me saying it at all. It's like, here's what a survey of many accomplished people has shown.

And it's not just the survey where you're like, yes, it matters or no, it doesn't matter. So best example, staff projects. Many people believe that no company will let you become promoted to become a staff engineer without doing the staff project. And a staff project is defined by like, you know, super hard or broad or something, some sort of like abstract, but like grants or requirements. What I found in the interviews is like most people never had a staff project.

Most people also like get into staff roles ⁓ by transitioning companies, like not many anyway. And those people in particular have never had a staff project, whatever that even means. And so I think there are just things that you can't make people agree with you, but you can show them all the stories. And I think the stories went a long way. Collecting the stories was...

Well, it was like an interesting experience. think parts of what I did there were like pretty annoying. That wouldn't be quite as annoying in a world like chat, GPT. But I think for example, the transcripts you get out of like a zoom recording and a lot of these are like zoom recordings. Then like did the zoom like audio to text in 2020 and just the tech wasn't as good back then. And so just like the transcripts were, they required a lot of editing is I guess what I'll say.

Nathan Toups (54:08)

Hmm.

Will Larson (54:09)

going from like the text transcripts to the actual like transcript that was used and reviewed with them for final approval, probably two to three hours per transcript, which is just like super annoying to do if you do like, I forget how many, but like 10 approximately in there. And there were also like interviews I did that like didn't make it into the book for whatever reason. And so it was time intensive, but I think it's honestly what made the book. And I think what I wanted to do

Nathan Toups (54:18)

Ugh.

Will Larson (54:36)

really particularly was to find people that people could connect with. Where like there's different types of staff engineers and if you find people who kind of connect with that kind of represents your path, like that's gonna mean a lot to you. Even if you don't like connect with to me in my writing directly, you'll connect to that author. So I really think that was a big part of it. And so for my most recent book that kind of came out the last couple of months, you know, Crafting Edge Strategy, I tried to do something similar, but it's hard to do.

because people kind of own their career story. So no one's going to be like, Hey, you're not allowed to talk about your career story. during strategies of like how a company actually approached a problem. Most people just like unauthorized to talk about that. And so figuring out how to do that in a place where most people just won't talk about it without like a level of like, ⁓ editing that like moves to a place of like, just like fiction, essentially.

That was a lot more challenging. So for this one, I ended up mostly working on my own experiences and just writing from that. Because at least I can be honest to a certain consistent degree in a way where it's harder because I can represent my own experiences in a way where it might be harder for you to represent your current company's strategy in a way that you actually find like totally accurate because you just aren't allowed to be totally accurate about places you work.

Nathan Toups (55:41)

Yeah.

Carter Morgan (55:54)

We have that same kind of funny dynamic with the podcast where a lot of our stories are just by nature two or three years out of date because we have to talk about the last company. You know, I'm able to be a little more open my current one, but in general, lot of our stories come from before that. It's not because we're not working on interesting things, folks. We just can't be 100 % candid about all that's going on.

Nathan Toups (56:11)

Right.

Will Larson (56:14)

A lot of stories from friends that reflect ⁓ very similar to what you're working on now. I understand ⁓ the dynamics for sure.

Carter Morgan (56:17)

Yeah. Well, go ahead.

Nathan Toups (56:18)

All right.

So,

real quick, so I walked into the book expecting some stuff. So I knew that you were gonna get into like tech lead, architect, ⁓ solver. I'm not sure I had a, for the archetypes. I don't know if I used that vocabulary word before, but right hand surprised me so much. I did not know this was even a career path. I thought it was such a cool opportunity for the folks who got to fill those positions. ⁓

I mean, how did you even know that somebody did this kind of job? Like, that's wild.

Will Larson (57:00)

Yeah, I think there's like a decent number of folks in these roles and kind of like a certain size company. think there are. So this happened after I left the Rick Boone who I hired at Uber. became like the he's, he's one of the stories in there. He was like the, right hand for the, think Matthew I'm forgetting Matthew's last name he joined after I left, but he was like the head of infrastructure. I think at, at Carta, I had a deputy CTO, Dan Fike, who's fantastic, who was sort of like the right hand model as well.

But at Stripe, there are a number of folks like Michelle Boo, who is in that story has subsequently become like a right hand to, think that the chief product officer, Will Gabrick, and there's like other people who've been in those, roles as well. So I do think, I do think they're relatively more common than you'd expect, but they, takes like a certain size company for them to actually show up. And it also takes like the leader knowing they want it. And I think a lot of leaders don't know the archetype exists sort of to your point.

So you didn't know they could like ask for it and it can kind of show up. But one of the, not to segue, but one of the things I've tried to do really militantly since I wrote that book was have like the most senior engineers of the company report to me as the head of engineering. And this kind of makes this more possible because they actually get enough access and visibility into what matters when they report that high up.

And that's kind of like a precondition to even having these roles like work as right hands is you have to have senior people and senior roles with visibility. And a lot of companies want their senior most engineers to report to line managers. And it's just really hard for them to ever evolve into a right hand. If that's the level of visibility you have.

Carter Morgan (58:44)

Well, Will, it's been such a pleasure having you on. And we always like to ask our authors before we leave, are there any books you'd like to recommend to the audience? I know you've obviously written several of your own and we won't shame you if you recommend several of them. But if there's also anything that inspires you or you think might be a fun read for our audience, we'd love to hear it.

Will Larson (59:03)

Yeah, okay. Let me just like check the bookshelf. So my bookshelf is mostly like things I think a lot of them are probably all of them on this part are kind of books I did research on for my last book. And then like the others are ones that I enjoy. But let's just give me a second. Let's see what we find.

Carter Morgan (59:06)

Hahaha.

No worries, you'd be shocked how many of our authors have done the exact same thing. They just turn around to their bookshelf and start plucking things off.

Will Larson (59:30)

Well, we can just do like a quick three. obviously shilling, shilling my own book, crafting engineering strategy. I think it's good. ⁓ did you haven't ever read a pattern language? It's, ⁓ a pattern language. So, a lot of like the, the, patterns like design software design patterns are based on this book. So this book's actually about architecture, but it's about like an approach to architecture where we have a consistent patterns that you like couple together and like build things out of. So you might have a.

Carter Morgan (59:36)

Yes.

No, haven't read that.

Nathan Toups (59:52)

Hmm.

Will Larson (1:00:00)

friendly room pattern, then you connect four friendly rooms into a friendly floor. And then you sort of like, have ideas like that, which are basically where a lot of software design principles literally were based on, on this book. Um, which I think it's just, it's really cool. I see how like, um, design patterns can come from like an architecture book that was, I don't even know when it was written. was written. All right. This book cover also does not know when it was written. So I won't go there.

Nathan Toups (1:00:12)

Wow.

Carter Morgan (1:00:23)

You

Will Larson (1:00:29)

The other one, you know, thinking and systems by Daniella Meadows, I think just like fantastic book. And I think it's super readable. It's not super, it's not super like mathy or dense or unapproachable. And I think just systems thinking is so, I've seen so many people get in trouble with systems thinking too hard at work. And so I think you can definitely system think too hard at work and get in lot of trouble, which is a whole different category of anti-pattern.

Carter Morgan (1:00:33)

We've read that. Yeah.

Nathan Toups (1:00:35)

Yeah.

Carter Morgan (1:00:42)

Mm-hmm.

Will Larson (1:00:58)

But such a great book, I think, and there's probably no book that's been more influential for me in my work than that one. So that's one I gotta call out.

Nathan Toups (1:01:04)

Amazing.

Carter Morgan (1:01:07)

Well, thank you so much for sharing those. And we always love them when we've read a book that an author recommends. I feel like we're a little ahead of the curve. ⁓ And then we always add the books that they recommend to our backlog. We've had several that have come from authors. Brian Kernahan recommended one called Recoding America, and that one made it into our backlog. Yeah, yeah.

Will Larson (1:01:23)

⁓ That's a good one. ⁓ I read that.

It's like a 2016 book. I forget exactly when it came out. It's a little bit older than I thought. yeah, it's a great read.

Carter Morgan (1:01:30)

Yes.

Yeah, Jennifer Paul, cause she was the deputy CTO of the Obama administration. So I think it's, she wrote it after she left, ⁓ public service and, and yeah, it's a, it's a great book. ⁓ well, well, thank you so much for, ⁓ joining us. We will include a link to a new book, Crafting Engineering Strategy, right? Yes. We will include the, Amazon link and, and the O'Reilly link, ⁓ below and then listeners, ⁓ we are partnering with O'Reilly now. And so.

If you share this podcast on LinkedIn or on Twitter, include a link and tag us. can tag us on LinkedIn. We have a company page for Book Overflow. Or if you tag Nathan and I directly, ⁓ the first 10 people who do so, O'Reilly has promised us that we can give you a free copy of the book. If you're located in the United States, you can get a print copy. If you're elsewhere, then you'll get an e-copy. ⁓ So we're excited about that. again, Will, such a pleasure to meet you.

And we can't thank you enough for coming on the podcast.

Will Larson (1:02:35)

Thanks so much, really appreciate it.

Carter Morgan (1:02:37)

All right. Well, we'll see you around folks. ⁓ at will, do you have any social media you want to plug? No, not so much. Well, well listeners, you can always find us. can email us at contact at book overflow.io. I'm on Twitter at Carter Morgan, ⁓ the podcast on Twitter at book overflow pod and Nathan and work with his consulting agency is at rojo roboto.com and rojo about.com slash newsletter. It's where you can keep up with Nathan's newsletter. Well, such a pleasure and listeners we'll see you around.

Will Larson (1:02:43)

I'm good, I'm good. You can find me if you want to.