How Engineering Leaders Approach Strategy - Crafting Engineering Strategy by Will Larson

Nathan Toups (00:00)

I think that there are probably prolific thinkers who come up with incredible strategy and maybe the boss doesn't understand why you're so effective.

but it's because you have this really great approach to strategy,

Carter Morgan (00:27)

Hey there, this is 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 co-host Nathan Toops. How you doing, Nathan?

Nathan Toups (00:39)

Doing great, hey everybody.

Carter Morgan (00:40)

Well, thanks for listening everyone. Like, comment, subscribe wherever you're at. Share the podcast with your friends and coworkers. We're excited. We got some plans cooking in the background. You guys will hear about them. But all of our plans can become only grander and more awesome with growth. So share the podcast with your friends and join the discord. We love having you guys on there and we love seeing what you get up to. And it's always fun to see how people found the podcast and to chat with other listeners. ⁓ And we're excited. We got this week. ⁓

This is a promised book, but we put it off to indulge ourselves in reviewing Project Hail Mary last week. We got a crafting engineering strategy by Will Larson. Will Larson, we've read another one of his books, Staff Engineer, and he's a friend of the podcast. We interviewed him about Staff Engineer. For the author introduction, 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.

Sent a year in Japan on the JET program teaching English, has been living in San Francisco since 2009. He writes frequently on his blog, Irrational Exuberance, at lethane.com. For the book introduction, have, good decisions are the core of creating software and strategy is 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 in concrete examples from real companies.

And before we get going, I just want to say Will Larson, I he's one of the more prominent names in the industry, at least from like an author perspective, and has worked at Calm, Stripe, Uber. I know he worked at Carta too, which if you have ever gotten like equity from a company, Carta is a big platform for that. ⁓ And I didn't realize, mean, computer science at Center College in Kentucky, a school I have literally never heard of. I love that about our industry. I love that nothing is a pure meritocracy, but... ⁓

You really do get folks like Will Larson kind of, you know, you don't have to go to Harvard or Stanford to have the kind of career Will Larson has. I hope our industry stays like that for a long time.

Nathan Toups (02:45)

Yeah, I will say I also appreciate a lot of times I have to like ⁓ summarize the book introduction or the author introductions and Will Larson's author introduction is like a succinct one paragraph. The book introduction is succinct. I think he probably had a hand in those things because it meets his writing style too. There's no waste in the books that he's written so far.

Carter Morgan (02:56)

Hahaha.

Well, give me your thoughts. read, this is a longer book, so we're reading, it's a three-parter. So we read the first third through chapter 10, right? Okay.

Nathan Toups (03:15)

Yep. So yeah,

it is. It's a large it's a longer book and it's pretty dense. So we decided to kind of I think this is the first hundred thirty pages or so is what we read it. But I don't want to make it sound like dense is bad. So I wish I'd read this book 10 years ago. It didn't exist 10 years ago. I wish. But for my career, I wish that I had ⁓ a deliberate view on strategic thinking, especially framed for the way software engineers have to think about problems.

Carter Morgan (03:25)

Yeah, about.

Nathan Toups (03:45)

I didn't know what to expect when I started this book, but I knew it was a Will Larson book, right? So I already had such a positive interaction with the staff engineer book. I think we liked it a lot. He's now a friend of the podcast. And I also have become a ⁓ very diligent reader of his blog, which if you're not reading Irrational Exuberance, it's to your own disservice. He writes just really well and very valuable information. I always get...

some little piece of information out of it and grow a little bit as an engineer. ⁓ Even though this book is long, unlike ⁓ Frictionless, there is no fluff. This is a high density, high value book. ⁓ There's a reason that it's as long as it is. And even in the first 130 pages, man, we have just already a big payout. can't imagine what the next two thirds are gonna dive into. ⁓ But this book is dense.

Carter Morgan (04:24)

Yes, yes.

Nathan Toups (04:42)

full of wisdom, full of real world examples, and everything's principled. just, there's this nice oscillation between, ⁓ here's how we did it at this company, or here's how this company's done it, and here are the principles behind it, and here's the things you'll run into, and here, like, it's just, it's like talking to just like really smart, capable person who's confident about the way that they've problem solved. ⁓ And even Pokes funded himself, like, he'll be like, ⁓ this might sound like it's too strict, and...

Maybe it is for you. I loved it, I loved it.

Carter Morgan (05:12)

Yeah,

Yeah, several times throughout the book he says like, you know, that you should adapt this process to work for yourself. ⁓ Will Larson is a great example. I think, especially amongst younger engineers, and I was a little like this when I was a younger engineer, you kind of think like, well, I've got all the right ideas. Someone just got to put me in charge, right? And like one, a lot of your ideas are probably wrong, right? But Will Larson is just a great example of someone like, it's possible Will Larson had a lot of these same ideas or has just always been a really smart guy.

But there's something to be said about experience. And Will Larson writing of this book at this point in his career, when he's been part of big migrations or projects at Stripe and Uber, he's been the CTO at a couple of different places. You know, that experience brings a lot of credibility to this book. And he hits out of the park again, per usual. I love Will Larson's writing style. I think, you know what, it reminds me of designing data intensive applications in a similar way.

⁓ Designs Added Tense Fabrications is a super dense book, but Kleppman doesn't ever have any fluff in it. It feels like every word is carefully chosen. Larsen is very similar in his writing style, ⁓ and ⁓ it really pays off as you're reading it. I think my only small complaint about this book, and this is my complaint with most book, is I find that most authors really, really, really want to sell you on the principle.

first and like kind of talk about the principle of what they're talking about and then they will give you an example to solidify the principle. ⁓ I like when books flip it and we'll give you the example first or just like briefly introduce the principle, give an example and then sell the principle by expounding on the example. ⁓

Nathan Toups (06:57)

Hmm, yeah,

I could see that. I don't mind that format, but I also think if we're thinking of it from like a stickiness perspective, I think you're probably right. would give you that payout, right?

Carter Morgan (07:02)

Right.

Yeah, right.

So it's like, it's not like a, Will Larson does this. I think we just read a lot of tech books at this point. And I think the ones that I enjoy the most tend to front load the example a little more. And, you know, I think that's kind of like, again, like a made to stick kind of concept to help you reason about the idea bit more. And now really good book, excited to talk about it. We're to take a quick break and then we'll be right back with our discussion.

Okay, let's get started. We need to start with chapter one. Really the introduction. What is the book he, Rumelt? That is the one, that's the author. Good strategy, bad strategy. The difference in why it matters by Richard P. Rumelt is.

Nathan Toups (07:49)

Yeah, it did.

Carter Morgan (07:55)

The book he read that he says kind of inspired this book. says that that book is all about just like strategy in general. I thought, know, there really needs to be ⁓ a book about engineering strategy in particular. So he the first part is about adapting Rommel's philosophy for engineering. We have three kind of sections to that. The first is diagnosis. And then Nathan, sure you these notes are these direct quotes here. I don't want to attribute them as direct quotes.

Nathan Toups (08:24)

Those are direct quotes, yeah. Yeah, so I think even if you just skimmed off the first sentence of each of those sections, if you wanted to do that, but yeah.

Carter Morgan (08:25)

Okay, these are the right quotes. Okay.

Yeah,

so diagnosis is a theory describing the nature of the challenge and you know, there's pretty straightforward right? Like you just have to actually try to figure out what the problem is and you know, I guess right here I guess what would the why it's a problem fall into here or you just trying to figure out what the problem is. Does it matter?

Nathan Toups (08:53)

Yeah, diagnosis to me, I kept going back to thinking, they don't talk about this in the book, but I kept thinking about my, I have a family full of doctors. And you know, a lot of times you're trying to figure out you've got some skin rash or you've got some weird thing, right? First, you need to diagnose the problem. You're like, well, it's because you keep exposing yourself to something you're allergic to, right? Like you have to diagnose the problem, ⁓ really kind of understands, you see some symptoms.

