Cope is Not a Strategy - Crafting Engineering Strategy by Will Larson

Carter Morgan (00:00)

Will Larson encourages us to be easy on ourselves and say, hey, this might have been the right strategy at the time. But as it's gone on, it's no longer the right strategy. And we talk about that with code. You say software engineering is code over time, and systems evolve, and we tried to do the best we could. But isn't there a lot of hope in that?

Hey there, this is Book Overflow, 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 am Carter Morgan and I'm joined here as always by my co-host, Nathan Toups How are you doing, Nathan?

Nathan Toups (00:45)

Doing great. everybody.

Carter Morgan (00:47)

Well, make sure to like, comment, subscribe wherever you're at. Join our discord. The link for that is in the episode description. We actually just passed 12,000 subscribers on YouTube, which is pretty neat and another fun little YouTube milestone. Our latest video with Carl Brown is actually now our most second, our second most popular video on YouTube. ⁓ Dthrone Martin Fowler, which we were texting Carl and he was pretty, he was very happy about the company he was in. was looking at his video. He's like, dang, like I'm, I'm up with Brian Kernighan Martin Fowler, John Ousterhout, Bob Martin.

Brian Kernighan is still the number one, but who knows? Maybe Carl is coming from. Pretty fun milestones, huh, Nathan?

Nathan Toups (01:21)

Yeah, pretty awesome. It's I love it that our guests, which were something we never I mean, we never imagined that people would actually become coming on our show, especially after. Yeah, and, you know, I think I think we've gotten 22 authors over the like 40 plus books that we've read, which is a pretty amazing rate, but there are overwhelmingly the most popular episodes typically. Right. So, yeah, we love it. It's something that's really enriching that we can bring to you all.

Carter Morgan (01:31)

We'd hope we'd get like maybe one or two.

Yeah, yeah.

Nathan Toups (01:51)

And yeah, I hope that we have many, many more.

Carter Morgan (01:55)

It's funny, they are overwhelmingly the most popular episodes on YouTube, but our audio is much less consistent. We've seen our audio just tends to grow steadily week over week. YouTube, we get these very spiky, which makes sense. YouTube kind of lends itself more to virality.

Nathan Toups (02:10)

That

is true. mean, I guess it's, you know, our podcast, which I love our podcast listeners. ⁓ You're the most consistent folks who show up. I really appreciate that you're sharing your life with. I mean, we're letting you're letting us share our life with you, I guess. And yeah, it's a much more like the, I guess, newsletter sort of model where you accumulate an audience over time. And so, yeah, that's great. I think some of the best participants in our discord are actually our podcast listeners.

Carter Morgan (02:30)

Right.

Nathan Toups (02:39)

So, you I think we have a special relationship with those folks and yeah, please keep listening.

Carter Morgan (02:39)

Yes, yes.

Well, absolutely. And we're excited. Today we're going to do part two of three of crafting engineering strategy by Will Larson. But before that, we actually have something more important we need to talk about, which, and this not in the notes, I'm surprising Nathan with this right now. I must give my spoiler free review of Project Hail Mary. Cause I saw it. ⁓ We're recording this on Friday. I actually got an early screening on Monday. You're going to hear this in a couple of days on your Monday. Yeah. Awesome.

You guys, if you listen to the Project Hail Mary episode, I'm a big fan of the book, one of my favorite fiction books of all time. Very, very faithful adaptation. ⁓ The few things they had to cut or tweak a little, I totally understand. There even a small change they made that I thought was better from the book than the movie. ⁓ So overall, I the book better. The most emotional parts of the book hit better in the book than in the movie. But Ryan Gosling kills it. Very fun, very funny, very heartwarming.

Nathan Toups (03:27)

Cool.

Carter Morgan (03:38)

and an excellent watch on the big screen. So from one of the biggest fans out there, big recommend, go see Project Hell Marion theaters. All right, and with that, let's talk about Crafting Engineering Strategy by Will Larson. Like I said, part two of three. And this is actually really interesting. Next week will be interesting because this is Will Larson. He does this in a lot of his books where the first half to two thirds is ⁓ the material and then the back third or so is

case studies or interviews. So staff engineer was interviews with a lot of staff engineers. And then this is case studies about how to kind of apply engineering strategies. So we finished out the material and read two of the case studies and next week will be just case studies. Let's introduce you to Will Larson and the book just in case you're listening to this for the first time. For Will Larson, our author introduction we have, Will Larson has been an engineering leader and software engineer at technology companies of many shapes and sizes, including Calm, Stripe and Uber.

He grew up in North Carolina, studied computer science at Center College in Kentucky, spent a year in Japan on the JET program teaching English, and has been living in San Francisco since 2009. He writes frequently on his blog Irrational Exuberance at lethane.com. And for our book introduction, we have good decisions are the core of creating software and strategies the art of reproducibly making good decisions. Crafting Engineering Strategy explains how you can improve your organization's decision making both as an engineer or as an executive, grounding the approach and concrete examples from real companies.

So finish the quote unquote material, read some case studies. ⁓ Nathan, give me your thoughts on ⁓ our, I guess, part two of three.

Nathan Toups (05:16)

Yeah, so I was I was a little worried with the way that we're breaking this up because it does it gets into case studies. I was like, man, is next week also going to be all case studies? But actually, there's a there's a closer. So I do think that, yeah, I didn't know I was like reading over the chapters for this to prepare for this episode. ⁓ All I can say is this book delivers. So we got through all of the made the major five sort of pieces of what he calls a good structure.

Carter Morgan (05:28)

Okay, there we go.

Nathan Toups (05:44)

to strategic planning and strategic thinking. And then this week we kind of, we transitioned into all of these ideas on, ⁓ but what is your writing strategy and what is the goal of these parts? And it's just, it made it all make sense. And I think that's what I'm excited about talking about today. And then straight from that, he's like, hey, you're not gonna learn all the way unless you see some like real world examples. And even I think it's the four or five case studies that we touch on, they're different enough.

that even though you're someone's strategic planning inside of a company, I'm like, oh man, at this point in time, this really was a problem and you really did need to take this new approach. it's like, it's actually like, if I was working at Uber at this time and we were trying to approach this type of problem, I would have felt in very good hands, right? And so I think that's where I was kind of not looking forward to the case study part, I'll be honest. I was like, got through this and I'm like, oh man, I'm gonna have to read.

We both were talking about this. like, we have these two case study chapters. And then they were just as easy to read as the other parts, right? Yeah, and so, I don't know. What about your thoughts?

Carter Morgan (06:50)

100%.

Yeah, I think this was our now our second Will Larson book. And Will Larson, I'm willing to say is one of the most talented software engineering authors out there today. At least, you know, as far as writing software engineering books, it's funny because we just read Project Hail Mary, which is written by a software engineer. And I actually picked up based on our episode. Did we mention this, the episode with Carl Brown? I this just might've been us texting him three body problem you had recommended Nathan or was that that was in the episode with project Hail Mary. Anyhow.

Nathan Toups (07:20)

Yes, yes. I think I brought

it up in the Project Hell Mary episode, yeah.

Carter Morgan (07:26)

So I started reading that, which you pointed out is also a software engineer turned author. So I've been enjoying a lot of fiction written by software engineers. And so I feel like I have to put that caveat, which is Will Larson, I love you, but I think Andy Weir's work, I'm a fan of more from a pleasure perspective. But as far as technical books, Will Larson kills it. He's very, very talented. He makes writing look very easy. You read this and you're kind of like, why are you, what's so?

Nathan Toups (07:30)

You

Carter Morgan (07:53)

challenging writing a book like this and then we've just read a lot of books and we've read a lot of books by some very talented people and It's tough. It's tough to write a book that flows as well as this one does ⁓ And I think a book like this you write a book you title it crafting engineering strategy So easy to make this very ivory tower very theoretical Will doesn't do that in the slightest. It's a very very grounded ⁓ You can tell this comes from someone who has done this a lot and who takes it seriously and the case studies that we read today

⁓ just serve to, it only helps that point. It makes it go from, these are all my wonderful ideas about how one might crafting and craft engineering strategy to I've actually done this. Here are some examples of how I've done this in the past. And, ⁓ I think what you said, Nathan is great. Like if you were under his leadership, you'd feel like you were in good hands. And, I think for anyone aspiring to be engineering leader, that is the feeling you want to invoke most in your employees. And so.

Nathan Toups (08:50)

Right.

Carter Morgan (08:52)