Carter Morgan (09:13)

Yeah

Nathan Toups (09:19)

there's some diagnosis, right? And that diagnosis is something that is your hypothesis of why the thing you're observing is there. And so ⁓ I think that this has to do with, and he kind of, he dives into this, right? That ⁓ if you skip this step, it's only to your disservice, right? Sometimes you want to get right into coming up with solutions for things, but he's like, if you don't spend the time properly diagnosing it, and I think we've all seen this, right? Have you ever been to the doctor?

Carter Morgan (09:38)

Right, right.

Nathan Toups (09:49)

And the doctor just jumps to a conclusion and he's like, well, yeah, that looks like this. And you're like, actually, I don't think it is that, ⁓ you know, just, because that person probably sees something similar to it and you're nine out of 10 times the doctor's correct, but that one out of 10 times might be you and you feel not heard. Right. So I think this is what he talks about from an organizational standpoint. It's like, and he gets into this later in the book. It's really tempting.

Carter Morgan (09:51)

Right, right.

Right.

Nathan Toups (10:18)

for a new tech leader to come in and be like, yeah, well at the last company, we did this migration to microservices and that fixed everything. And then just like six months goes by, you have this complete nightmare of a situation because you didn't properly diagnose the problem, right? You just said, this is a mess. We had a mess before. We fixed it with this at my last company. And so therefore we should do this at this new company. And he's like, that's a terrible way of approaching this, right? ⁓ So spend time on the diagnostics.

Carter Morgan (10:30)

Yeah.

And as your instincts get stronger, it's only more important to spend more time in the diagnosis step, right? Because you're gonna be, again, it's like the doctor has been around for 30 years and you just say, yeah, I've seen this 100 times, it's gotta be this. And again, nine times out of 10, probably right. Will Larson's point is that one time out of 10, you're gonna save yourself a lot of trouble and heartache down the road if you spend time diagnosing. ⁓

Step two would be guiding policy, which he defines as a series of general policies, which will be applied to grapple with the challenge. Guiding policies are typically implicit or explicit trade-offs. And I love this quote, I highlighted it. If a guiding policy doesn't imply a trade-off, you should be suspicious of this. I'm a big fan of this way of thinking, not even just in engineering, but just in life in general. I'm always suspicious. ⁓ We do not talk about politics.

much on this show, but I am regrettably a bit of a politics junkie. And I'd like to think in the best possible way. I'm interested in like the legislation being passed, right? And I'm always very skeptical from any ⁓ lowercase P party when they're describing a policy they want and there's no trade-offs. And they say that there's nothing, you know, like, and the trade-off might be very small, but in general, I feel like if you're not willing to acknowledge a trade-off, you've got to be delusional about some aspect of what you're selling.

⁓ yeah.

Nathan Toups (12:12)

I've kind of taken it again. I know we do avoid politics, but I've taken this sort of anti utopian approach. Utopians love to talk about, if you only give me power now, then all these wonderful things will happen in the future. And regardless of the political persuasion, I viscerally will react to this because I'm just like, yeah, but there's a trade off. Like you need power now. And that means that you're going to not let us do certain things.

Carter Morgan (12:18)

the bright rim.

Yes.

Right,

Yeah.

Nathan Toups (12:39)

And it might be effective and it might even be in our benefit. But if we don't talk about the trade off, like, hey, you lose a little bit of autonomy, but then we get safety or hey, ⁓ we reduce safety, but you get more autonomy, right? Like those are trade offs. I think the policy part two is unfortunately, I've been in a lot of companies where we've a lot of policies are kind of like throw spaghetti at the wall policies. And again, he doesn't say these words. These are me reading through the book, but like,

Carter Morgan (12:49)

Right, right.

Right, right.

Nathan Toups (13:09)

He does say the argument that every company has strategy. Whether it's, you know, if you choose not to express that strategy, you're still having a strategy. The strategy is, we don't talk about a strategy. ⁓ Or that, know, exactly, yeah, it's the fight club strategy. Or it's just like, well, whatever just kind of the whim of the week is, and, you know, complete chaos can come from it. Sometimes...

Carter Morgan (13:17)

Yes.

Yeah, the fight club strategy.

Nathan Toups (13:40)

letting that chaos in is actually more effective than a well planned out terrible strategy. Like I'm not saying that you can't have this sort of ad hoc, but he makes this very good argument for all the benefits of having a well reasoned strategy that's written down, that is got the policies are in place. ⁓ So that there's sort of these living documents that we can, you know, people are always going to disagree. For instance, he talks about this later in the book. And if it's written down,

it's much easier to have a debate about whether, ⁓ well, it says that this is the policy and we do it this way. Well, I think that that's stupid. I think that this doesn't make any sense. I think it's slowing us down. Or I think that this is giving a bottleneck because the CTO is being pulled 20 different directions. And if he has to sign off on every little thing, we're never going to get anything done. You can debate this if it's written down. If it's just kind of a Slack message and you hope you catch his attention or her attention. ⁓

Carter Morgan (14:35)

Yeah, right.

Nathan Toups (14:37)

That's still a strategy. ⁓ I think this gets us into the third thing from the RUMLET, ⁓ did I say that correctly? I'm gonna be so, RUMLET, yes. dyslexia, okay. ⁓ It's coherent actions. And it's set of specific actions to address the challenge, right? And so these are the sort of operations pieces, he'll get into this later in the book. they're guided by the policy, but it's,

Carter Morgan (14:45)

Brum out, I think. ⁓

Yes.

Nathan Toups (15:07)

how you take action and how you align on action and how you say something's outside of those policies. It's the enforcement mechanisms that are there.

Carter Morgan (15:16)

Yeah,

and he goes on to say you said that he didn't write this down, but I actually think he did. ⁓ Where he does say there's always an engineering strategy, even if there's nothing written down. I see, I see. Yeah, yeah.

Nathan Toups (15:24)

no, he does. Sorry. Sorry. He didn't write the spaghetti on the wall thing. That's me coloring that

language. He does say that. Yeah, he he has a few pieces of wisdom. One of them is that he said good strategy embraces change rather than fighting it. Actually, I just wrote a thing about change management and how it's more like surfing. You can't control the waves. So you kind of have to learn how to read that and dance in the moment. think strategy is a lot like this, too. You can't lock the whole world down and force it to your will, but you can.

Carter Morgan (15:42)

Yeah, yeah.

Nathan Toups (15:53)

come up with a set of standards to navigate the world as it is, right? Or navigate the changes you want to impact in the world. And I think that, again, there's a maturity to this that I just hadn't thought about, like, ⁓ I've had an arrested development in some of my approach to strategy. And this kind of really, I felt called out. Also, ⁓ his father is an economics professor, ⁓ and he talks about how he was like,

Carter Morgan (15:58)

Right.

Nathan Toups (16:22)

as a teenager brought to some like systems modeling workshop or something. And I was like, well, that would have changed me too. Yeah, that's a pretty amazing, ⁓ it's a pretty amazing like experience to have. And obviously he took a lot out of it because it's deeply impacted his ability to do ⁓ strategic thinking in his career.

Carter Morgan (16:26)

⁓ yeah, yeah.

Yeah.

Yeah, my dad's a psychologist, so ⁓ I got a lot out of that too, but not quite getting taken to systems modeling conventions. ⁓ Yeah, another, we've talked about this on the podcast before, and he mentions it, which is that you have to, is this a quote from something we read or just a quote in general? It's like, people and then tell people that you told them, right? Like we've...

I can't remember if that's just, I could just be making this up. Yeah, think, because one point Will Larson makes is that anyone can do engineering strategies. He you don't have to just be a senior leader, right? I think it's certainly more helpful if you're a senior leader or have any sort of official leadership position. ⁓ But you ⁓ you should always be trying to craft strategy around at least the domain you have the most influence over. And so that can even just be if you own like, you