This is the book you gotta read. Let's take a quick break and then we'll be back with our full discussion. Okay, we're back. Let's talk just, yeah, let's talk about the book. We might go chapter by chapter, we might not. We can kind of just talk about what stood out to us the most. Nathan, why don't you start? Our first chapters, maybe 11 and 12, we've got writing, readable engineering strategies, and bridging theory and practice. That wraps up part.

two of the book and then we enter part three refinement tools. Anything stand out to you here?

Nathan Toups (09:24)

Yeah,

yeah. Well, I thought there's a couple of things. ⁓ We definitely, and I'll tell you, we haven't talked about this too much in the episode, but we've back and forth and been like, we got to put this in the backlog, this book on the backlog. There's one book I think he, it was called Don't Make Me Think, which is a Peach Pit book. I knew of this book, ⁓ and it's talking about how it's a Steve Krug, ⁓ it's a classic book, I've heard of it, ⁓ basically on user interface design. Like I shouldn't have to,

Carter Morgan (09:37)

Yeah.

Okay.

Nathan Toups (09:54)

low cognitively, the default correct thing should be completely obvious, which takes time. It takes a lot of time and energy. And he said, let's see, the ideal format for this first case is generally at odds with the other two, which is frequently the reason why strategy documents struggle to graduate from brainstorming to policy. And I think he's talking about the transition. I guess I need to give a little context. Writing structure inhibits reading, right? So, ⁓

He goes into this idea that if the discovery and all these ⁓ refinement and the whole process that you do to construct a good strategy, you typically need to invert that structure for the reader. So while we go through these discrete exploration phase, diagnostics, refinement, the way you present it in writing is actually inverse. You really want the TLDR where you say, hey,

here's our policy, like here's how we're gonna execute. And then you justify it. know, okay, we did these things. And you go through and he makes this really good argument. And again, you can see that this is probably a glimpse of how his writing is so good. He probably does this really structured way of getting all of his thoughts together and then goes through this sort of like refactoring phase where he said, you know, I'm gonna invert this so that the value that I've refined out of this goes first. And ⁓ I don't think this is...

focused on enough, Like inverting the document structure for reading. And he basically says it should be, it's not a full inversion, right? So the order that we build a strategy, and we talked about this last week, is there's an exploration phase, there's a diagnostic phase, you refine your findings, you talk about policy, which is like the things that are, what does the strategy require or allow? And then the operational part. What he recommends for the writing the document, so for the reader,

is that you do policy first, then talk about operations, then you justify all this with your refinement, diagnostics, and exploration. So it's sort of like, it's an almost complete flip where policy and operations stay in the correct order, but at the very top. And I'll tell you, after we read the case studies later, this is absolutely correct. This is absolutely the correct way of doing it. ⁓

Carter Morgan (12:11)

Hahaha.

Nathan Toups (12:13)

And yeah, I thought it was completely justifiable. At first I was like, maybe that sounds fine, but no, it makes a huge difference.

Carter Morgan (12:21)

Yeah, I really like the distinction he makes between academic writing and professional writing. ⁓ Basically saying, how does he describe academic writing? says, academic essays present evidence to support a clear thesis and generally build an argument forward toward a conclusion. Some business consultancies train their new hires in business writing, blah, blah. Says, well, academic essays want to develop an argument. Professional writing is a bit different. Professional writing is typically has one of three distinct goals. Refined thinking about a given approach, seeking approval from stakeholders or executives.

or communicating a policy to your organization. And he says, the ideal format for the first case is generally at odds with the other two. And that goes exactly what you're talking about, Nathan, with this idea of inverting it. And when you're reading the case study, he is saying that. He's like, hey, if you want to understand what the strategy is, and the high level, like, start at the beginning, what if you want to understand the thinking that led to the strategy, go reverse? Do I have that backwards? No, that's correct, right? Yeah, that sounds right.

Nathan Toups (13:19)

I think that sounds right. And if it's not, roast

us in the comments, right? ⁓

Carter Morgan (13:22)

Yeah, roses in the comments. Come on, guys. Hey, we read the book.

⁓

Nathan Toups (13:26)

Yeah, and the other justification on this too, goes, zooming out a bit, there's a classic lack of user empathy problem. The document's authors are so deep in the details that they can't put themselves in the reader's shoes. And I think this is that curse of knowledge thing, right? Like once you become a domain expert, even if it's just from a small research spike, and you've seen this, right? You've probably done this in a meeting. You've probably been in a meeting.

Carter Morgan (13:37)

Yeah.

Nathan Toups (13:48)

where somebody's talking so over your head, so abstractly, that you've no freaking clue what they're talking about. And you're like, that sounds right, but it's, know, and so it really is from a user empathy standpoint, you need concrete ways of justifying, you know, hey, I'm thinking, I'm arguing that this policy is the best policy. Now that might ruffle some feathers and it's okay. If they lean forward and they go, my gosh, finally, someone's saying the quiet part out loud, or we really need to do this, or.

Carter Morgan (13:50)

Yes.

Yeah.

Nathan Toups (14:18)

they might

this really respond to be like, this is a disastrous idea. There's no way it's gonna work. If you can get that level of engagement, you're gonna get someone to read the rest of your document, ⁓ But yeah, and if you start soft with the exploration phase, you're like, ⁓ well, here's all the domain of problems. And here's all the things that we have. You're like, no, if you've gotten somebody to get through accepting or rejecting policy, accepting or rejecting the ⁓ operational side of it,

Carter Morgan (14:28)

Yeah.

Nathan Toups (14:47)

then they're gonna wanna dig in, either to build a thesis for why you're so wrong. They're gonna look, your exploration is completely flawed. You didn't even think about this. didn't, you know, like, that's great. It's the kind of engagement you want. ⁓ And so, yeah, I, I really, and again, I'll bring it back to the case studies. It's funny. One of the case studies was like an Uber case study on how they can do self-service, because they're growing so quickly. I think they were doubling the software engineering team every six months. Yes, the thing was is that,

Carter Morgan (15:08)

Yeah, yeah, like service provisioning.

Nathan Toups (15:14)

And we'll talk about this with Wardly Maps later. But everything in the software cycle, we're trying to get towards commoditization. Commoditization is literally stuff that's just so obvious that you don't have to put in a bunch of engineering effort. take something off the shelf. Most organizations are not going to build data center infrastructure with an abstract API. You're going to go get a cloud provider. So AWS or Google Cloud is commodity at this point. You just kind of

table stakes, you get Terraform. But if you go back to where Uber was solving these problems back when they were doing it, they were like, well, there's this emerging trend with Kubernetes, and here's Mezos, and here's all that. And it was not a solved problem. Meaning, if they wanted to use some of these cool patterns, they actually had to build custom software to do these cool things. And yes, they were correct strategically. But from the execution standpoint, they had to do special stuff. They had to write this whole strategy document as to justify why this was the trend of where things are. And you look at it now, and you're like,

Carter Morgan (15:58)

Yeah.

Nathan Toups (16:13)

This is so easy, right? Like you just, it's a few, if you're gonna even do click ops on Google Cloud or AWS, you literally just like turn on a Kubernetes cluster and, you know, do a few things. ⁓ But I loved this, because again, it gives you this like little time capsule that you can like travel back in time and see how an engineering team was trying to approach a problem. anyway, surprisingly fun to read ⁓ for me.

Carter Morgan (16:15)

Yeah, yeah.

Yeah, yeah.

Yeah, I appreciate these kinds of like, retrospectives necessarily, but like you said, traveling back in time, I even had that thought when we were reading his ⁓ biography, it says he's lived in San Francisco since 2009. I don't know when he kind of broke into the tech industry, if that was in 2009, or if maybe he had worked elsewhere and then moved to San Francisco, but I felt like, wow, 2009, like that's right, you know, kind of the thick of the recession, moving to San Francisco, like interesting, like I'm not.

familiar enough with like what big tech culture was like back at the time. I know it wasn't as impacted by the recession of some other industries, but still.

Nathan Toups (17:11)

So I have a glimpse, even though I wasn't

working in Silicon Valley, my sister, my little sister is like seven years younger than me. So she's in her mid 30s at this point. And she had just gotten into San Francisco Art Institute. And I'd go visit her and I would go to conferences and stuff from time to time. So I actually got to see the glimpse of what Silicon Valley and San Francisco in like 2010 period.

2009, 2010, 2011, the transformation of getting out of the recession and this sort of abundance that was in place, Twitter was, Twitter started in 2007, if you, I think that that's about when. 2006, 2007, I think it became more, you know, at least more ubiquitous. But there was like an excitement and a youth and like, obviously there were still like problems that cities have, but it's very different vibe than it is.

Carter Morgan (17:51)

Yeah, that's roughly it.

Nathan Toups (18:08)

now. yeah, and so like, I don't know, there was like an, at least my experience of it. And again, I was in like my mid or, you know, my early to mid 20s. So maybe that was coloring it as well. No children, you know, all this stuff. ⁓ But what a cool time to go to San Francisco. So I guess what I mean, like the upside of that money was free. All these startups, these unicorns are popping up and he got to work at a decent number of them. And so like, it's really kind of cool because these companies were

Carter Morgan (18:09)

interesting.

Yeah.

Nathan Toups (18:37)

shaping. So there's the big tech companies like the thing. And obviously they're setting a lot of the agenda of values as far as how you do stuff. Kubernetes came out of Google, but lots of really important projects, open source projects were spinning up out of dig and Uber and Yelp and all these like companies were making these open source projects and kind of like giving engineers a way of expressing ways that you could build stuff in public. ⁓

And I don't know, there's just a lot, I just remember a lot of like kind of cool things popping up all the time. And so getting a glimpse on this side of being like, oh wait, there was a strategic plan under the hood to kind of think about this was cool. This fits, oh yeah, go ahead, go ahead.

Carter Morgan (19:20)

Yeah.

Well,

was gonna, you go, you go ahead.

Nathan Toups (19:27)

Oh, I was just gonna say, this actually is a nice bridge. The next chapter is called Bridging Theory and Practice. And again, this chapter happened exactly when it needed to. It's like, hey, everything up to this point has been pretty ivory tower, right? Like, okay, we have this formal process, this is how you write a good one. And then he's like, there's a lot of stuff when things like...

writing definitive documents or ⁓ doing strategy despite unrealistic timelines, which is like what every startup you've ever been in, right? ⁓ And so there's a really good advice on like, hey, what's the right level of touch? Like how formal do I get or how do I evolve this thing as where, you you're in a chaotic environment or, you know, you're trying to form strategy, but you're not an executive, right? Like there's all these like kind of crazy

Carter Morgan (20:00)

Yeah, yeah.

Nathan Toups (20:21)

things and it's just real good, practical, documented, you know, just stuff in this section.

Carter Morgan (20:28)

Yeah, I wanted to comment on that, ⁓ where he talks about using strategy as a non-executive, because I mentioned last week, I'm like, think you can only do as much strategy as your boss will allow. And he would kind of push back and said, well, I don't know about that. ⁓ I just want to quote verbatim here, because I love these ⁓ couple of paragraphs. Some engineers will argue that the only valid strategy altitude is the highest one, the executive level, because any other strategy can be invalidated by a new higher altitude strategy. They claim seem.

teams simply cannot do strategy because executives might invalidate it. Some engineering executives argue the same thing, claiming they can't work on the engineering strategy because the missing product strategy or business strategy might introduce new constraints. I don't agree with this line of thinking at all. To do strategy at any altitude, you have to come to terms with the certainty that new information will show up and you'll need to revise your strategy to deal with it. When it comes to using strategy, effective diagnosis trumps authority. At least as many executive strategies are ravaged by reality's pervasive details,

as are overridden by higher altitude strategies. The only way to be certain your strategy will fail is to wait until you're certain that no new information might show up. And I really like this. ⁓ It kind of reminds me of Made to Stick where they say like, they list like all the traits that make a story sticky. And they say, so do you have to come up with these stories? And they say, no, you need to be good at spotting them in the wild and then using them effectively. I kind of think about that.

It's a little similar here where one of the advantages you have if you're at a lower level is you are just closer to the action. And when he says effective diagnosis overrides, you know, any sort of planning or strategy writing. I think if you're closer to the action and if you're, and particularly if you're most concerned with the needs of your team, the strategy you will try to implement for your team is going to be

hopefully more effectively diagnosed than strategy that comes from a much higher level. Now, there are some things you just can't change. If your organization has decided that you have a TypeScript monolith and you must live in the TypeScript monolith, like any sort of local team strategy to break you out of the monolith might not apply, right? But if there are strategies about, you know, ⁓ more effective testing or

incident resolving or you know how to handle on-call responsibilities anything like that like That probably can be handled more effectively at a local level because you can diagnose it more effectively

Nathan Toups (23:02)

Yeah, I think that it's like, know, to say that you can't do this unless you have this perfect environment is a cope, right? I think he makes a really compelling case for this. And again, worded it much better. My instinct was that, I actually, you know, I disagreed with your assessment last week, but I didn't have the clarity of thought or the expression or the experience that Will Larson has had. And I think he makes a really nice argument that you will never have enough information

Carter Morgan (23:11)

Right, right.

Nathan Toups (23:31)

There's always gonna be new information that's coming in that changes what's going on. so learning how to craft engineering strategies in this constantly moving environment is the skill that you have to work on, right? And it's okay if it's wrong. And honestly, as we see here, and we see with a lot of software, when we write software, we can't know every way that the business is gonna use the software in the future, right? We do our best effort to solve the problems in a maintainable way, a testable way.

⁓ Software engineering is code over time, right? I mean, that really is what we have. And this frames this in a way that I think helps a software engineer think about something that is actually, we actually are set up for success here. We're doing this all the time with the way that we write code or the way we think about product development. ⁓ But strategy is this sort of like meta systems thinking framework. And again, we'll get into this with the case studies, but.

You can kind of see how Will always looks for those exponentials, right? He goes, OK, we have this problem. We're not able to do this thing fast enough, but we also know that we're going to hire more people and hiring more people actually makes it worse. So what do we have to fundamentally change so that hiring more people doesn't make it worse because we know we have to hire more people? Right. So you basically make this like diagnostic and you're like you look at it go, yeah, obviously there's some fundamental shift in how

your provisioning resources has to change or you're gonna screech to a halt. And he gives evidence of like, here's the number of tickets that are created, but here's the number of tickets that are closed, right? And there's like, ⁓ there's not a linear correlation between the two, which again, shows these problems. I think, you know, even if in that assessment, they make a hypothesis that says, if we do this, then it'll solve this problem. And then they're wrong. It's okay. You just change the strategy.

Carter Morgan (25:09)

Right.

Nathan Toups (25:27)

We have, you know, that's your next strategy. ⁓ we thought this was going to actually fix it, but actually it turns out that there's this secondary thing that, you we didn't know about.

Carter Morgan (25:34)

Okay, let's talk a bit about COPE, because I've got some thoughts on this. ⁓ One, we talk about engineering strategy and like, yeah, engineering strategy has to evolve. actually think, I was seeing someone on Twitter talk about like, one of the reasons when you want to like create a startup idea that you want to try to focus as much on like any sort of emergent technology as possible, whether that's, know, LLMs or VR or, you know, the internet, the iPhone, whatever, is that the whole venture capitalist ecosystem is designed just to

Nathan Toups (25:37)

Okay.

Carter Morgan (26:03)

take over any sort of business idea and to judge it worth funding or not worth funding. And so if you have an idea that doesn't capitalize on some sort of emergent new technology, the odds that a venture capitalist has already looked over it and decided this won't work or funded it and it didn't work are much higher. That's not an ironclad rule. I think Airbnb is actually a great example of like this is a business that was invented like 2009, but there's no reason Airbnb couldn't have been invented in say 1999 necessarily.

Right? Like, sure, phones made it easier, but like the Internet is really what made Airbnb possible. So there are counter examples, but kind of similarly, a strategy. If there were like, or it is actually kind of the inverse of strategy, right? Which is that like, if there were some sort of perfect engineering strategy, right? There are so many software engineering leaders out there, right? Someone would have created it by now, and it would just be the time, you know, time tested strategy that we all use.

But that's not the case. Instead, we find we have to keep creating new strategies. And Will Larson encourages us to be easy on ourselves and say, hey, this might have been the right strategy at the time. But as it's gone on, it's no longer the right strategy. And we talk about that with code. You say software engineering is code over time, and systems evolve, and we tried to do the best we could. But isn't there a lot of hope in that?

I say that because right now we are in the middle of a big re-architecture of our system. And

I look at the original system and it's not the worst code base I've ever seen. We had some kind of fundamental constraints with it, but there are some things I look at where I'm like, you know what? Someone with a little more hair on their chest wouldn't have made these mistakes, right? They would have built this thing correctly from the beginning and now we wouldn't be in this mess. And so it kind of the same thing with strategy. can say like, well we pivoted, but then we pivoted again and we pivoted again. Like, look, we're just doing strategy. It's just evolving over time. But at what point do you just say like,