Nathan Toups (17:17)

That's excellent wisdom, but I don't remember where I heard it. Yeah.

Carter Morgan (17:46)

you're the subject matter expert and like your Lambda consumers for your event driven architecture flow, right? That you should have some sort of strategy around those consumers if strategy is necessary. But I think we as engineers can struggle with being timid and being like, okay, here's the strategy. And like you send out a doc once and then you're like, well, I don't want to be obnoxious. I don't want to keep telling people about the strategy, but

Like you have to keep telling people what the strategy is, right? ⁓

Nathan Toups (18:20)

Yeah, take the Bernie Sanders approach again. The guy's like been talking about millionaires and billionaires for 40 years.

Carter Morgan (18:22)

Yeah. Yeah. Yeah.

and, I think, especially if you work at big companies, like you'll, some companies, like, again, I don't love Amazon as an employee. They are really, really good at this from like a cultural strategy perspective. Like they are all in on the leadership principles and they're constantly reiterated and you as an employee know, like, okay, these are like, quote unquote, the rules of the game.

Um, but I've also worked at other companies where like, they are not as aggressive in selling their principles or their engineering strategy. And I think in part as like a backlash to places like Amazon, where like, almost feels like a little culty and it is a little culty, but, uh, then you're kind of like, sometimes like you'll be in a meeting with like a senior leader. Like now remember we always do this and you're like, we always do that. Like when, what? I didn't know that was part of our strategy at all.

⁓ and so, yeah, you got to tell people more often than is comfortable for you.

Nathan Toups (19:29)

Chapter two actually does dive in, and again, I love this about this book, think staff engineering was similar, the staff engineer book. Chapter two is called, is engineering strategy useful? And he's basically making this sort of counterfactual arguments on like, you might think this, but actually that. And so, and not in an AI way, this is a real human written book, it's very obvious. There's always an engineering strategy, even if there's nothing written down, right? And that's exactly what we were just talking about.

Carter Morgan (19:40)

Yeah. ⁓

Nathan Toups (19:58)

He basically makes this case that this is inescapable, right? As soon as you get a group of people together and you're trying to build something as a group, you are either officially or unofficially taking a strategy, right? There is a way that you in your mind are picking a programming language or patterns or designing the architecture of a system or interacting with stakeholders. You have a personal strategy, right? You wanna keep your job.

you want to do good work, you want to dial it in and make no one notice that you're twiddling your thumbs all day, like whatever your strategy is. ⁓ If you aren't intentionally designing this as an organization, then you're sort of just letting the cards fall where they may. And again, I think in really small early stage companies, that might actually be the most effective. Like it is the anarchist sort of approach to strategy, which is might equals right, right?

Carter Morgan (20:53)

Right.

Nathan Toups (20:55)

Like, whoever's got the strongest strategy, most effective way of shipping or whatever, ⁓ it is a way of doing it. But as soon as you want to actually be like, how do we write code? How do we keep our standards? As soon as you want to start thinking as a group, ⁓ he actually, there's another little quote, William Gibson, which anytime there's a William Gibson cyberpunk quote, I'm happy, very famous one. The future is already here. It's just not very evenly distributed.

He said, the same sense, there's always a strategy embedded in an organization's decisions, even if the strategy is only visible to a small group and quickly forgotten. And that's absolutely true. If you don't deliberately do this, you are just, have, we're like tapping into tribal wisdom and all the other stuff that we hear.

Carter Morgan (21:44)

Yeah, I, cause you're, I was thinking like, okay, very small startups, like at what point does strategy not make sense? But I think you're right. Like strategy always makes sense. And I was thinking, we've been discussing a lot as a team, like, okay, how are large language models changing the game in terms of like engineering practices? And one place where I think they really are changing the game is testing. cause I've, think I've said it before, but like,

I remember reading like on Reddit, like the experience that I've separate when I was younger, my career, when someone said like, when should you not write tests? Someone said like, when it's harder to write the test than implementing the feature, I'm like, so that's all tests. Like I feel like almost every time, especially like when you're a junior engineer, implementing a feature is easier to reason about than writing the test, like testing, you're like, whoa, you know, I didn't learn this in school. Anyhow. and so.

It's been very debated with the industry. Well, how often should you test? And ⁓ we had a strategy when the startup was seed stage, pre-seed, of we don't write tests because we're still fighting product market fit. And there's no point in writing tests for code that might get thrown away next week. ⁓ And that's an example of, you disagree?

Nathan Toups (23:01)

Well, I'm glad I wasn't on that team. I'll just put it that way.

Carter Morgan (23:05)

Yeah, I

joined later and but it's been an us.

Nathan Toups (23:09)

No, no, I've seen this time and time again. It always bites you long term. ⁓

I'll put it this way. You can, you know, especially if you have children and if you don't have children, even if you just live in a space where you're responsible for how tidy or how messy your house gets, right? There's the tidiness, which is just like, are things put in the right place? Then there's also the cleanliness, right? Like I need to sweep, I need to mop, I need to wipe down surfaces and stuff like this.

Carter Morgan (23:26)

Hmm.

Right, right.

Nathan Toups (23:38)

Obviously, you don't do a full deep clean every time you need to get your house in order. You're probably going to tidy up ⁓ more frequently. And the thing is that if you let your house get super messy and a friend wants to come over, you will be embarrassed because you have to tidy up really quick. You can't find things. You can't find your keys. can't, you know, like there's all this disorder that comes from it. How much you write tests is like how tidy you keep your house. That's how I look at it. So, yes, you can allow your house to get a little messy. And because, you know, if you're

Carter Morgan (23:53)

Right,

Right, right.

Nathan Toups (24:07)

OCD about every little thing being perfect every time. It really can slow things down. But if you need to rely on consistency amongst a lot of people, the tidiness becomes a lot more important. Like, where do I put my keys? Or do we share a vehicle? Right? Where do I put my keys? Well, if I'm just dropping my keys the last place that I always had them, now we have this huge fire drill every time I'm like, I don't know. I remember where I put my keys. I might've left it in my pocket. Did it go in the wash? it, you know, like, and so

Carter Morgan (24:34)

Right, right.

Nathan Toups (24:37)

In my mind, it's sort of like a lot of the times it organizations, I say, I think about, well, myself, am I giving a gift to myself six months from now? That's kind of a threshold that I'll bring up. So it's like, if I, if I didn't touch this code again, it's like, and I would come back to it in six months and I decided not to write tests. Would I care? And if I wouldn't, then I would actually not write tests, right? Like if I, if it's literally one of these like throw away things, if it is one of those things where I'm like, man,

Carter Morgan (24:50)

Right.

Right, right.

Nathan Toups (25:07)

I built up this crazy mental model, and I understand the code now, but I'm not gonna understand it in six months, and that would really suck if I don't at least write a few tests to make sure that it's behaving the way I want it to, right?

Carter Morgan (25:19)

You know, my

hot take with tests is not so much that, like, I think there's a lot of value in like the tests for validating that the code works like it should. I actually think the bigger value from tests is that it forces you to write code that's easy to test. that, right, like, because we just have functions in our code base that are just like.

Nathan Toups (25:39)

100%, yep.

Carter Morgan (25:44)

800 lines long with like all this branching logic and like I'm starting with this on our front end. We're doing a rewrite of the back end and I think this is where AI is changing the game is like tests right now much cheaper, which is awesome. But we have this problem on the front end, just like a simple like form submit problem or like you click a button which opens a modal. You write, you know you add something to the form and then it should append to the list once the modal closes ⁓ wasn't appending to the list. And so I was like.

I should just write like a test just to make sure that like this happens in the future. And so I asked Claude code. was like, what would a test like this look like? And it came back and it said like, yeah, so this is a really complicated, like intermingled mess and I'm going to have to mock out eight components. So instead, why don't we just validate that the modal opens and that you can write something. And I'm like, I don't need to know that. I know the modal opens, right? And,