We made the wrong decisions. This was a poor move. And if we had had some sort of knowledge or been more experienced or more talented, we would have gotten it right the first time.

Nathan Toups (28:15)

I think there's a survivorship bias. ⁓ Well, first of all, we will make bad decisions. I think that that is totally possible that, yeah, right, right. But we look back and go, ⁓ what was I thinking? Or it could have been, you know what? Five nights of skipping sleep and these crazy deadlines of trying to onboard this person and I was writing code like a drunken sailor and that's just how the code is and that's what we're living with right now, right? ⁓ Or, yeah, hey.

Carter Morgan (28:20)

Right. Maybe you will.

Nathan Toups (28:43)

We didn't have the right talent at the time. And this person is incredibly capable in this area, but they were kind of out of their scope. We had some Dunning-Kruger problems, right? But I don't think that all that does to me is beef up the fact that there probably was a lack of formal strategy. Actually, this gets into chapter 13 really well. It's a good tie in. Strategy testing for iterative refinement. like chapter 13, I think in 14 and 15 are all in this sort of like...

advanced tooling for refinement section. And he goes, ⁓ if I could popularize only one idea about technical strategy, it would be this prematurely rolling out a strategy prevents you from evaluating whether the strategy is effective. And I think this kind of ties into that piece, which is like, hey, I have an idea. Let's just do it. I think large language models actually make this super cheap to do, ⁓ which is that if you don't give yourself the time to refine something and it's important,

Carter Morgan (29:32)

Yeah, yeah.

Nathan Toups (29:41)

strategically, right? Like this is gonna be a system that impacts a lot of future decisions. I think that taking that extra moment, that extra beat of testing this as low stakes as possible is really important. I think that there are some things where like this formal multiple strategy, know, multiple step strategy stuff doesn't make a lot of sense, but yeah, figuring out the data structures for your API server and ⁓ in like how you're gonna, you

access a bunch of data across, you know, entity types and stuff, probably needs a beat, right? Probably needs a little bit of thought.

Carter Morgan (30:19)

Yeah, we we've been talking about that a lot in an LM world where producing code is now much faster. I mean, how much time now needs to be dedicated to that upfront planning? I think I think we're going to realize that we are benefiting from some of that friction in the past because you get started on something and just because it's taking you physically wrong longer to write the code and you might be running into bugs that were more challenging to solve. But that's giving

There's time is passing and during that time passing, you might be discovering new things about the problem and a completely unrelated like unrelated to the code, right? Or, uh, as you're working through the implementation of the implementation is more difficult, right? Like you, cause like, that's the thing. It's like, if you're trying to write code and then you're trying to test that code and if that code is hard to test, right? That can kind of cause you to take a beat and you take a moment and you say, wait a minute, are these patterns correct?

Is this the right approach here? But with LLMs, you kind of just brute force everything. If it doesn't, if it's hard to test, I mean, just have the LLM take another pass or two or three at it, but then it kind of leads to unmaintainable code over the long run. Right. I think we've been benefiting from that friction in ways we didn't realize. Yeah.

Nathan Toups (31:41)

said this when Carl Brown was on, I called it a Dunning-Kruger powered tech debt machine, if you're not careful. So in the reason I say Dunning-Kruger powered tech debt machine is ⁓ that you don't know. It's very easy for you to use a large language model to take you out of your domain of expertise. You go, man, I don't know much about mobile app development. That's OK. I'll use Quad to help me out. And I do a first pass, and it looks pretty good.

Carter Morgan (31:47)

Yeah.

Nathan Toups (32:10)

Partly, it looks pretty good because I have Dunning-Kruger. Dunning-Kruger is this idea that I don't know what I don't know. Somebody who's probably built mobile apps for years is like, that is the worst structure. In six months, you're going to want to shoot yourself because all of the abstraction's wrong, or whatever. Because when I look at it in a domain that I am an expert in, like go performant go API servers or something, it's something where I actually can scrutinize the code quite well.

Carter Morgan (32:13)

totally.

Yeah.

Nathan Toups (32:38)

I'm like, ugh, I mean, you could do it that way. One of the things that we've done that's actually been really helpful, and it's a good use of large language models, is one of the clients that I work with, I'm a pretty big chunk of my time right now, we're doing AI augmentation for the whole team. We're trying to design how we use AI tools collectively. And we've been really settling on this thing called SDD, or Spec Driven Development. I don't know if you all have used this much at...

Carter Morgan (33:06)

not a ton.

Nathan Toups (33:07)

OK, so this is so cool because you basically write a spec that an ⁓ agent could follow. And what's also nice about it is it's this like ⁓ we have these FDR, the functional design requirements. We have ⁓ these high level architecture documents. We're putting really nice documentation, and it lives next to the implementation along with a plan and a task list. And I'm not joking. I will spend, you know,

hours sometimes, depending on the project, of writing a spec, getting all these ideas together, really, really figuring out how an agentic sort of like a markdown documentation. And that gets code reviewed by another human before we even write a real line of code. ⁓ Now, there are some things that it's easy enough that I'll do SDD and have the code sitting next to it. And it's just easy enough for me to do this. And as we critique the SDD, as we critique the documentation,

Carter Morgan (33:52)

Right, right.

Nathan Toups (34:03)

in the code review process, I'll actually rewrite the code that goes along with it. But I found that this is actually like, it gives me enough of that friction where I have to own this description of how the system should work. The way that I would break the problem down, the way that I would like do it in phases, and then the code that supports it, that ⁓ it's slowed me down in the short term, but it actually has given me like a really honest way to have a conversation where I'm not.

Carter Morgan (34:12)

Bye.

Nathan Toups (34:31)

because I'll tell you, I'm very against vibe coding, but under constraints, it's super easy to slip into it where you're just kind of like, eh, I don't really 100 % know what's going on here, but I also don't really care. then all of a sudden, the code base just slips into something that you're like, you you're basically doing open claw where, you know, you have no idea what's actually being changed as long as the quality gates or whatever are in place. And it's just not a world I want to live in.

Carter Morgan (34:38)

Right, right.

Nathan Toups (34:58)

But it's funny now that I think about it though, I think I'm gonna probably write some skills for our, because we write skills that the whole team shares. And that helps us with like the craftsmanship for the whole team. I think I might slip in, and those are code reviewed as well. I think I might slip in some of these principles from Will Larson on good strategy, because I think Will Larson style strategy along with our spec driven development is actually be like a good one, two punch that we will experiment with.

Carter Morgan (35:17)

Yeah, yeah.

Well, we can talk a bit about some of the specific refinement tools he recommends here. ⁓ There are two, systems modeling and Wardling maps. We talked a bit about, I think, both of these last week. We can talk about systems modeling because this actually comes from thinking in systems by, my gosh, Donna, Donna something? Danela Meadows, yes. ⁓ Yes, which is.

Nathan Toups (35:33)

Yeah.

Mm-hmm.

Yeah, Danella Meadows.

Carter Morgan (35:56)

the book we've read, I've been thinking, I'm too lazy to like assemble the manual data, but I really want the book overflow graph of all the, I want two graphs. want one, which books reference each other and then in our episodes, what books have we referenced back to? But I know, Don Almeida's Thinking and Systems, basically very high level overview of thinking and systems is that systems are comprised basically out of stocks and flows, roughly, a stock is some sort of resource.

that can build up and a flow drains that resource and moves it somewhere else. Very, very high level overview of systems. But he talks about systems modeling and says, hey, know, this can be an effective tool when trying to refine your ⁓ engineering strategy. ⁓ This is one where there are some scenarios where I see this as very, very useful. And there are some scenarios where

I think you could gravitate towards like this seeming a little made up. I think this is something that I would not reach for in every conceivable scenario. Now in the case study for the Uber service provisioning case study, I thought system modeling was very appropriate here. He basically said, this is how many services we have to provision. This is how many we close out with one engineer manually provisioning that or provisioning them. This is another with two engineers or three engineers. This is how we think.

Nathan Toups (37:12)

Mm-hmm.

Carter Morgan (37:25)

the amount will increase if we ⁓ continue hiring at the rate we have been. This is how the amount we think will increase if we double our hiring rate, right? ⁓ And it's kind of, it does make for a compelling argument, because you can kind of look and say, okay, looking at this system and knowing we can't hire anymore for our specific team, ⁓ this leads to the inescapable conclusion that we must build an automated way.

to do this. ⁓ That makes a lot of sense to me. ⁓ In less tangible problems like that, like this kind of screams to me, like if someone said like, I've modeled this system, but then it has like very fuzzy numbers. And if your stock is like team morale, right? Like I would kind of be like, what is going on here? And I would take your argument less seriously as a result. Will Larson does not argue for that. He does not say this is the silver bullet. If you don't have a systems model, what are you doing?

Nathan Toups (37:56)

Right.

Carter Morgan (38:24)

But I could see an engineer reading this and getting excited about the possibility of modeling a system. But I think first I'd encourage you to ask yourselves, do I have something worth modeling? Or do I have something that if modeled would yield ⁓ productive insights?

Nathan Toups (38:41)

I like in the section there, he gives him tools, which again, know, those are, unfortunately, those are the things that are gonna get dated in this book over time. But I will say also, most of the systems modeling books are also from like 20 years ago, which is, so we read Thinking and Systems, which actually came out in 2008, which that's newer than I thought it was in my mind. But oh, that's right, because I think this was written post, this was after her, after she passed away, I think these are like her notes that she never,

Carter Morgan (38:50)

Right, right.

Yeah.

Nathan Toups (39:11)

If I remember correctly, I think it was her notes and an unfinished book before ⁓ that her friends helped, you know, finish the publication of business dynamics, systems thinking and modeling in a complex world, which sounds, you know, very systems thinking he and then there's another book he mentions called Introducing Introduction to Systems Thinking by Barry Richmond. ⁓ The reason I bring this up is that the tools meant to work with those are, you know, they're a little bit older, but I think

it might just be that they're fine, right? It's okay. Not that many people do a formal systems thinking, formal modeling like Will Larson. I've very rarely actually seen this in the wild. Now I'm not in the caliber of companies that he's been in, but again, I think that these are super power tools. And one of the things that can be pretty overwhelming, I've tried doing modeling before and I've failed.

Carter Morgan (39:53)

Yeah.

Nathan Toups (40:09)

describing things well, and he actually says how to model. ⁓ Learning to model systems takes practice. So I'll approach the detail of learning ⁓ to model from two directions. First, by documenting a general approach, and second, by providing breadcrumbs for deep exploration of models developed in the book. And I think this is a really important thing, which is like, if you're learning to code, right, you don't wanna just spin up a React app as your first coding project.

you're probably gonna do something that uses like text input in the terminal that maybe deals with maybe, you know, popping ⁓ items from an array, you know, some really basic things so you can kind of get a feel for how like data structures work in programming. I think you need to do the same thing for modeling, which is model out some really simple things. Use some tools where you can model, even if it's literally, you know, draw by numbers type of thing, right? You're like, okay, here's the actual model. Can I build this? Like, do I understand?

And if you asked me to build this from scratch, could I build this workflow or whatever? He also gives you some really nice stuff like you can use these formal modeling tools or use ExcaliDraw, right? Like just start with Figma, Whimsical, any of these tools that are just like easy for you to get your hands on. They're not going have all the power tools or the other kind of cool things. You know, I knew a guy that uses something called C4, ⁓ which is like a formal way of describing

Carter Morgan (41:18)

Right, right.

Nathan Toups (41:34)

uh, complex systems. And he was a soft, he's a software architect and he actually loves this one called like C4. And the book here does not talk about these tools at all, but C4 is kind of interesting. Those who get into it, they're super into it. You can do code generation from it. You can do all these things. It's a beautiful diagrams and graphs. And for him, it was like super intuitive. I've like watch it, you know, pre LLM, just typing stuff out and writing these like beautiful complex things. And I tried it my one time and I was like, I'm an idiot. I don't know how to do anything.

Carter Morgan (41:55)

you

Nathan Toups (42:04)

what did I do with my life? I, you know, just like all those things came up and it's because I hadn't practiced. He's taken a lot of time and energy thinking about how to express his thoughts this way. And so, yeah, give yourself some patience, I guess. And ⁓ yeah.

Carter Morgan (42:20)

Yeah. ⁓

It's tough because as engineers, want to, we're naturally drawn to be like, this is a cool new thing. I don't know how to do this cool new thing. I should go and do this cool new thing. ⁓ But I'm with you. It's like, yeah, start simple. ⁓ And I think this is a good tool to have in your tool belt, but I would just caution patients. out of anything in this book, this was the one thing I read and was like,

Ugh, like if someone showed up with one of these to a meeting and it wasn't like iron clad, I'd be a little like, what are we doing here? Like, we're all busy. Like, how long did it take you to make this?

Nathan Toups (43:08)

And I will say, fortunately or unfortunately, mermaid is another common one, and you can embed those into GitHub Markdown. ⁓ And large language models will gladly generate you a mermaid diagram. And boy, are they ugly. Most of the time, I'm like, I'll at get it started, and I'll make some corrections. And I'm like, man, why did I do this? I'm just asking myself all kinds of questions in my life. That being said, I've seen other folks who use mermaid

Carter Morgan (43:20)

yeah.

Yeah.

Nathan Toups (43:38)

beautifully, right? So I think this is a skill set that I need to spend more time on. One of the things I did love about, again, talking about modeling, there's a couple of quotes. Models are input into a strategy, but never a reliable sole backer. So this idea of the model isn't the strategy, right? I think that's another way of expressing that. It should support, right? It should support these decisions that you're making. someone who's good at data visualization,

I'm always in awe of it. I've worked with lots of data engineers and data visualization folks. They're like painters with data, right? They understand which type of graph to show or what kind of things are in place. There's an art to it, even though it's scientifically based. ⁓ The other quote, the last one I'll say here before I pass the baton is, ⁓ what systems modeling isn't? love, again, you know me, I love like counterfactual stuff. And so,

Carter Morgan (44:31)

Yeah.

Nathan Toups (44:33)

When your model and reality conflict, reality is always right. I love that quote, right? It's, know, but the model says, you're like, no, doesn't matter. Like in reality, this isn't what's going on.

Carter Morgan (44:46)

Doesn't he,

he quotes Jeff Bezos here, doesn't he? Where Jeff Bezos was fond of saying, when anecdotes and data conflict, the anecdotes are usually right. ⁓ Which is a...

Nathan Toups (44:57)

There was that famous

one where he like everyone was like, ⁓ talking about the customer service numbers

Carter Morgan (45:03)

Yeah, they're like, yeah, customer service numbers are great. Like or, you know, yeah.

Nathan Toups (45:06)

And he's like, let's call him right now. And so he calls it

and he's like, he's like on hold for, know, they were like, you know, the amount of time you're on hold has gone down and he like, he's on hold for, you know, minutes or whatever. And ⁓ it sucked. And he's just like, okay, well, in this case, it wasn't. And I just called in and we need to fix this. So.

Carter Morgan (45:16)

Yeah, yeah.

Yeah, yeah,

I know. I think. ⁓

Yeah, I know there's that that's an interesting example right there because it's a little, I would be frustrated if my boss did that to me. Like if I were like, hey, website latency is, you know, like we have a P 50 of, you know, 80 milliseconds and our P 99 is 170 milliseconds. And then he's like, okay, let me load the website right now. And then it took three and a half seconds to load. And, but then we looked and it was just a spike, like a momentary spike at that, you know, right then.

And you're like, no, well, the website's obviously not working. So get to work on that.

So, yeah, but I do see a little more like, I've heard stories with like customer satisfaction, where it's like, ⁓ we're reporting customer satisfaction of 98%, but then you get an email from a customer that's like, hey, I had a really negative experience with this. And that leads you to ask a little more like, well, are we measuring customer satisfaction the right way? Or are we only, or maybe we are measuring it the right way, but the only people responding to our customer satisfaction surveys are the people who are satisfied, right? ⁓

Nathan Toups (46:26)

great.

Or is that 2 % you know is it just kind of like eh you know it's mostly fine but you know I don't know of a better tool and you know when it breaks it's kind of annoying or is the 2 % so bad that that's like all of your churn right like it's like you drop the ball never using this again telling all my friends never use it again like that 2 % is a very different 2 %

Carter Morgan (46:35)

Anyhow.

Absolutely. Right.

Yeah.

Well, let's talk about Wardley maps. a ⁓ that rounds out kind of the ⁓ official material, not official material, but everything before the case studies, right? Wardley maps. ⁓ Yeah, he's high on Wardley maps and the doctors are Wardley maps, Nathan.

Nathan Toups (47:32)

It's the white whale. It's the white whale.

⁓ What I'm about to is these two dimensional diagrams, they're very recognizable once you see them. ⁓ And I'll say there's actually some really cool web-based tools that are out for these now. But so basically you have two, the y-axis is less visible to the user ⁓ down to zero. And then as you go up, it's more visible to the user. So the top of this grid would be things like, I think they were talking about ⁓ AI enhanced documentation.