Nathan Toups (26:28)

Mm-hmm.

Carter Morgan (26:41)

Yeah, but I think if you had led with kind of like a we need to write tests for everything approach, you would have realized that pretty quickly. I've been like, huh, like this code is kind of a nightmare to test. And anytime you run into that scenario, shouldn't be therefore tests are useless. It should be, I wrote this code.

Nathan Toups (26:58)

I end up, you know, I'm mostly doing backend type stuff and so it's really easy to, like if you're writing, you know, Go or Rust or Zig or Java or something, there's very mature testing frameworks in place. It's really easy to kind of like understand those boundaries. And if you're writing, at least it could be as I've run into, a lot of React and JavaScript ends up putting a lot of logic inside of components and things. ⁓

it gets hard to test because you end up having to use Playwright or something. You end up having to do these really advanced EDE. And I do think that it's appropriate because there are emergent behaviors that come from event stuff that happens in the DOM. and maybe this is me fighting the JavaScript community, I really like having well-defined libraries that I pull into my JavaScript.

Carter Morgan (27:33)

Yes.

Right, right.

you

Nathan Toups (27:55)

where if it's something that's gonna be interacting with databases or API backend or something, I really like it if I can put that inside of a library so I can mock it easier. So it's like, can I do this kind of complex thing in the framework of a library so I don't need to care about React at all? And all this thing is doing is saying, add a user to the database and then all of a sudden I can throw in a fake or a mock or some other thing and you get sort of the backend.

Carter Morgan (28:14)

Right, right.

Right, right.

Nathan Toups (28:25)

niceties of inversion of control and some of these other patterns. I like, I've done this with the Book Overflow website where we have a database now. We have, we keep the records of all of our books and I do a little, it's not fully functional, but I'm actually like, for most of the stuff that we have, I pass in a database client into the function. And it's not as common, but I do. like, I'll have this user update thing and it's got a database client and it's got like the, you know, the parameters that I need for doing that.

Carter Morgan (28:45)

Yeah, yeah.

Nathan Toups (28:55)

update. And it's so nice. Like I could just write really solid tests around this because I'm like, okay, I can do edge cases. I can think about partial failures. can, can mock all of these things out, run those through. And then for my end to end testing, if I'm using Playwright, I just run the normal workflow stuff. And I have like confidence that I don't have to use Playwright to like mock every kind of database failure and all these other things. ⁓ And so.

Carter Morgan (29:21)

arrive.

we using for

our database, by the way?

Nathan Toups (29:27)

Postgres, like a proper gentleman. Yeah, we're using Neon, which is serverless, so it spins it down to zero when we don't need it, and it's pretty good cold start. I think it's like 100 milliseconds or something. ⁓ I haven't heard anybody complain, so. ⁓

Carter Morgan (29:28)

There we go. Sick.

Nice. Okay, nice.

Did

you do something with the website to make it so that ⁓ agents can't crawl it?

Nathan Toups (29:50)

No, I didn't.

Carter Morgan (29:50)

No, I just looked at,

I have a couple domains hosted on Cloudflare and, oh wait, no, no, I know. I must have given you, I gave you DNS control over the website, right? No? I just pointed.

Nathan Toups (30:02)

No, you just pointed it to Vercell. So

we're on Vercell and Neon, a little inside baseball. Yeah, we're on Vercell and, yeah, are we blocking agents? Because I don't want us to block agents, actually.

Carter Morgan (30:11)

No, I just

noticed that the visitor traffic was much lower than like I, I've told a story on the podcast before. I bid on a bunch of domain names, which I was like, I'll just bid on these and then hope that someone outbids me. then sure that'll work, but no, no one outbid me. And so I own a bunch of stupid domain names like Portland tax attorneys.com. ⁓ yeah, that's a, know the only one I'm proud of is prime brisket.com, which I

Nathan Toups (30:30)

Mmm, you're squatter.

⁓

I own and it's got really, I think a very funny landing page for it. have cooldudes.biz, but cool is spelled K-E-W-L, cooldudes.biz. And it has a like GeoCity style, like under construction. We'll put a link in the show notes, cause you know, it's real cool. And I...

Carter Morgan (30:53)

That's ⁓

Yeah, then I've said before, if you if

you meet me in person, you are not to say, Hey, are you Carter Morgan from Book Overflow? You're supposed to say, Hey, are you Carter Morgan, proud owner of prime brisket.com? And that's how I will know. Anyway, they redirect my LinkedIn. Okay, we've gone off the rails. Okay, we got to we got to get back to Will Larkin because we promise this is a really good book. Part one, that was kind of like

Nathan Toups (31:08)

Climb brisket, ooh, that's a good one.

I also have I also own everything is stupid dot lol which I've never done anything with.

You

Carter Morgan (31:26)

the general summary. Go ahead. Okay.

Nathan Toups (31:27)

yeah, the last

little part of part one that I thought it was also great is inappropriate strategy is especially impactful. So he talks about like how disastrous and he calls it the grand migration, which is this like attempt to entirely rewrite some architecture. Again, new person comes in, you want to have a high impact. You know, they hired you for a reason. They've complained about this. ⁓ And what a nightmare it can be. And of course, I think we've all experienced.

Carter Morgan (31:35)

Okay.

Nathan Toups (31:55)

spectacularly bad strategies, right? And so this book does not sugarcoat. It's not like some of the DevOps handbook stuff that we saw, which is like all amazing stories of all the wonderful things that happen when you implement DevOps. It's like, no, strategy is incredibly powerful. Bad strategy is going to completely derail everything. It's going to cause lots of problems. So be very careful. Yeah.

Carter Morgan (32:06)

Right.

You

Well, let's move into part two. Let's actually take a quick break and then we'll be

Okay, moving on to part two. He takes all these kind of steps we've talked about and explores each of them in detail. And so he says,

There's kind of he likes five steps to crafting strategy, which is exploring diagnosing refining Setting policy and operations. I really liked from like a meta perspective reading about his exploring approach because I feel like that's all this podcast is is exploration, right? Yeah, and and he said he's like There were two things that resonated with me, which is one He says like he tries to read like 10 to 20 engineering books a year

Nathan Toups (33:12)

Yeah, we're a couple of explorers, for sure.

Carter Morgan (33:22)

which I think is about, we do probably about 20 a year. If you figure we put about 50 regular discussion episodes and average is a two-parter, yeah, 20, 25 or so. Thanks, Designing Dad Intensive Applications for throwing our average off. But this is something that I feel is, if not on...

Nathan Toups (33:31)

That's about right. Yeah.

Yeah, think we might do 15 this year.

Carter Morgan (33:49)

Maybe underrated is the right word, which is like before you can even implement any sort of strategy, you have to know what's out there. And I think there are engineers who just, the only thing they know is what they've worked on at previous companies. ⁓ And ⁓ so, you know, I'm a big fan of, we've talked about it a lot, but like there's a lot to be said for depth in this field. Also a lot to be said for breadth, which is why I really like some books like Fundamentals of Software Architecture, which is exposed to

Nathan Toups (34:14)

Mm-hmm.

Carter Morgan (34:18)

a lot of different patterns you could use. I'm a fan of things like... ⁓ go ahead.

Nathan Toups (34:24)

He talks about it. says, read widely and read narrowly. So again, just like the ideal is that T-shaped engineer that we've talked about in the past, this is the same way that you should be reading. I need to have these. This is a perfect example of a read widely. Strategy is this all-encompassing thing. It has a positive impact on your career. It has a positive impact on business outcomes. ⁓ You have to have this meta.

Carter Morgan (34:27)

Yes, exactly.

Mm-hmm.

Yeah.

Nathan Toups (34:49)

understanding of like how you do stuff. And then read narrowly, right? You've realized that you want to use Zig because that's what Bun and Ghosty were written in. And you have a problem that kind of fits into the shape of those things. And you need to understand how the allocator works, right? Like go deep, like go do it. That's a part of an exploration phase that you need to go into. Don't shy away from it. And we have to be comfortable kind of doing that. Like big picture Will Larson stuff. And then