Carter Morgan (48:07)

I've got it right, right, right.

Nathan Toups (48:07)

platform or something. Yeah, so there's an

author and a reader, right? Like, those are your two sort and you can think of these as like archetypes or user types if you're in like the product world. ⁓ So these are the people using this. So whatever is closest to them on the worldly map is the most visible, right? They actually see this content creation interface, right? Or they read the content on your website, right? Or whatever. And then those things can live on a continuum on the X axis, which...

Carter Morgan (48:22)

Yes.

Nathan Toups (48:35)

Genesis, which means it's completely novel. The world has never seen this. You've created some brand new thing. You straight up own it. And then it becomes custom. You've customized something that exists. It's a product, meaning that this is something that you build that is unique product. And then commodity, commodity being that off the shelf, you don't even think about it.

twice, right? And so I think in this one wordly map that's like mapping AI enhanced document editing, a document reader would be under commodity, right? So it's maybe not, so the user reads content, maybe there's some like custom, a little bit of custom stuff that's like makes it pleasant to read, but the document reader piece that's like reading data off of your systems or whatever, that's probably just some library. You don't even think twice about it. It's your MDX rendering system or whatever, right? That is like,

Carter Morgan (49:10)

Right, right.

Nathan Toups (49:31)

taking interactive markdown and putting it somewhere. ⁓ Where maybe something that's like in this worldly map, a search index, right? Search indexes, maybe there's some novel way that you're doing search indexing because it's a large language model. You have to have a rag, databases and all this kind of crazy stuff. It's pretty custom, right? Like you've taken a lot of things and you've customized it to what works well for your workflow. So it's less visible, like not visible to the customer ⁓ because they're not thinking about your search index, but they are thinking when they type something in, just...

works, right? And so you kind of map all of the stuff out of all the things that you have that make your system work, the connections between them, and it helps you understand, what are the real valuable things? You can even describe these where teams maybe own certain parts of your worldly map system. And I don't know, it gives you this really nice, you also can give these flows, it's very common in a worldly map, where maybe we have like,

a document editor that's over here in like somewhere between like custom and product, right? And we want to maybe commoditize it. meaning over time, we wanna have, we don't wanna be running our document editor. We really just want it to be some commodity document editor. Like we're moving towards this direction. ⁓ And so that's the, one of the maps can also show like movement over time of like some part of the system. And, ⁓

And again, it actually, it's a really nice way of seeing the complexity of a complex system from a user-facing standpoint. And I think the point of a wordly map, at least my understanding of them, is that the more visible something is, ⁓ the more ⁓ weight that this user has, right? Like the way that that part of the system behaves. And there's lots of supporting invisible things that might be important to the business, but if you're not changing anything,

Carter Morgan (51:21)

Right, right.

Nathan Toups (51:28)

positively for the visible part, it's not really well understood. ⁓

Carter Morgan (51:34)

I hope to have the option one day to make a Wardley map that proves useful. I agree with the philosophy behind a Wardley map. I think this is like prime behind like the classic mistakes people, engineering organizations make, which is like, let's build our own markdown rendering engine, right? Let's build our own operating system. Let's build our own.

distributed messaging queue, right? And like you want to do that as an engineer because that's fun and because the constraints and the challenges associated with that are purely technical challenges and it's pretty easy to find like does this work? But like when you look at a worldly map and it's very much like how visible that is this to the users? I mean, it's ⁓ way down at the bottom, right?

And so, you anything that's down to the bottom, you should be pushing more and more towards the commodity side of things. so, to me, those feel like just good instincts to have as an engineer or an engineering leader. And a wordly map visually depicts those instincts. ⁓

Nathan Toups (52:36)

Yes.

Carter Morgan (52:57)

I'm just trying to figure out the scenario where like a ward lay map would be like really, really useful, right?

Nathan Toups (53:01)

Ah, so

we read team topologies. And what's interesting is from what I've heard is that version two of team topology is the one that we haven't read yet, actually gives a whole section on worldly maps when it comes to flow for teams. And so one of the things that they talk about, there's like a map overview showing which teams owns which capabilities, right? So one of the things that I think can help with a worldly map is you go, hey, our company is fixating on this part of the product.

Carter Morgan (53:05)

Yes.

Okay. Okay.

Nathan Toups (53:31)

but I'm warning you, it's invisible to the end user. And we are spending a tremendous amount of engineering resources because it's all custom code. And if you see like, hey, why isn't the infrastructure engineering team solving all these other problems? You're like, well, actually you've put search index on their plate and it's super invisible and super custom code. And it's like super labor intensive. If that's our secret sauce, this is why we need to maybe hire separately. so this idea of like,

Carter Morgan (53:48)

Hmm.

Nathan Toups (53:59)

What's occupying times for teams? What's core business? And again, it's a very strategic thing. And again, if you don't write a good one, it's kind of BS. But if you're trying to use it to help identify like, why are we stuck? Why is there friction? And so I think it's just, it can be useful. And I'm saying this from a theoretical standpoint, I've never used a worldly map in the wild, right? I've tried to start modeling. I'm actually working on a data project right now.

Carter Morgan (54:01)

I see, yeah.

Yeah, yeah

Nathan Toups (54:28)

where I do think that we've got a lot of moving parts. trying to, we have, there's this company that I'm doing stuff with, they're doing a bunch of stuff in Excel, very manual, super smart folks, but it's super labor intensive and error prone because you're using Excel and macros and stuff. And we want it, that's all under, you know, Genesis custom level stuff, super slow, the wrong people are working on it, you know, that could be doing other finance type stuff. And so what we, what I want to do is,

Carter Morgan (54:43)

Mm-hmm.

Nathan Toups (54:57)

a wordly map that shows the processes, what's visible and what's not, and then how can we move it towards commodity? And I don't know of a better way of visualizing it than a wordly map, even though I'm a newbie in describing this. ⁓ And so, yeah, it's not like solves all your problems. To me, it's really helps when you're talking about how you structure your teams, the things that you're actually building.

Carter Morgan (55:06)

Right.

Nathan Toups (55:23)

And then where are we spending our time? Are we spending all of our time on invisible things that are super custom? Or can we make our team more focused on the stuff that's right there in the user's face? And so, yeah, I don't know. It's interesting. when are wordly maps useful is actually an interesting section. And he's like, no tool is universally effective. And he said, wordly maps are extremely helpful at helping people understand a broad change. They're less.

Carter Morgan (55:46)

Right.

Nathan Toups (55:52)

helpful with details. And so, you know, I think that is, if you're trying to persuade folks to being like, this team is spending all of this time on custom code or this team is, you we have all these invisible processes with all these teams dedicated to these invisible processes, I think it can be super, super valuable.

Carter Morgan (56:09)

Yeah. And talking about how they help deal with change, he says, for example, in the early 2010 startups like Facebook, Uber and dig were all operating in physical data centers with their own hardware over the next five years as cloud-based infrastructure rapidly expanded, having a presence in a physical data center went from the default approach for startups to a relatively unconventional solution. Any strategy read in 2010 that imagine the world of hosting a static was destined to be invalidated.

⁓ so, know, you could see, you could imagine kind of building a wardley map of like, yeah, like you're, trying to reevaluate and be like, okay, we've been doing our own on-prem stuff for a while. We're to a data center approach. Let's take, let's take stock of the, the landscape, right? Let's figure out at this point, what has been commoditized, what hasn't been, and we'll probably see this with LLMs, right? We're like,

I bet there are companies right now that have spent a decent amount of time investing in these like agentic harnesses to really turbocharge their LLMs, which honestly have probably already been eaten by Claude Codd. ⁓ I think will only continue. I think now the big question is kind of like multi-agent orchestration, right? Because like you kind of have to do that to pay over the context window problems. ⁓ And about their companies out there right now, investing a lot of these kind of comp-

complex multi-agent orchestration workflows that I bet will be commoditized in three years max.

Nathan Toups (57:39)

Yeah,

anywhere that there's high pain but high value, those are on path to be commoditized. Again, perfect example is that you look at companies like Vercell. Vercell sits on top of AWS. So you could argue that they're charging a premium on type of it. And I think the way that certain workloads are set up, it would be super expensive. But if most of your stuff is scaled to zero, I don't want to think about my DevOps pipeline type work.

Carter Morgan (57:43)

Yep.

Yeah.

Mm-hmm.

Nathan Toups (58:09)

takes a lot of pain away and it actually prevents you from making a lot of bad decisions. I think the same thing is going to happen with like, there's going to be companies where you're going to do a brute install of some ⁓ agentic harness where, you know, you've got spend scale to zero serverless agentic tools where, you know, it's super safe, it's isolated, it's not going to take over your machine, it's not going to do these things, but it's going to feel just like cloud code local.

Carter Morgan (58:11)

Yeah.

Nathan Toups (58:38)

or whatever and ⁓ actually I just saw this recently, Claude just announced that they've got their own like open-claw kind of alternative where you can now use Claude code where it will, you can talk to it through like WhatsApp or Telegram. Wild, right? So again, and I would imagine that it's a much more measured way of approaching it where you don't have to like YOLO your whole life on a Mac mini. ⁓

Carter Morgan (58:55)

Yeah, yeah.

Nathan Toups (59:06)

these things are gonna go from being novel in genesis to commodity, right? I think that that's absolutely true. And that's true. Most, we read in the plex, Google had to figure out how to transition from a couple of servers in Iraq at Stanford or whatever into starting to provision data centers. ⁓ Most startups these days don't have that at all, right? Most startups these days are just gonna go pick a cloud provider and not have to deal with scaling.

⁓ infrastructure in writing and doing like custom data center design until they're pretty big, right? You don't have to worry about data centers until you're a big, big company now because of how easy it is to get that off the ground. And it used to be that if you, know, early 2000s, you had to have data center designers and all kinds of stuff to make your company work.

Carter Morgan (59:42)

That's right.

Well, let's talk just a bit about the case studies. We don't have a ton of time. ⁓ But we've kind of ⁓ talked a bit about them throughout the episode. ⁓ And obviously, the case studies are just ⁓ showcasing what we've learned in the book so far. ⁓ I'll just highlight again, I really liked the Uber service migration case study ⁓ talking about the need for, this was when Uber was in the ⁓ process of migrating off of their monolith.

Nathan Toups (1:00:01)

Mm-hmm.

Carter Morgan (1:00:27)

onto new microservices per team. And yeah, I thought this was a very effective use of systems modeling showing that like, hey, at this pace, like our current trajectory is unsustainable. We need a new way off of this. And this was also a really great case study showcasing ⁓ how to do strategy at a lower level. Now this is interesting because ⁓ the top level strategy was already set at Uber, which was like, we're

getting off the monolith or moving towards independent systems. But this shows how an individual team can be effective in accelerating a strategy by just making the actual operational parts of it easier. ⁓ And yeah, so mean, good case study. And we've talked about a lot of the concepts throughout the episode already.

Nathan Toups (1:01:15)

Yeah, and these things don't make a lot of sense for us to go play by play, other than sort of highlights. I will say it's, again, from a time capsule standpoint, there's a shout out to the tool, unless you know, you know, called Fabricator, and it's spelled with a P-H. ⁓ Have you ever run into Fabricator? Yeah, so I worked in one startup that used it, and I was just like, what? It's like a Silicon Valley lore sort of thing.

Carter Morgan (1:01:21)

Right, right.

I know of Fabricator, I never used him.

Nathan Toups (1:01:42)

folks who used it with success, but it's an alternative to GitHub for doing code reviews and stuff. you use it. It's got some really nice features that don't exist in GitHub. Like for instance, if I do a code review and I make a few little updates, it's super easy to see the diff from when I last reviewed.

somebody's code to where they made changes. So I can just see what they did in response to my code view. And you can do this in GitHub, but it's like not easy. ⁓ It's just super intuitive and basic. And it does a bunch of other things too. And it had a ticketing system. The only problem is it's like, it became an open source project and basically unmaintained. ⁓ But it's just funny because I was just like, yeah, I'm good old fabricator days. ⁓ But there's other ones, right? Garrett, there's a few others out there, but.

Again, most of these tools these days, you wouldn't just use the commodity version ⁓ of them. ⁓ Excellent Wordly diagram with that Uber one as well. I think they showed where they have like ⁓ Puppet plus Clusto. And I think Clusto is something that came out of the dig thing. And again, you'll see these little stories. And they're like, OK, these served us for a time, but it's not where we want to be in the future. And we want to move this towards serverless cloud provisioning stuff. ⁓

Carter Morgan (1:02:53)

Yeah.

Nathan Toups (1:03:04)

And so the wordly map kind of shows this invisible piece that's transitioning from product into commodity, right? And I think it's, again, it's a good way of backing up this, here's our strategy. We're doing all these things, it's gonna do this stuff, and it's also gonna reduce the burden of this one custom code base that we have.

Carter Morgan (1:03:24)

Well, do you want to talk about the next case study or I think it's a lot of the same stuff?

Nathan Toups (1:03:29)

Yeah, no, again, I highly recommend like, you've gotten this, if you've gotten this far in the book, if you listen to like what we're saying, these case studies are gonna be really familiar, right? I think if we had started looking at the case study and I didn't have a framework for thinking about what makes a good written strategy, I'd have been like, okay, this is pretty dry. I don't know what I'm looking at. But now that I have these tools and I'm like, yeah, this is well argued. Like here's the policy portion and you know, here's the diagnostics. And I understood why it's like,

set out the way it is. ⁓ They're fun to read. Again, I know that that sounds insane, but it's not. ⁓ These are good sections. I think there's a couple more case study chapters that we have, and then they're going to finish out the book with like, you know, where do go from here kind of stuff, which I think is going to be a nice arc ⁓ for next week.

Carter Morgan (1:04:20)

This is a I'm actually just reading right now because I was you mentioned you said Clusto came out of dig or was fabricator.

Nathan Toups (1:04:28)

No, think Clusto came out a dig at it. might, yeah, roast me if I'm wrong.

Carter Morgan (1:04:30)

I was like, no,

I was like, dig, whatever happened to dig. And so I was like, I knew, I know dig kind of had their big redesign and that, you know, that kind of drove all the traffic to Reddit. didn't realize, but just like two months ago, uh, the founder of dig, they've re-bought, they bought dig back from whoever purchased dig and like the fire sale. Um, and with the founder of Reddit and they launched two months ago and just like six days ago, they shut down again. Um, so poor dig.

Nathan Toups (1:04:58)

no.

Carter Morgan (1:04:58)

They said the bot problem was terrible. uh, anyhow, uh, sad little side note about dig there. Uh, let's, uh, let's move on. got as far as hot takes. mean, I I've given mine throughout the episode. think, look, don't make a systems model unless you're really confident. That's a good systems model. I think this is just like,

There, I read this great little essay on Twitter called Tool-Shaped Objects, ⁓ which is about this idea that like,

There are some objects which, or some, there are some quote unquote tools which are theoretically supposed to be tools and make you more productive, but are actually just fun to use. so basically the market for seeming productive is actually bigger than the market for being productive, right? He actually talks about like Farmville and says like, Farmville, like no matter where you click on the screen, your farm is gonna grow, right?

Nathan Toups (1:05:52)

yeah.

Carter Morgan (1:06:00)

And he was likening large language models to this, where he says, large language models are both a tool and a tool-based, or a tool-shaped object. ⁓ He says, a good sign for if you are dealing with a tool-shaped object is when you're talking more about how much you're using the tool than what you're building with it. And so that's thing with LLMs is it's both. It's like, we can build really cool things with it. But at the same time, you see people bragging about, I thought it was so bizarre when

I started handing out like those awards for like token spend. So that seems bad.

Nathan Toups (1:06:33)

Right.

Imagine the electric company

being like, this is your lifetime kilowatt hours usage, and you're like, ⁓ that is a...

Carter Morgan (1:06:41)

Yes, exactly right. Bizarre.

Worldly maps strike me, or not worldly maps, systems modeling strikes me a little about someone who wants to feel like I'm doing strategy. I'm being productive. I made this systems model, you know.

Nathan Toups (1:06:56)

Interesting. I definitely think

that you could, and he does talk about this at beginning, do not cargo cult with this. And I think that you're right. I think it's very alluring, or even Kyle Newport talks about this with a busy-ness theater, right? It's like if I act like I've got this stuff, but there's a famous thing to say, like fake it till you make it. Don't do that with strategy.

Carter Morgan (1:07:03)

Yeah, yeah.

Yes. Yes.

Nathan Toups (1:07:22)

Don't fake your strategy until you make it. If you don't have a good strategy to contribute that has a good model of how the world works, because one of the things that you're probably going to do is make a bad strategy that sounds very convincing. And that's a waste of everyone's time, for sure.

Carter Morgan (1:07:41)