you know, that weird thing on 10 things you didn't know about Zig allocators, like do it.

Carter Morgan (35:23)

Yeah.

Well, you know, Twitter is a cesspool, but I actually do like Twitter for that reason, which like it's easy to get exposed to a broad surface area of concepts. especially, I mean, we were chatting before the podcast even started about like the different ways, you know, my company and the companies you're working with are trying to switch to AI agent native workflows. And like it's moving so fast and concepts that were

maybe all the rage six months ago are less useful today. And it's hard, it's hard to keep up with all of that. And so, you I find things like Twitter ⁓ or podcasts or YouTube channels, a good way to kind of read broadly. ⁓ But you do have to kind of buckle down and once you've locked in, be like, okay, I think this is the right approach for us. That's when you gotta go narrow and figure out and read more narrowly.

Nathan Toups (36:06)

Yep.

Exactly, I

think Substack has filled that for me in a lot of ways. ⁓ My YouTube feed is, I'm a weird YouTube user because I actually have recommendations turned off because it'll just take me down rabbit holes. Yeah, so I call it boring YouTube. And this is just because I will spend, I already spend two, not too much, I have a large time investment in YouTube. yes, absolutely, absolutely.

Carter Morgan (36:23)

Yeah

really?

You

YouTube premium, do you have YouTube premium? do you just, yeah. No, but that's

probably the best value subscription I have. Which is not necessarily a good thing, right? Because it just says how much money I spend on YouTube.

Nathan Toups (36:49)

Well, I also like

it because I don't want my daughter to be advertised to. I'm like very sensitive to that. so I'm, and I'm happy to do that. I like that business model for those who can afford to do that sort of thing. I like the creators being compensated for that, but I will say, so yeah, so, know, if it's number file or Veritasium or, you know, anything ⁓ Marquis Brown Lee does or, you know, I have a,

Carter Morgan (36:52)

Yes, yes.

Yeah, right.

Yeah, yeah.

Nathan Toups (37:18)

I basically, I'm into skateboard YouTube. So there's some skateboarders who just kind of do day in the life videos that are, my wife and daughter are like, why are you watching this dude just hang out with his friends? And I'm like, you don't understand. This reminds me of being 17, so this is great. ⁓ But yeah, so there's a tremendous amount of ⁓ DevOps platform engineering. ⁓ Low Level is another good YouTube channel. ⁓

Carter Morgan (37:28)

Yeah.

Nathan Toups (37:47)

Primogen, I'm a huge fan of. there's these I love keeping track of because it kind of keeps me on the pulse of stuff. But then I have friends who are like, I'm the rubber ducky for a friend who he does a lot of agentic stuff and Rust things. And agentic stuff I have a lot of overlap with. Rust, I'm not a Rust developer at all. But I will tell you, I know more Rust than the average person because I get to hear about...

some cool pattern in Rust that he's like super excited about. I'm like, I mean, like I learned through that. I'm like, wow, that's never thought of a language needing to do that. And, you know, here's how the borrow checker works. And here's how you express types and some, you know, abstract academic higher order type system or something. And I think you need to be comfortable. If you're comfortable oscillating between these two, the exploration phase is a lot of fun. And I think that there's a reason he talks about exploring before.

diagnosis, which is that if you don't have this sort of like broad, this breadth of knowledge, your diagnostic phase is going to be really, it's really just not going to reach its full potential, right? In the same way that you want a doctor to go to medical school and be exposed to all the different ways that are, I keep talking about rashes on skin, but you know, ⁓ yeah, I think this is a,

Maybe a good transition into diagnostics unless you have more say in exploring.

Yeah, diagnosis is your attempt to correctly recognize the context that the strategy needs to solve before deciding on the policies to address that context. ⁓

Carter Morgan (39:31)

Yes,

he gives some good examples here. Like he says, a diagnosis can be largely data-driven, such as the strategy for navigating a private equity ownership transition. And then he has a direct quote from other documents he's written that says, our engineering headcount costs have grown by 15 % year over year this year and 18 % year over year the prior year. Headcount grew 7 % and 9 % respectively, with the difference between headcount and headcount costs explained by salary band adjustments, 4%, and a focus on hiring senior roles, 3%, and increased hiring in higher cost geographic areas, 1%.

So, you know, basically like this is a diagnosis step to say like, hey, like costs are growing. He has another example about integrating an acquired startup. This is when he worked at Stripe. says, we only need to rapidly integrate the acquired startup to meet this timeline. We only know a small number of details about what this will entail. We do not know what point of sales devices directly operate on payment details, blah, blah, blah. Right. Yeah, I think.

as far as diagnosis, like we've already talked about a decent amount, but it's just the attempt to really say like, okay, what is the problem? What exactly are we trying to solve here? ⁓ And I think that, you know, that can be, ⁓ it can be good to be clear-eyed about that, because like, it can be easy to come into a situation and like, the problem is that everything is bad, right? But like, that's not a problem, right? Like, you gotta be more specific about what exactly is going on.

Nathan Toups (40:57)

And yeah, this actually gets us also, there's another one that comes right after diagnosing, which is called refining. And one of the things I like about refining is that you take these raw, unproven ideas and you're testing them against reality. And so we'll talk about this because he actually brings up this idea here of why doesn't refinement come earlier or why doesn't it come later in the process? Like, why do we have exploration, then diagnostic, and then refining?

He basically says it needs to happen before we get into ⁓ setting policy, which is the next phase. So I guess, however, I don't know if we listed all five of them, exploring, diagnosing, refining, setting policy and operations, right? Like, yeah, actually Carter did talk about this.

Carter Morgan (41:44)

But you gotta tell people and then you gotta tell them that you told them.

Nathan Toups (41:46)

Well, and refining actually can naturally, this is one things he brings up, and I think this is really nice about this sort of framework. Refining can naturally come up in any one of these phases in little pockets. So like in the exploration phase, I might actually refine my exploration down to the categories that I really care about, right? Like we maybe we threw a wide net. So I did this recently, actually. I'm working on building out this data warehouse.

We want to build it so that we can have, we have certain patterns. We want a very clear separation between ETL pipelines of external data that comes in and then our data warehouse, like our data lake that we have, and we're using Databricks for this thing. ⁓ And it's really important that we have these like directed acyclic graphs, these DAGs, ⁓ where we're not like doing data lake stuff that feeds back into this. We want these like clear separations between what is OLAP analytics data and what is transactional.

oriented sort of like daily process type data. Very pedantic about it. And I actually did, ⁓ actually with some agentic augmentation here, an exploration of the current state of market research on what these patterns that are in place, what are being done by different organizations at different maturity levels, what the trade-offs are, right? We did this like, and so I would actually say like I did exploration and then I did some, I did some exploration and a little bit of refining.

And then I made this design document of our strategy for this, which is I had some diagnostics that we did, and then we refined it again. There's another round of refining. And so I didn't realize I was following this ⁓ pattern, but I was like, you know what? This is really cool. And now we're actually in the phase of looking at policies. And now we say, OK, if data gets ingested, ⁓

this is the policy, you must have these columns, right? We have to have a recorded at column. We have to have a batch ID. We have to have, like, we have these very clear things. It's like, if this is data that we're going to do ⁓ bronze to silver to gold medallion model or whatever the data processing thing is, here's the standards that we hold ourselves to. These parts are append only. These parts, we never reprocess twice, right? This is event-based versus this is entity-based. Like all these...

we have written policy documents that came from these formal things so that if we onboard a new person, they don't have to go and be like, oh, I have these like 15 ideas. They're like, okay, what's the policy on how we ingest data? Oh, it's right here, right?

Carter Morgan (44:23)