Yeah, it's a, we are just in the middle of this big rewrite. And I just, keep kind of with the team, I've been trying to practice like, tell them and then tell them that you told them, right? And something I keep trying to reemphasize that like, listen, there's so much work to do here. We're going to be productive. Everyone is going to spend every day writing code and making some part of our system better. We're all smart engineers. We're just going to do that.

But are we building the right things? And maybe more importantly, are we building the right things fast enough? And one of reasons I harp on that so much is because I have fallen victim to this in the past. And that's why I gave Slow Productivity in 2024. I said that was my favorite book of the year because I felt called out in like this, oh, pseudo productivity is what he calls it, right? This idea that like you're doing things that like theoretically, like it's work and they're things that need to get done.

but is it actually moving the needle? so ⁓ just a word of caution on my end with any sort of engineering strategy is like, you gotta move the needle and don't latch onto like the easy part snacking as Will Larson would call it in his other book, Staff Engineer. ⁓ So not that Will Larson encourages that, recognizing that tendency in myself, I thought, you know, that's gonna be my.

Nathan Toups (1:09:03)

No, absolutely.

And yeah, I think the other one with LLM, somebody brought this up really well, which is that the similarity between LLMs and 3D printers, right? And I think I brought this up in other podcast episodes, which is most 3D printer owners end up doing, I, least this is what I've seen. They end up 3D printing modifications for their 3D printer. Like, oh, I need this clip so that this wire hooks out better, right? You end up using the 3D printer a lot for your 3D printer.

Carter Morgan (1:09:15)

interesting.

Yeah.

Nathan Toups (1:09:32)

⁓

Which is a lot like, I have all these skills that I've been working on for my large language model. you're like, okay. And then the other one is like, or you're just like, make your 3D printing tchotchkes, right? Like you're like, ⁓ you made a Iron Man mask, know, lifelike, the actual size of the Iron Man mask. You're like, that's cool. Like, I'm glad you did that. like, ⁓

Carter Morgan (1:09:51)

Yeah, yeah.

Yeah.

Nathan Toups (1:09:59)

I remember when the 3D printers came out and it was like, ⁓ yeah, manufacturing's gonna get distributed to everywhere and you're gonna be able to print replacement parts for your car and all this other stuff. I'm like, very few people actually do that. Even though 3D printers are amazing. I'm not discounting how cool a 3D printer is, but you actually have to be pretty skilled to be able to use one. And I think large-singular channels are a lot like that, where it's like...

Yes, anything is possible, but very few things are practical. And you really actually have to be pretty skilled to use them in an effective way.

Carter Morgan (1:10:38)

Well, what about you? You got any hot takes?

Nathan Toups (1:10:40)

Hot takes, man, wordly maps look super cool. At I think they look super cool. They are so hard to write. I've just tried to make some and I'm like, this is a clown show. I don't know what I'm doing. And so I just need to get better at, he has some really good strategies on how to like breadcrumb in and the multi-pass sort of doing pieces. And I think if I get better at making a wordly map, I'm gonna be better at thinking about organizational flow in general. And so, yeah, I've carved out some time.

Carter Morgan (1:10:46)

Yeah.

Nathan Toups (1:11:10)

to do this. Yeah.

Carter Morgan (1:11:12)

What about, what are you gonna do differently in your career?

Nathan Toups (1:11:16)

Inverting the document structure, goodness. I've definitely gotten some strategy stuff, but I've actually looked at something that I wrote just a couple of weeks ago, and I was like, yes. If I had used, if I had inverted the structure the way that he outlined, I think it would have been a much more effective document for others to read. I'm gonna, I have some, I have a couple of, I have one strategy document coming up on like how we're going to approach a new problem ⁓ with some, you know,

Carter Morgan (1:11:18)

There you go.

Nathan Toups (1:11:46)

Proposals on how to do this and I I think I'm gonna Apply this to that. What about you?

Carter Morgan (1:11:52)

For me, listen, I want to, in the spirit of the podcast, I want to have something real here. But to be honest, like we, I did a lot of engineering strategy about six weeks ago to come up with kind of like our re architecture. And we're just now in the thick of it. And we have entered kind of squarely the trough of sorrow with any big project or, you know, right. Or it's, we're going to get through it. It's going well. we, we, the database migration is done and that was like a beast. And then

Nathan Toups (1:12:10)

yeah. man. You'll get through it. You're gonna get through it.

Carter Morgan (1:12:20)

And then we got the front end migration done. basically like our front end components were really tightly coupled to the GraphQL implementation. And so just to even be able to switch to the new service, which will be rest-based, we had to introduce that kind of migration seam and decouple it. So we got all of that done now and we've really invested in like our cloud code skills to be able to analyze the existing functionality and to, you know, get us a good V1 version of it that we can then review. And so we have all of that and now we just

have to start like now it's entering production, which is scary, right? Um, and so we're going to do it. spent all day yesterday load testing the new system because that was a thing. I'm like, this thing's got to be able to handle load better. That's why we're doing all of it. And my, my initial results were much better than the previous system, but I was a little like, geez, like this isn't as good as I wanted. And then the more I looked into it, I'm like, oh, I think I chose the single worst endpoint we've written so far. was like six SQL queries that like, like it's like two batches or

three batches of two each. Each query was kind of complicated on its own. then so I started testing with some simpler endpoints. And I was getting the performance I wanted out of it. I'm like, OK, good. This is what we're wanting. Anyhow, all that to say, I got to make it through this re-architecture. We're going to do it. All right. And then, yeah, as far as who you recommend the book to, for me, same as last week. If you're in leadership or adjacent to leadership,

Nathan Toups (1:13:30)

Amazing.

You're gonna do it. I believe in you.

Carter Morgan (1:13:49)

Again, what I recommend to the juniors, me personally, not so much, but it's a good book. think you like this a little more than I do, but I think that's fine.

Nathan Toups (1:13:58)

Yeah,

this is a top five book for me, which is pretty hard to get into that list. ⁓ I'm going to say that it's going to be up there with fundamentals of software architecture and philosophy of software design. Just because I think it rounds out, if you're on a path in which you want to go, you know, staff plus, you really like ⁓ this and either you're going to go staff plus or you're going to go into management. ⁓ Thinking strategically is so valuable.

Carter Morgan (1:14:08)

So nice.

Nathan Toups (1:14:27)

and understanding how to interact with folks who are thinking strategically, right? The other part of this book is when you inevitably run into a Will Larson, the next up and coming Will Larson, if you want to more effectively talk to a person like this, you need to also understand what their motivations are here. Why are they thinking this way? Why are they thinking in systems? ⁓ If that's interesting to you, it is, I haven't seen it tackled this way, even though aspects of our fundamental software architecture, aspects of it are in team topologies.

Carter Morgan (1:14:37)

Yes.

Nathan Toups (1:14:57)

⁓ It's easy to recommend. Is it going to be worth your time if you want to, if you read the first chapter and you're like, ooh, this is right up my alley, the book's going to pay off, right?

Carter Morgan (1:15:09)

Yeah, this will be one that's ⁓ widely read for a while. ⁓ Okay, great. Well, we will wrap up next week with our closing thoughts on the whole book. It's gonna be mostly case studies. Interesting how the episode goes. I think it'll lead to a lot of interesting discussion. ⁓ And as always, you can find us on our website, bookoverflow.io. Check that out if you haven't. Nathan, I'm really impressed. It's looking really cool these days.

Nathan Toups (1:15:33)

yeah, ⁓ we just added ⁓ most of the, or at least all of the most recent episodes. I'm back filling the rest of them. ⁓ But we have episode transcripts that are from our recordings and includes timestamps that you can click into the YouTube videos. And so not only can you search for like, if we've ever talked about, know, how many times has Carter mentioned the word Disney, right? You can go find every episode where the auto transcript, you know,

Carter Morgan (1:15:58)

Yeah.

Nathan Toups (1:16:02)

creator has put it there. So if you remembered, man, didn't they talk about this thing this one time? You can go search for it now. And if it's in the last 50, 60 episodes, it's there. We're working on getting the rest of them in there too. But yeah, we're going to keep trying to add stuff. Hopefully, this also helps with search engine optimization. Maybe someone's curious about something, they find an episode. yeah, let us know how you like it.

Carter Morgan (1:16:19)

Yeah.

Yeah, and you can always contact us at contact at bookoverflow.io. You can find us on Twitter at BookOverflowPod. I'm on Twitter at Carter Morgan and Nathan and his newsletter with his consulting agency Rojo Roboto is at rojoroboto.com slash newsletter. Thanks for tuning in folks. We'll see you later.