Right. I'm I'm just thinking now because I mentioned we're in middle of a big rewrite due to what we kind of saw some not intractable problems, problems that it would have been like, you know, as actually I owned. We moved to Utah, we kept our home in Orlando and we were renting it out and then our renters left and we just got hit with like this double whammy of it was going to be like six thousand dollars to get it rental ready and we're going to have to lower the rent price and like our escrow went up or is going to be like.

$10,000 to get it sell ready. And we kind of hated being landlords on the, especially when we were like 3000 miles away from our house. And so we were like, you know what, let's just sell it. It was very similar decision with this rewrite. It's like, there was a certain amount of like, there was a smaller amount of work you could do to get it like rental ready and to keep moving on the old system. And then there was maybe a 40 % more work to just rewrite it. So we're like, you know what, like let's just rewrite it. And with that, there,

You know, there was a lot of strategy and exploration and diagnosis with, ⁓ kind of what does the overall architecture look like? and I've been living in that a while and we got, we, we've got all the infrastructure set up. got the data all migrated and just now we've started writing and we've been in the middle of, ⁓ doing the front end migration, just kind of switching the front end and staying mostly the same, at least business logic wise, but we are sticking some new patterns in to give us a migration seam.

so that there's a common place where we can switch from the old backend to the new backend ⁓ and toggle that via feature flag. ⁓ But now we're just getting to writing like the actual backend code. And we've standardized on some things like, you know, ⁓ we're switching to functional programming instead of object oriented programming. And we have like all of our frameworks in place. Like we're using TypeScript with Express and Zod for type validation and Prisma for database access. And we have some

rules around exactly how we use Prisma. Anyhow, but I'm just now realizing, I'm like, you know what, we haven't talked so much about like, we know we want to test, but what rules do we need to have in place to make sure that testing is easy? that, what you're talking about, Nathan, like making sure you're always passing in like a database client instead of, you know, having calling some functions directly. Or yeah, there's just a lot where I'm like, dang, like we gotta hone in on that.

But I think there's a ⁓ case to be made that that is part of refinement. Like I wish we could have been like Moses coming down from you know, Mount Sinai and said like, these are the rules, we're gonna do this. But like, you gotta move. And so I'm just like, yeah, I think there's a bit of refinement going on here. Like, yeah.

Nathan Toups (47:00)

Yep.

Well, and I will

say that ⁓ you can even have a policy. this is a good example. ⁓ think Stripe acquired a company called Index. And they had a policy where they couldn't get on the same page on, think Stripe had, I think at the time, if I'm remembering this correctly, they had a pretty strict thing where they picked, they used a single programming language for as much of the code base as possible. didn't, you they weren't, even if they had microservices, which I don't know, they chose to.

use the same language, ⁓ at least as much as possible across this. And so this was a decision, a setting policy that happened where they couldn't get on the same page on whether they should migrate them to a different programming language. And they said, defer making a decision regarding the introduction of Java to a later date. The introduction of Java is incompatible with our existing engineering strategy. But at this point, we've also been unable to align stakeholders on how to address this decision.

Further, we see attempting to address this issue as a distraction from a timely goal of launching a joint product within six months. We will take up this discussion after the initial release, launching the initial release. You can have, that is a policy. You could think of it as a thing you can point to if there's a disagreement and somebody comes back in. And I think we talked about this ⁓ in fundamental software architecture. ⁓

can't remember the name of it, where you basically, you have these sort of zombie debates because you haven't documented something in a good document log, right? So if somebody says something in a Slack conversation, they think that that's the thing that's stuck, but it didn't actually live anywhere. And so these things keep coming back up. If you make it clear and you say, hey, look, I know nobody wants this. We got to launch though. If we don't launch, it's a huge problem. It's a bigger problem than the fact that we have two different programming languages. We're going to duke it out.

Carter Morgan (48:39)

Yes, yes.

Nathan Toups (49:00)

after launch, right? Settled. There's no more debate, right? This is a policy that came out of, they did an exploration phase, they diagnosed the problem, they refined this down to something, and then the policy came out of it, right? ⁓ I think that, again, this is a sign of maturity where, when I've been in organizations that had ⁓ these boundaries, right? Like this is, and this is any good relationship, right? It's like you set a boundary of,

Carter Morgan (49:27)

Yeah.

Nathan Toups (49:29)

we don't do this, our family doesn't do this or, you know, my friendship, we don't gossip about our other friends, right? And if you that that's, you know, as a policy, you know, ⁓ if you're gossiping about somebody else, just assume they're gossiping about you, right? And so we kind of informally are not do this. This gets us into the fifth step. And I guess we can dive into to these a bit more if we want to, but that is operations. So

Carter Morgan (49:44)

Right, right.

Right,

are you actually enforcing this?

Nathan Toups (49:59)

Yep.

So how do you interpret? So if a policy is like a chunk of code, now the operations is the interpreter. That is like, is this thing? It says, even the best policies have to be interpreted. There will be new circumstances where authors never imagined, and the policies need to be in effect long after the authors have left the organization. The US Constitution, excellent example. We have three branches of government that are constantly trying to reconcile.

Carter Morgan (50:23)

Right, Yeah.

Nathan Toups (50:28)

What do they mean with a... Yeah.

Carter Morgan (50:32)

Yeah, this is ⁓ this is really where the rubber hits the road, right? ⁓ Some some of these things are easy. Like if you're doing policy at a lower level, like on a team in particular, coding styles. Yeah, you know, I might go to the team with a proposal like, we got to make sure that we're only ever accessing the database via client in a way that's easy to mock. Like, great. Throw a linter in there.

Um, we need to have a policy that like of 80 % test coverage. Like that's great. Like have a, you know, have a coverage report generated on every PR. Um, it gets harder as you go higher. And I don't know if it's course around this step in particular, but he talks at one point about like, you have to like sometimes whisper the quiet parts of why a policy is necessary. And he says he worked at a place where like they decided they were going to implement like the Amazon bar razor.

method, right? Where, where like every team had to have an outside hire who would evaluate, who would also serve on the interview panel and then they could veto the, ⁓ they, could veto the, ⁓ decision. But like people weren't really abiding by this thing. No one was really listening to the bar raiser and he was confused. He was kind of like, why do we even have this? Like what's going on? And then he found out that it was basically there was a senior engineering leader.

Nathan Toups (51:25)

Right.

Carter Morgan (51:52)

that none of the other senior engineering leaders trusted to hire. They thought that he or she was just making bad decisions. And so they implemented this whole framework, this operation to enforce this, but it didn't make any sense to him. And so he says, as far as when you start implementing these things, you still have to have a way to like, if there's some part you're not allowed to say, you still need to have to have a way to say it or else,

Nathan Toups (51:56)

Wow.

Carter Morgan (52:21)

people don't know why they're doing what they're doing. ⁓ Yeah, I was just really like, I don't know, that cracked me up.

Nathan Toups (52:25)

Great.

I did love he

in the operations section, in the operations chapter. there's an overview of kind of all these things that we're about to read about. And then we actually get each, there's a dedicated chapter for each one of these. That's what we read through today. ⁓ Chapter 10 is actually the operations phase. So I'm actually excited to see what they build on top of it. One thing that I thought was cool was he referenced another book we've read. He said, operations in government. And he said, for another interesting take on how critical operations are, Recoding America by Jennifer Polka is worth.

Carter Morgan (52:44)

right here.

yeah.

There we go.

Nathan Toups (52:59)

The read, it explores how well-intended government ⁓ legislation often isn't feasible to implement, which results in policies that require massive IT investments, but provide little benefit to the constituents. And I think he talks about this in the operations side of this, which is, you know, there are useful, there are useful quality gates, right, if we want to think of it that way.

of the enforcement mechanisms that are in place. And then there are some that are way too restrictive or kind of tone deaf to what the organization actually needs. I think we've probably always, we've all experienced this where like, I'll call it organizational scar tissue, where you're like, why is this rule here? And then yeah, you find out it's because they kind of passive aggressively wanted to handle this one edge case for this one bad apple indirectly by making a rule that restricts everyone.

Carter Morgan (53:40)

Okay.

Nathan Toups (53:54)

trade. ⁓

Carter Morgan (53:56)

This, I

don't know if I'm gonna do this. I'm just thinking about it now. But just because he mentioned Recoding America, I might try to make a directed graph of all the books we've read. Right, like, see, like, that might be fun. And then like, stick it on the website somewhere. I don't know.

Nathan Toups (54:07)

Ooh, yeah.

That actually, that'd be really, so I'm actually in the process of, one of the things that people brought up is I wanna have, I realize that our software that we have does transcripts where it actually has like, I said this and Carter said that. It's a different format than what we have for like the closed captioning, which is slightly different format. But I wanna export all these and I would, because I want from a search engine optimization standpoint, I would love it if our transcripts are on the episode pages for everything and that way if somebody searches for something, it comes up.

Carter Morgan (54:25)

Okay.

Yeah, yeah.

Nathan Toups (54:44)

know, cool SEO potential. But it would be really cool to see if we could have some sort of extractor that does, yeah, sort of you know, edges and nodes ⁓ graph of like every episode where, you know, it was about a book, but we've referenced these other books or where the book itself actually references these other books. I think that would be really cool.

Carter Morgan (54:56)

Yeah, yeah.

Yeah, yeah, that'd be interesting. ⁓ We got

big plans here.

Nathan Toups (55:09)

Approval,

think this one I thought was worth calling out from operations, approvals and advice forums. So like, think this one is really, this was helpful, again, examples that he gave. He was talking about when he was at ⁓ Calm's product engineering strategy, he was CTO at Calm. It said, exceptions are generally granted by the, these are approvals that have to happen. Exceptions are granted by the CTO, it must be in writing. Above policies are deliberately restrictive.

Sometimes they may be wrong, and we will make exceptions for them. However, each exception should be deliberate and grounded in concrete problems that we are aligned both on solving and how we solve them. If we all scatter towards our preferred solution, then we'll create negative leverage for Calm rather than serving as an engine that advances our product. All exceptions must be written. If they are not written, they should operate as if they are not granted.

Our goal is to avoid ambiguity around whether an exception has or has not been approved. If there's no written record, the CTO approved it, it is not approved. And I don't know if you couldn't make that more clear, right? It's like, wait, that doesn't align with our policy. How did you do that? ⁓ I just kind of ask forgiveness later. Like, I don't think you understand. Like you're crossing a line here. We have a very clear operations guide that if so-and-so didn't sign off on it, this is going to get shut down. Like you're going to be in bad shape.

Carter Morgan (56:16)

Yeah.

You

Nathan Toups (56:36)

That

way you can have these sober conversations amongst peers. You don't have to wait until somebody tattles or slaps you on the wrist. You can have a peer enforcement be like, dude, you gotta stop this or like, you better go get approval right now or you're gonna get busted, ⁓ which I think is healthy. It's a healthy thing.

Carter Morgan (56:53)

Well, why don't we, ⁓ let's talk about some of our hot takes if we don't have ⁓ much stuff to wrap up. I can go first, ⁓ which is, I think you can only do as much strategy as your boss wants you to do. which, I don't know, like tell me if you agree with that. really, this is just part of my constant aversion to managing up. I'm a great number two. I'm a great wingman to who I feel is a confident leader.

Nathan Toups (56:58)

Yeah.

Carter Morgan (57:22)

And I really, really struggle when I look at somewhat like my boss and think like, if you weren't here, I could be doing your job better. And so I ⁓ think if you find yourself in the situation where you feel like you're having to like write a lot of strategy to compensate for the failures of your boss, you're gonna make yourself miserable. And so, I don't know, what do you think?

Nathan Toups (57:47)

I disagree slightly in that I do think that you may, your recognition for your contributions to strategy are limited by your boss's imagination. So there's a subtle nuance to this, which is that I don't think you're limited of the strategy that you're able of accomplishing, right? I think that there are probably prolific thinkers who come up with incredible strategy and maybe the boss doesn't understand why you're so effective.

but it's because you have this really great approach to strategy,

but they just know, man, Carter always gets his stuff done, I don't get it. And it's unfortunate that they don't realize the fact that you have this really good approach that you took, you really explored things, you spent the time diagnosing it, you figured these things out. ⁓ And if you can't effectively convince them that the reason you're successful is because of your approach to strategy, I do think that you're gonna run into problems.

I think that that is, but I don't think you're dependent on them to actually be effective at strategy, if that makes sense. ⁓ Now they may sidestep it or go, you know what, you're spending way too much time thinking about this thing, just do it, just do, dial it in, make it happen. I think there's a sense of disrespect for the process that could wear you down over time, for sure. ⁓

Carter Morgan (58:52)

Right, right.

Yeah.

Nathan Toups (59:11)

especially if you realize that your boss is not effective. It'd be one thing if I'm way too careful and it takes me way too long of a decision. I'm hand wringing, I'm a perfectionist and your boss is like, look, we could have shipped three features and figured out which one was actually the good one in the amount of time that you tried to come up with one that was okay. You always have to question, am I actually effective at this? ⁓ But I know what you mean though.

If I come in, I'm kind of bright-eyed and bushy-tailed and excited about something, and then the boss is like, that's stupid. You don't want to contribute strategy if that's the case. I think I do agree on that.

Carter Morgan (59:48)

Yeah.

What do you got?

Nathan Toups (59:57)

The book doesn't address this directly. guess it talks about you do have strategy whether you plan to or not. But I've said this, I'm quoting myself in here a lot, and I think I've stolen this from somebody else. I can't remember who said, hope is not a strategy. I say this a lot, especially because they're like, oh, I hope if we do this and I do this and I do this, then I hope it's gonna, it might work out. And I'm like, that's not a strategy. That's not an effective strategy, I should say. Hope is not a strategy, meaning is that like,

Carter Morgan (1:00:09)

Yeah, man.

Nathan Toups (1:00:26)

we need to have a way of, it needs to be falsifiable. We need to have these boundaries. We need to have some, you your diagnostic phase and your refinement phase and your policy phase should be grounded on some hypothesis of the way the world works. It's modeling exercise, right? We need data, like good example with the external data ingest tool that we're building. We know that we have a bunch of data coming from external sources. We really care about insights for decision makers in the organization.

And we need, as this, the in number of external sources comes in, we need to make sure that we aren't like spinning a bunch of plates, dropping data, messing things up so the decision making process doesn't break, right? That's our diagnostic. We know that this was a problem in the past. We know that we need to actually have a system for evaluating external data and making sure that it meets the quality that we have internally, right? That's a...

That's us taking a step back as engineers and saying, hey, I see all this chaos you have. It's because we're missing this bigger framework, this bigger strategy for what's going on here. Here's my hypothesis. Here's why I think these things are going to get better. Here's why it's going to be easier to onboard new data in the future because now we don't have to make a decision every time. ⁓ And so we're not hoping that it's going to work in the future. We came up with something. Now, we could be wrong. We could be like, this is too formal. it's too strict. It's too, you know,

Carter Morgan (1:01:33)

Mm-hmm.

Nathan Toups (1:01:52)

those things could be addressable over time. yeah, this ties into my next one, which I think I brought up briefly, which is far too many companies seem to use the throw spaghetti at the wall strategy. I think it's fine, especially early on, and we really don't know. But there's a point where it's an arrested development, where you like, okay, we get it, like, please stop throwing spaghetti at the wall. we know which part's stuck. Like we now need to actually,

Carter Morgan (1:02:05)

Bye.

Nathan Toups (1:02:22)

⁓ move forward. And ⁓ I think it can be alluring to kind of have the informal yellow mode for stuff. ⁓ And sometimes you do. Sometimes you need somebody who's a willing participant in throwing spaghetti at the wall because we're kind of stuck. But ⁓ it's not appropriate for everything.

Carter Morgan (1:02:23)

Yeah.

Who's the first guy who threw spaghetti at the wall? How did we get this as an idiom? Yeah. That's true. Yeah, that's true. I didn't realize my toddler was a prolific thinker. All right. Well, as far as, you what are we going to do differently in our career? I'll go first. I already mentioned it, but we are exploring, we're starting to actually write a lot of the backend code and

Nathan Toups (1:02:42)

I'm guessing it was a toddler, right? Because they eat spaghetti and they can throw things.

innovator.

Yeah.

Carter Morgan (1:03:09)

I want to be good about writing down like what our back end strategy is. And I think you're right. Like, ⁓ I think I wish we had. I think I'm frustrated. I said this before, like it's okay to miss things. Like it's okay to ship a feature like that you intentionally know is going to piss off some of your customers. That's fine if you think it's the right move, but you have to know what's going to piss off your customers. What you don't want to do is ship a feature and then be surprised at the reaction.

Nathan Toups (1:03:38)

Yeah, Apple and liquid glass. Come on. People don't like this. Vista, Windows Vista. Yeah.

Carter Morgan (1:03:39)

⁓ Yeah, exactly. I I text my family

group chat. I'm like, liquid glass is really great if you've ever looked at your iPhone and said, I wish everything were slightly blurry. What is going on there? Anyhow, and I'm realizing we now did this with our big rewrite. I had a big document kind of explaining, know, like proposing like, okay, here's what we're gonna do. Here's the architecture. Here's this, here's that. ⁓

There was very little in it about like, what does the actual backend code look like? And I think it would have been fine to say, this is a pattern we're going to discover as we start implementing and we will revisit this. But I didn't say that it was just, it was a missed spot. And so as we actually do this, I want to be good about writing down, yeah, like what is our strategy? Like how, what patterns are we following on the backend? And we, we've got some high level stuff, but I want to be more detailed, especially in an AI native world.

This context is not just good for us, but good for agents so they can write code the way we want them to write code.

Nathan Toups (1:04:43)

Yep. Yeah, and that's actually a good point. And I will say, I appreciate this book is actually, you pretty new. It came out, I think, towards the end of last year. It's not just it. There is some talk of large language models in it from a very like pragmatic standpoint, but not a like, and even this is triply important for large language, which I find those are not going to age well. Like, yes, we live in a world that uses LLMs. That's not going to change. ⁓

Carter Morgan (1:04:51)

Yeah, yeah.

Right, right.

Nathan Toups (1:05:12)

but I will say that this book was definitely written to be long shelf life for sure. I appreciate that. So what am I going to do different? I've talked about these in the past. We've had a few things. There's kind of like trending, but wordly diagrams and we didn't talk about this in the episode today, but wordly diagrams actually play a really important role in this book, at least in the first third. I think it's going to be even more later. Wordly diagrams are a way of, of kind of surfacing the things that you build that are

novel and have to be completely custom built on a spectrum from that's in one end to commodity, meaning I can just go buy it and it works and it's good enough. ⁓ And then top to bottom is visible to the customer and then invisible, right? Invisible to the customer. And obviously, ⁓ things that are the prioritization pieces are like, what is the core of your business is gonna be something that's probably custom and towards the

customer, the visible side, right? That's when people think of you, it's the like secret sauce that is your company. But there's a lot of stuff that supports it that are layers below that. It's like somewhat visible, super invisible, maybe that infrastructure or telemetry stuff probably ties into that, but are critically important. And you might say, well, the way that we do telemetry is so new and novel that it's invisible and highly crafted by us. Well, can we get on a path in which

even though it's important, maybe we can get to commodity off the shelf, Grafana cloud, right? That yes, we need it, but we really shouldn't be spending tons of our time. And so, Wadley diagrams help us describe where we want to trend things towards commodity, where things are in the visibility. If I take a lot of engineering effort on lots of invisible things, it may not help us in the marketplace, for instance, right? That people go, they're not innovating anything, even though they might be spending a lot of time doing invisible things.

Carter Morgan (1:06:44)

Right.

Nathan Toups (1:07:07)

⁓ And so where do I prioritize? Where's secret sauce? Where's off the shelf stuff? Decision-makings and trade-offs. It kind of gives you this sort of two-dimensional way of thinking about what the engineering team spends its time on product and engineering. ⁓ And I think I've avoided Wardley diagrams because they look complicated, but I think it's emergent complexity, right? It's emergent complexity where if I think if I sat down with this data engineering project, I think it would be really good.

Carter Morgan (1:07:28)

Right.

Nathan Toups (1:07:37)

for me to do this so that I can more effectively talk to a stakeholder, like the CEO, and see what he's probably sees, right? Which is, some business intelligence dashboards and his request for certain data sources. That's gonna sit up here where like, oh, but we also have to make sure that the data pipelines and the observability and the alerting stuff is super nailed down. it's a way for us to...

understand this sort of dimensionality for what we're working on. anyway, wordly diagrams. I'm sure I'll be talking about them more. ⁓ Yeah, that's my focus.

Carter Morgan (1:08:11)

Ha ha.

Well, how about recommendations? can go first. I'd say really anyone in leadership or adjacent to leadership. I know he says anyone can write strategy. This is another one where I'm like, I wouldn't read this as a junior engineer. But you know, if you are someone who's been looking around and saying, you know, we have some problems in our organization, but how do you fix those? Like, this is a good book. And so obviously, the higher up in leadership you are, the more applicable it be to you. But if you're adjacent to it, read this book. It's a great book.

Nathan Toups (1:08:42)

I think that is a completely reasonable take. ⁓ I'll add that if you have aspirations for being staff plus or management track, ⁓ I would say there is an asterisk there of if you have big plans or you think you can make a big impact, but that would be the junior engineers who that is a clear thought in your mind. I want to be Will Larson.

Carter Morgan (1:09:00)

Yeah, okay, that's fair.

Yes, yes.

Nathan Toups (1:09:09)

I'm gonna be where Will Larson was at age 25 when I'm 25, right? Like, let's say that's a goal where you are. It's a very good goal, by the way, because he has a cool career. And ⁓ so you probably want to start thinking strategically early, right? Like that is, if that's where you want to be, even if you're not really in the place to impact it in a large scale, if you try to take on the skills of where you want to level up to, gives you the opportunity when it rises to be there. ⁓ I will absolutely say,

engineering leadership, if you're struggling, if you feel like your strategy efforts have just faltered, read this book. You absolutely need to. ⁓ I'm doing a lot of consulting work. Strategy is very important for consultant. I'm doing consulting work. People are asking me strategically how we approach them. I recently had to do some work where a really smart engineering team was struggling with how they're going to do CI, CD for single tenant deployments for this product that they're working on.

And I just kind of came in with my strategic thinking and we looked at the current thing and we figured out how to like bundle it up into this unit, thinking about it as a product. And it sounds very simple, but I had to kind of look, I had to do my exploration, I had to do these things, think about other stuff. And so even if you're in these sort of like, ⁓ you know, the right hand type role, if you're an advisor type role, thinking strategically, even without authority is super nice because you can kind of

whisper those strategies to the decision makers and ⁓ get a lot of impact out of it.

Carter Morgan (1:10:44)

All right, well, that wraps up our first part, ⁓ part one of three of crafting engineering strategy by Will Larson. Excited to tackle the rest of this over the coming weeks. You can always find us on Twitter at BookOverflowPod. I'm on Twitter at Carter Morgan. You can contact us at contact at BookOverflow.io. You can find Nathan and his work with his consulting agency, Rojo Roboto, at RojoRoboto.com and his newsletter at RojoRoboto.com slash newsletter. Thanks for tuning in, folks. ⁓

We are excited to cover the rest of this and we'll see you around.

Nathan Toups (1:11:17)

See you.