Is Strategy Worth It? - Crafting Engineering Strategy by Will Larson

Nathan Toups (00:00)

it takes a form of like experience and confidence to pick the simplest solution, right? And to always like, and to show by example, that hey, look at these things. This is the strategy and approach we took. And we found the simplest solution here. I think that should always be a moment of pride because complexity and complicated aspects like slip in so easily

Carter Morgan (00:39)

Hey there, welcome to Book Overflows, the podcast for software engineers by software engineers where every week we read one of the best single 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:51)

Hey everybody.

Carter Morgan (00:53)

Well, make sure to like comment, subscribe, share the podcast with your friends or coworkers. Join our discord link for that in the episode description. And we are back with our final ⁓ episode on crafting engineering strategy by Will Larson. This is chapters 18 through 25. We can give you the author introduction real quick in case you're ⁓ just joining us for the first time. Will Larson has been an engineering leader in software engineering, 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 the book, we 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 decisions, making, your organization's decision making.

both as an engineer or as an executive, grounding the approach and concrete examples from real companies. So wrapped up the book this week, the last couple chapters here, mostly case studies, but he does have two chapters that have his closing thoughts at the end. So Nathan, give me your thoughts on our final reading. And I guess we can talk now about the book as a whole, since we've read the whole thing.

Nathan Toups (02:11)

Yeah, so we're starting out this section with, we're in the depths of these case studies. We've been mentally prepared to actually read these strategies and kind of pick apart what the structure is, how you're presenting it. But it does get a pretty dense and I'd say some of the case studies really resonated and I was like, wow, this is cool. And some of them I was like, okay, this is a case study and I have to get through it. ⁓

Carter Morgan (02:37)

Yeah.

Nathan Toups (02:37)

But I am really

thankful that after the rest of the case studies, he kind of has this beat where he comes in and says, okay, what is a good strategy? How do I quantify whether a strategy was effective or not? How do I abandon a strategy? And again, it rounded out the book really well, right? We couldn't, I think that would have been too abstract to think about if I hadn't just slogged through a bunch of case studies. Also, I will note, the book closes out recommending a bunch of books.

And I was like, this was made for book overflow.

Carter Morgan (03:07)

There we go.

Yeah, I enjoyed these case studies. ⁓ I tend to be someone who thinks about things. I appreciate the practical applications more than the theoretical. so case studies are always at my alley. ⁓ This is just personal preference, but part of me wonders if instead this kind of case study material had been spread a little more throughout the book. ⁓ I might have enjoyed that a little more.

But some people really, really like the kind of ⁓ raw theory with the hard application all kind of concentrated at the end. I think we're going to take this episode, talk about some of the case studies that are really interested in us, and then also just to kind of riff on some of the ideas about, know, the strategy ideas, Larson has applied and how we've applied them in our careers as well. ⁓ Like we say, this is not a... ⁓

This is a book club masquerading as a podcast, not a book report masquerading as a podcast. ⁓ just whatever, you know, we'll talk about whatever we fancy. So why don't we take a quick break and we'll be back with our discussion right after that.

Okay, and we're back. Thanks for listening. Well, let's talk a bit about this chapter 20. It's a, the service architecture strategy. ⁓ and this is, I'm trying to figure out if this is, I think he puts a fake name for a company on this. I don't think this comes from a ⁓ real one.

Nathan Toups (04:38)

Yeah, and that's a good thing to note.

He talks about he'll share real company names when he can. And then sometimes we'll have to put a fictitious name because, to protect the innocent, I guess. I will say I do like the service architecture strategy because he starts it off with quoting Kelsey Hightower, which as anyone who's been listening for a while knows, I'm a Kelsey Hightower fanboy. And so it's...

Carter Morgan (04:55)

Yes.

I actually just want

to read the two opening paragraphs because they really set the stage well. says, since the first introduction of microservices in 2005, the debate between adopting a microservices architecture, a monolithic service architecture, or a hybrid between the two has become one the least reversible decisions that most engineering organizations make. Even migrating to a different database technology is generally a less expensive change than moving from monolith to microservices or from microservices to monolith. The industry has in many ways gone full circle on that debate.

While most hyperscalers in 2010s took part in multi-year monolith to microservices migration, Kelsey Hightower's iconic 2017 tweet predicted that monolithic applications will be back in style after people discover the drawbacks of distributed monolithic applications. ⁓ And this is something I think about a lot. The idea of the distributed monolith, because I agree 100 % there, which is just call a spade a spade. And if you have to work on monolith,

It is much better to work in a real monolith than the distributed monolith, which is a bunch of microservices that you have to always make sure are all running at the same time. ⁓ and, and even worse at fundamental software architecture talks about this, if they're joined at the database level, if they all share the same database and they all share, you know, have to maintain, the same database contracts, but it's across different services. Like you've just created a distributed monolith.

And we're seeing that in the industry right now. There is a trend back towards monoliths. mean, Nathan, what's your thoughts on kind of microservices versus monoliths these days?

Nathan Toups (06:34)

So I'm in the Kelsey Hightower ⁓ camp here, which is that the choice for microservices is not about performance. It's about how the teams are structured for autonomy. The cognitive load is that any distributed system is more difficult to reason about. And unless you have really clear contracts and boundaries, you're going to run into big problems. And I've seen this time and time again. I've been lucky enough as a consultant

Carter Morgan (06:44)

Mm-hmm.

Right.

Nathan Toups (07:04)

to look at a glimpse at a bunch of startups. And it's the best of intentions, but I've seen this more times than not, where you don't have a very clear producer and consumer model with your event sourcing stuff. You share databases across multiple services, which again, the reason I bring this up is who owns the schema migration, right? Do you have multiple schema migrations, which is an awful idea, never ever do that. ⁓ If you have a schema migration that's owned by one service, I would actually argue,

Carter Morgan (07:14)

Right.

Mm-hmm.

Yeah.

Nathan Toups (07:34)

you either need to fully break these things off or those three services, let's say, they're talking to this one thing, should be folded back into whatever controls the schema migration. But what you really don't want is 15 microservices for a team of three people, right? And that's the problem.

Carter Morgan (07:52)

Right. I've heard about that

where there's a microservice per person or more, right?

Nathan Toups (07:57)

Right. Now, I could see a world in which everyone literally is doing isolated solo dev work, and you really do have these strong contracts, and you really have a strong way of doing loose coupling, and you understand all the things that are negative about what Kelsey Hightower brings up. ⁓ And everyone controls their own databases, and you just kind of put this and then and then. Or you can go back to what DHH also is a great example of why

they are advocates for the monolith, even with a team of like 30, 40 plus people, ⁓ is just because they can reason about the system in a single code base. have one database architecture on the backend. They do split off into some asynchronous stuff, know, architecturally, but it's all in one place. ⁓ And I'll tell you that you, unless your goal, if your goal is to like double your engineering team every six months for the next three years, a microservices architecture,

is probably what you have to have. ⁓ Mostly because those teams, they, you're gonna get these, ⁓ you think of it like having a mutex across a bunch of ⁓ locks that you need on constrained resources. If everyone has to coordinate every time anything has to change, ⁓ you're just gonna die. And that's where the monolith versus microservices thing really pans out. And so again, it gets back to my thesis here, which is,

It's an organizational decision, right? It's an absolutely an organizational decision on how can we operate independently.

Carter Morgan (09:27)

Yeah.

Yeah, it's a and I get it from like a startup perspective because you want to be optimistic and you want to say, of course we're going to grow a ton, right? And so we should do microservices because that's going to scale. But even then I wonder if that's the right decision, because like that makes a lot of sense, I guess, if like you. So one, if you are confident you're going to grow a lot like you are growing like 5X month over month and see no signs of that stopping, because then I could see being.

in like, you know what, we've identified this really clear slice of our service like payments, right? Or then we have another really clear slice like

scheduling and so we are going to cordon that off into its own service and because we anticipate as we grow we will have a team entirely dedicated to payments and we want to set them up to for success when they get here like that's not the craziest idea in the world but you have to ask yourself what other changes you're gonna stomach with it right which is like the idea that again like you need to have separate databases for all of these things right ⁓

You need to be able to run one service without running all of the services. ⁓ yeah, I, in general, I don't know. I think about this all the time. Right. And it's also kind of like, well, what is a model at the versus a microservice? Right. Like I tend to not care so much about that distinction. Like I care that individual teams have ownership and autonomy over the systems they're working on. so.

If that is like quote unquote a monolith that has, you know, covers a lot of different business functions, but one team has the ability to, you know, change the architecture when that system goes down, they're the ones who get paged for it. They own the database schema. Like I don't, I don't care. Call it a microservice, call it a monolith. It doesn't matter to me. And I could even go so far as to say that like maybe, and he talks about that.

can't remember what case study is exactly, but basically saying that like every business unit should have their own monolith. When I was at, yeah, yeah.

Nathan Toups (11:41)

Yeah, that is in Chapter 20. He outlines it in the policy,

which I thought these policy, I can just kind of read the main headlines. And again, the purpose of this is how are they going to structure ⁓ for their work. And so our policy for service architecture is documented here. All exceptions to this policy must escalate to a staff plus engineer for their approval. ⁓ And then that has to be escalated to the CTO. So that's sort of the framing, which is business units will always operate on their own code repository.

Carter Morgan (11:47)

Yeah.

Nathan Toups (12:11)

in monolith. And I'll tell you, I'm actually working in an organization right now ⁓ of a client who they have this really, I like this distinction, they call it an app context. And the app context is this, we have this huge Terragrunt thing, which Terragrunt is like, ⁓ it terraforms terraform basically, and gives you a bunch of different layers that you can do. And each layer that we go down, we deprivilege. ⁓ So there's no super high-privilege terraform.

We have that at the outer layer, but each layer that you go in, it's more constrained. An app context is basically a monolith or a business unit monolith, where that business unit has full control. They actually have their Terraform inside. They have all these things, but it's constrained within this outside world. And so those are typically bound by some sort of monorepo for that app context. So we don't have a super monorepo for the whole organization.

Carter Morgan (12:53)

Yeah.

Nathan Toups (13:06)

But each app context kind of has this. And that way they get autonomy. They still control their CI CD pipelines. They control databases and signaling. Now we do have some ways of doing communicating upstream. Like for instance, ⁓ we are coming up with a universal spec for Kafka. So we need to have a way of announcing consumers and producers or provisioning permissions across app contexts. And so there's some like architectural things that we have. But.

It's very similar in alignment to here, which is that, hey, a business unit should basically be able to work autonomously as much as possible, right? ⁓ That new integrations across monoliths should be done with some standard communication protocol. In their policy, they say it's GRPC, ⁓ which completely reasonable conclusion to reach. I think more and more you're going to see that it'll be GRPC in probably some sort of event sourcing model or sort of event-driven.

model using Kafka or some other things so that can have these of hubs and event buses. ⁓ He also said, except for new business unit model, we don't allow new services. And I think this means that basically you're not going to be creating new independent services outside of what your business unit functions on. And there's some stuff with the CTO. And then merging existing

services into business unit monoliths where you can. instead of having some like one, you know, one team that's going across a bunch of business units, you should consolidate those down into what your team does within that business unit. And again, I think this is a nice framework for folks to go in and go, what should I do with the service? Let me go look at the policy. actually, this is all managed by the same business unit. We should roll that into our monolith for the business unit, right? I don't have to go ask the CTO every time something comes up.

Carter Morgan (14:51)

Right.

Yeah. Right, right.

Yeah, I don't mind a monolith per business unit. Like I think it's fine if there's like three or four teams working on the same code base and like there's going to be a little bit of coordination over it, but like it's all a trade off, right? Cause it's like, yes, it can be a little frustrating if maybe like you don't have a ton of control over like what your infrastructure looks like, but at the same time, like by sacrificing some of that control, you are gaining a

Nathan Toups (15:03)

Mm-hmm.

Carter Morgan (15:26)

You're pooling your resources, basically. And now that's several teams who don't all have to kind of solve the same problem over and over again. ⁓ One thing that Will Larson talks about in this book, and it's kind of a theme throughout all these case studies, is that you need to evaluate your strategy as it goes on. And you need to decide if it was, he says, something could be a good strategy when it's conceived and when it's implemented. And as time goes on,

Become a bad strategy. And he actually highlights, you know, ⁓ decomposing the monolith as exactly this, which is that at the time, and I think he was relating this to Uber basically saying that like, it was absolutely necessary for Uber with their massive scale to decompose our monolith and for new business units to be able to spin up their own services and run them. But several years down the line, they're just left with this absolutely sprawling architecture.

And it is maybe no longer a good business strategy. I don't know what you do at that point, bring everything back into the monolith. That sounds rough.

Nathan Toups (16:33)

No, think, you know, this would be really interesting to see. My guess is that they probably went too crazy with like the complete decoupling and realized that, you know, and again, if we get back to fundamental software architecture, you realize that locality plays an important role, right? How close things are to each other. should, coupling is not always bad. I guess we should really talk about this. If two things are really close to each other, it might make sense for them to be tightly coupled.

Carter Morgan (16:43)

Yeah, yeah, probably.

Nathan Toups (17:03)

Right? Or that the type of coupling, and we call it a connascence that comes up in there, can, you know, when we have two completely decoupled services, want connascence of naming, right? Which is literally, can, this is what service-oriented architecture is all about, service discovery. I can swap out a name, and then the service just like understands how to like interact with it just at a naming level. It doesn't have to know any of the inner workings. But if you actually have like a closer coupling, maybe on the

expectations around the runtime or how close they are, file systems, you know, these other pieces. It's OK if they're physically close to each other or logically close to each other. And we've seen these cases that came out. think there was some stuff about AWS had some streaming tool that they went back to the monolith. Really, what they did is they consolidated a set of business units around, I mean, sorry, a set of services around a single business unit and made a monolith out of that one piece. They didn't just like drop distributed services. ⁓

but I think that these are healthy conversations to have. And again, I think it's the second to last chapter, or maybe the third to last chapter, he gives you like a scoring system. So he basically even talks about this study with the distributed ⁓ decomposition when he goes, okay, when we started this process, the score was like seven, and seven's very high. It's like seven out of 10, I think. ⁓ And then over time, it dropped down to like a four of like its value.

And this is actually a good signal that we should maybe either abandon the strategy or modify it into a new form. ⁓ You know, take the learnings that we have, see the business is different. And I would imagine that that probably had to do with the fact that like Uber probably changed their hiring strategy, right? Or maybe there's new strategic initiative from top down on reliability or user churn or something else that actually changed the calculus of what was the most important thing to work on.

And so optimizing towards doubling your engineering staff, we know that those aren't exponentials, right? We've talked about sigmoid or the logistics curve. Eventually those things slow down. And then all of a sudden optimizing for exponentials isn't useful anymore. And I think that's kind of where we have here is that strategies can be good within the context and they change over time, right?

Carter Morgan (19:27)

Yeah, I mean, I agree. It's yeah, but I'm just laughing because it's like, at the end, it's like strategies. Yeah, like, does anyone disagree with that? You know, strategies can be good in the context and change over time. But I guess, you know, I think that is a reasonable distinction to make because like, I think less sophisticated thinkers are maybe just less experienced thinkers, again, are in the pursuit of like the

What is the one engineering strategy to rule them all? Right? Like surely if we just do what Google does, right. Then we will too be like Google. We talk about that on the podcast all the time, cargo colting. And so I think that is an important dimension for Will Larson to, to emphasize, which is like, Hey, the strategy that works right now might not work later on. And you're going to need to adjust. part of being a good engineering leader.

is using this framework to evaluate your strategy and to grow as an organization over time. ⁓ What do you, sorry, go ahead. I was gonna say, as far as other chapters, mean case studies, anyone that stood out to you in particular?

Nathan Toups (20:28)

Yep.

No, no, I-

Yeah,

yeah, yeah, I was gonna go back to, we're getting close to the end of the book, we were chapter 18 through chapter 25. I think this might have been the last case studies, and I think these were my favorite.

Carter Morgan (20:48)

⁓

chapter 22 with the stripe.

Nathan Toups (20:52)

Exactly. Chapter 22, Developer API and Acquisition Strategy. And I will say we didn't really highlight this because I think we're kind of gravitating towards technical strategy. One of the things that kind of blew my mind about this book is that the strategic ⁓ framework is used for all kinds of stuff like, ⁓ what's our hiring strategy for engineering level now that we're going to be managed by private equity? Right. Like there's these like interesting things where you're like, well, when we replace

Carter Morgan (21:16)

Yeah.

Nathan Toups (21:20)

⁓ if we ⁓ replace an employee, we're to do an n minus 1 replacement. So if we had a staff level person, we're going try to replace them with a senior level person. And I thought that was really interesting because this is how an organization that's growing doesn't also grow their title bloat and their compensation bloat and these other things. And it means that the staff engineers in that organization are truly exceptional. And that's what you want. You don't want it.

Carter Morgan (21:31)

Yeah.

Mm-hmm.

Nathan Toups (21:50)

you know, Tommy's been here for five years. It's his time to become a staff level person. You know, it's really like, Tommy's been here five years. He's so amazing. We would not want to lose him. Strategically, he's been able to, you know, or, or Sally has been, you know, shooting straight out of school and doing all this cool stuff. Right. ⁓ I think that I hadn't thought about that the constraints for the strategy job to get to chapter 22. ⁓ I thought this was like a really nice glimpse into Stripe.

Carter Morgan (21:53)

Right. Right.

Nathan Toups (22:20)

And again, you've heard me talk about this before. I'm a fanboy. think Stripe's engineering practices are phenomenal. And again, just look at their documentation. Look at their stability. Look at their approach to how there's a reason that Stripe is such a big deal when it comes to payments.

Carter Morgan (22:26)

Yes.

I think Stripe is one of those companies where like so many companies, like especially tech companies, especially in the 2010s, are like, we're changing the world. We're making the world a better place. as you watch Silicon Valley, right? We've mentioned this before on the, yeah, yeah. I love, yeah. But I love Gavin Bellson, like, I don't know about you guys, but I want to live and I don't want anyone to make the world a better place better than we can make the world a better place or whatever. I don't want to live in a world where someone is making the world a better place than we make the world.

Nathan Toups (22:50)

Yeah, I was CTO at an early stage startup a while. That show was going on. It was very painful and I loved it at the same time.

Carter Morgan (23:08)

like some insane like that.

Nathan Toups (23:09)

Yeah, it's

literally every AI startup right now.

Carter Morgan (23:11)

Yeah,

exactly. Right. Stripe, think, is one of those companies that like did legitimately make a product that made the world a better place. Like to be able to kind of unlock commerce for so many startups and to take such a hairy, sticky problem and to solve it in an incredibly developer friendly way. kudos to those guys. And like, I think about them a lot too, because like when they set out to do that, it's not like, like some ideas are just kind of

novel, like, you know, like, let's take like LLMs and transformers, for example, like that is just the result of a novel technology. And then sometimes you have something like, Uber, which is, you know, like, ultimately it's like a taxi service, right? But it is leveraging a lot of new technology. There's nothing really about Stripe when it was invented that was like leveraging some crazy new technology that couldn't have been done before, but they just really buckled down and

solve the hard problems of payments in a good way.

Nathan Toups (24:12)

Yeah,

I think the execution, also made like, they understood their target audience was somebody who was living in the world of APIs. when I was, mean, we integrated Stripe way back, was CTO 2015 through 2017. And we were evaluating things like Stripe and Braintree, which is the other ⁓ one that was popular at the time. And...

Carter Morgan (24:20)

Exactly.

Nathan Toups (24:40)

Stripe was like a, it was a no brainer in that like their documentation was phenomenal. I remember it was novel at the time, it's super normal now. They had these interactive docs where you could pick your preferred language and it would have code snippets that were like working code snippets. it was just like, or you could look at the curl requests and the JSON blobs and just be like, the data structures were right there. You felt, you realized that you're using this really beautiful API that was stable. There was just a lot of ideas.

Carter Morgan (24:51)

Yes, yes.

Nathan Toups (25:10)

I learned a lot about building web services by really deeply analyzing Stripe's web services. And of course, it was at a very formative time in my career where I was like, okay, this is what the expectations should be of a API service that's consumed by other software engineers. And so this is where I was so excited. So chapter 22 is developer API and acquisition strategy at Stripe. And it just shows...

Carter Morgan (25:16)

Yeah, yeah.

Nathan Toups (25:37)

an inside glimpse at the decision making that actually crafted the product that they had. And so for instance, like I actually wasn't aware that most of their infrastructure was this Ruby monolith. ⁓ And that they use this thing called Sorbet, which again, I'm not part of the Ruby community. ⁓ I used some Ruby in configuration management stuff because early days of Puppet and Chef are all Ruby. It was just like the popular system and language back in the...

Carter Morgan (25:50)

Yeah, that was I.

Nathan Toups (26:07)

late aughts, nots in the early 2010s. ⁓ But then most things switched over to like Python and Go for people in my career path. it, yeah, yeah, yeah, yeah.

Carter Morgan (26:16)

Yeah, I've worked in Ruby before yet. Or just mentioned

Sorbet. I've worked in Ruby before. I don't love Ruby. But yeah, I knew about Sorbet. I never liked, like, I appreciate the idea of Sorbet. Sorbet is just a type checker thrown on top of Ruby. And I was a little, that's one of reasons I don't like Ruby. I'm like, maybe your language should have just been typed from the beginning. But I was shocked to find out like Stripe invented this. And they invented it because they were looking at the choice of like, do we...

Nathan Toups (26:25)

Yeah.

Carter Morgan (26:45)

migrate from Ruby to a strongly typed language, right? Which I think most people would just make that decision. like, let me tell you, as someone who's in the middle of doing a rewrite from Java to TypeScript, it's a, we are just kind of, we have an aggressive timeline, but ⁓ only with the help of large language models. And even then those large language models are only able to succeed so much because they are.

Nathan Toups (26:48)

Like Java, right?

Carter Morgan (27:09)

analyzing existing behavior in another system and reproducing it. But anyhow, it's tough. It's tough to do a rewrite in another language. And so, yeah, like I was shocked that Stripe, rather than doing that, they said, you know what, let's invent a Ruby type checker and we will, you know, like, that's crazy.

Nathan Toups (27:28)

And yeah,

I thought that was interesting too, because we have these interpreted languages that are optionally typed, right? So this is Ruby, I guess, goes this route through Sorbet. think Python has been on this journey as well. The entire reason that TypeScript was invented. And again, type annotations are really useful, turns out. And the people who are in strongly typed languages, like Go or Java or C++ or Rust, they have their own

Carter Morgan (27:36)

Right.

Nathan Toups (27:58)

benefits to reasoning about the system, especially having the compiler or the JIT ⁓ reasoning about the system. And while it does introduce some formality upfront, there's reasons. soon as you start having a lot of people writing code, it becomes really difficult to reason about something that kind of tries to do type coercion, or tries to do the best guess of what you actually meant. That's the thing about Ruby and Python is that you can feel very productive, and it's really

amazing for exploratory work. I think one of the reasons that Ruby was so popular is that it's really easy to write what are called DSLs, or domain-specific languages. So most Ruby communities that I knew ended up writing a bunch of meta-programming patterns. They write their own subset language that lives inside of Ruby because it's the super expressive, object-first sort of thing, and encourage this as a community. Turns out that...

Carter Morgan (28:43)

Yeah, yeah.

Nathan Toups (28:55)

when you start getting into performance critical applications, it can be pretty terrible. ⁓ But, and I would argue, most companies aren't dealing with that. If you do get to something where every CPU cycle matters, you're probably gonna switch languages anyway. ⁓ But what I loved about Stripe, yes, they mentioned Sorbet, they mentioned some other things here, there's some really cool stuff, but I loved this particular section on ⁓ how should Stripe deprecate APIs?

It sounds like such a dry topic, if any of you've ever dealt with API development, this is incredibly important thing. ⁓ I would say if you're dealing with databases, temporal data and changing things over time, I think when you're talking about APIs, it's how do you design it so that you can ⁓ reduce these deprecations? again, here's the policy. I'm going to just kind of give the high level. You should design your design for a long

API lifetime, right? So this idea is that once you've created this thing, people are going to use it, and they're going to continue to use it, and you have to support it. that, first of all, puts this thing on your shoulders that, this needs to be an elegant, well-thought-out design. If I just kind of like throw a bunch of crap out there, ⁓ I'm going have to live with that thing. And so a nice REST structure where I have this nice hierarchical ⁓ ID system, that I have this elegant response structure to it, that

maybe I can extend it, but I don't break it backwards compatibility. You know, it puts this culture at Stripe of you really need to think about this thing. It's going to live for a long time. You can't just get rid of it. ⁓ All new and modified APIs must be approved by API review. So they actually put friction here, which is they have this API review board. ⁓ And they basically say, hey, does this meet our standards? Right. And this is a good learning moment internally to be like, hey,

I see where you're going with this. It's a cool idea. This is not an RPC endpoint, though. We're doing REST APIs, right? We want to think about these objects that are coming back, not communicating between two servers or whatever, right? Whatever might come up. Then we never deprecate APIs without an unavoidable requirement to do so. That's a super high bar, right? That policy is basically like, hey, we're going to support v1 of the user API endpoint until we die, unless...

Carter Morgan (31:00)

Mm-hmm.

Yeah, yeah.

Nathan Toups (31:21)

there's such a critical security vulnerability, right? Or some other unavoidable piece where we force some migration to v2 of users or whatever. ⁓ But this is a beautiful policy. The next one was ⁓ when significant new functionality is required, we add a new API, right? And so again, it gives you this escape hatch. We need to have those. Or you can make this new API endpoint. But of course, you have to go back to all the previous steps in the policy. have to get through the review board.

Carter Morgan (31:40)

Yeah, yeah.

Nathan Toups (31:52)

We manage this policy's implied technical debt via an API translation layer. And again, these get pretty technical. We don't have to get too much into the details, but I love this policy really hops into all of these pieces. And then they also say, hey, in the future, we might soften this policy. In the future, we might have such mature practices that you don't have to go through every little piece of this. And of course,

Then they go through the rest of the structure for the strategy on like diagnostics and what this will impact. ⁓ I think that their big thing here was that ⁓ by not holding themselves to this standard, they're going to have customer churn, right? That was their primary concern. And which I think, again, is super high framing. Like, hey, if you don't follow these policies, we're going to lose customers. And here's the data to back it up, right?

Carter Morgan (32:34)

Yes.

Well, especially like API design is something that could absolutely fall in the domain of like, ⁓ you know, very disconnected theoretical engineering. Like we take pride in our APIs, but I, they very correctly identified it as a business problem. ⁓ and I thought it was neat that they, ⁓ yeah, like you said, like they would maintain backwards compatibility just ruthlessly for these APIs. And they identified that like,

Customers who were maybe on the verge of churning could be kept by having ⁓ strong support for existing APIs. But the moment you tweak something even slightly, an old API introduced a breaking change, that's where customers who might have been dissatisfied with the product in other dimensions, they use that as the off ramp. They're like, okay, well, you know, we either need to accommodate this breaking change or switch to a new provider. And we already kind of wanted to switch to a new provider. So let's just do that.

Nathan Toups (33:44)

Absolutely. you just think about it, right? Think about it in any organization you've ever been. You have some new person that joins the team. They just have a personal vendetta, right, against, or they really loved this other payment processor, right? So they're looking for every little piece of evidence that they have that their decision's actually the better one. What Stripe would never want is it to be reliability. Like, like, you know, I don't love Stripe that, you know, like this person might be like, hey, I don't love Stripe, but they're super reliable. I understand where you're coming from.

Carter Morgan (33:53)

Right.

Nathan Toups (34:12)

But if that flipped over, ⁓ no love lost or, you can think of the other one, which is you advocated for Stripe in your organization and Black Friday comes around and you can't process payments because the API is unreliable. You could potentially lose your job. You could potentially have all these things. so when you're making decisions about which technologies you advocate, obviously Stripe needs to be in that sort of gold tier of reliability.

for you to like bet your business on things like that. And I think the fact that they've taken things that seriously was cool, right? And again, a written down strategy document saying this is why we build things this way is it completely justifies things like, know, somebody might come in with a reduced friction initiative and be like, the API review board, that slows people down. We shouldn't do that. And they're like, actually, if you break this API, we have to own it forever.

and the stakes are way too high, we need friction here. You need to be really thinking about how you're structuring this so then you can ship fast everywhere else, right? So yeah, I thought that was really cool.

Carter Morgan (35:22)

Yeah, it's a.

Nathan Toups (35:23)

Shifting

gears a little bit in this chapter, so I'm not going to get too much into this rubay and why did Stripe build Sorbet. One of the things that stuck out to me as they were justifying this, I think this was under the diagnostic section, this was just a perfect metric here. Looking at our productivity metrics, our test coverage remained extremely high with coverage above 99 % of lines. Tests are quite slow, but run locally. ⁓ Sorry, so they run quite slow to run locally.

Carter Morgan (35:46)

wow.

Nathan Toups (35:53)

They run quickly in our infrastructure because there are multiplexed across a large fleet of test runners. And this is one of the justifications here was ⁓ if I could lean on my type system, I could have more confidence that the things were at least structurally correct and I could run that Sorbet checker locally. And so it'd be a lot of certainty here and I wouldn't just break tests in stupid ways, right? It's not a replacement for testing, but anyway, ⁓ 99 % plus test coverage. I think a lot of organizations would consider that

Carter Morgan (36:16)

Right, right.

Nathan Toups (36:23)

excessive. I've been in organizations, though, where we had a rule on hot code paths had to have something super high. think ours was 98%. ⁓ It was, again, fintech. So really

Carter Morgan (36:24)

Yeah.

How did you determine

the hot code path?

Nathan Toups (36:38)

Yeah, what was it? ⁓ We actually had an analysis tool that would show, what did we do? We basically, I think that we would look across all of our tests and the ones that had the most passes along those lines of code were considered hot code path. You know, I actually don't remember. It might have been something that was also aesthetics, right? Like hot code path for us was, ⁓

Carter Morgan (37:05)

right.

Nathan Toups (37:07)

some transactional thing that had to happen with the lowest latency possible. And so we would look at that signal chain and just go, OK, everything here has to get, you know, from this function call all the way up to the database, we need to have this in place. And then I know that with projects like Go, and I think other test runners have this too, they actually give you like a graphical ⁓ interface to show which lines of code have test coverage. And not only that, but they will like, it'll be darker green.

Carter Morgan (37:10)

Right, right.

Nathan Toups (37:36)

for the ones that have been passed multiple times in various tests, and ones which may be like, you know, ⁓ a Boolean flag somewhere that maybe has like one test covering it, and it'll graphically tell you, like, yeah, it's covered, but you aren't checking both the pass and the fail of this Boolean or whatever. So, I don't know. ⁓ There are certain critical organizations in which we have a stable API.

Carter Morgan (37:54)

Mm-hmm.

Nathan Toups (38:04)

we have a stable workflow process where we would just crank down on test coverage because we really wanted to make it difficult to just break something in a stupid way, right? Which, yeah, but,

Carter Morgan (38:14)

Right, right.

Nathan Toups (38:38)

yeah.

Carter Morgan (38:39)

This is not strictly related to the book, but I've been thinking about it, which is as you advance in your career and you're in charge of setting strategy, like, I think you can sometimes wind up a bit with like the curse of knowledge, which is like, you will create a strategy and then your team will execute on it. And you're kind of like, well, anyone would have come up with that strategy, right? Like anyone would have, anyone would have figured it out. Like this is child's play, right? And then I don't know, like,

And I think it's also like this balance between like when you're working with a really good team and everyone's just executing, like firing on all cylinders, you can kind of feel a little like, what, what am I even doing here? Right? Like what is my, it seems like if I left today, everything would kind of just continue on without me. And like, maybe that is the answer. Maybe things would continue on roughly fine without you. And that's just what working on a good team is like. Cause like the opposite is to work on a bad team where you are the hero.

Right? And you know, everything and if you leave everything does grind to a halt, but like, that's a way worse place to be. Um, so I guess, I don't know, like, do you have any thoughts on that? Like, how do give yourself credit for, you know, like, leading out on things and, and when, when do you recognize yourself as a force multiplier versus just like, well, I'm just doing what anyone else would have done.

Nathan Toups (39:41)

Yeah.

Yeah, I don't, I'm trying to have empathy here because I don't think I've ever thought I would just do what anyone else would have done in this situation.

Carter Morgan (40:17)

I think it's more to me, like, I'm thinking about it right now, like this re-architecture. Like, I'm actually very pleased with how this re-architecture is going. It's a lot of work, ⁓ but I'm the lead on it and kind of came up with the plan for it. And like, it's been going really well. And there are some design decisions, I say we've made, I made them, right? ⁓ That have worked out really well for us, right? Like, for example, our decision to, instead of getting some sort of enterprise data transformation product,

Nathan Toups (40:17)

Hmm.

the Royal We.

Carter Morgan (40:45)

Instead, going from Mongo to Postgres, we just ported all of our Mongo stuff over to very dumb Postgres tables that are just, it's just a one-to-one mapping to collection with two columns, ID and document. And then we wrote a bunch of trigger functions, which when the dumb tables change, they transform the data into the new ⁓ relational shapes, right? And so that's worked out really well for us because,

We've noticed as we've been doing the actual migration, getting stuff in production, we're like, wait a minute. We messed up this function right here. And instead of having to go into like some big enterprise product and figure out like how the freak do we do this? Like it's super easy. You just rewrite the trigger function, right? And it's often like a, you know, a five line change. ⁓ or another thing is like, I was very insistent that, ⁓ and I learned this from the DevOps handbook, right? This idea, you got to decouple feature releases from code deployments. And so.

Our front end was very tightly coupled to our old GraphQL implementation. so I said, I said, the very first thing we need to do is we need to decouple that. And we need to define these kinds of like transport neutral, models that the front end will consume. And then we will have a layer in the front end that queries the backend and transforms the backend data into these transport neutral models. And that way we can have both our legacy GraphQL implementations and our new REST implementations.

at the same time and we'll just control it with a feature flag. And so, you know, ⁓ and so that's been really nice for rollouts. And like just the other day, like we had tested this feature locally. looked good. We're like, okay, this makes a lot of sense. We released it and it turns out there was like this edge case that like maybe 10 % of users had that we just didn't account for in our testing. And we had someone report it to us and then we were like, our bad. We clicked a button and rolled back to the old version, fix the bug and then released it and then click the button again. And so like,

Nathan Toups (42:40)

Amazing.

Carter Morgan (42:41)

Yeah, and so like it's been going like it's just one of those things that's just like and especially when you're at a startup where like we're gonna mess some things up, but we haven't messed anything up in a really critical way and we've been able to recover very very quickly because of it. And so like I guess like I'm very happy with how it's all going, but I also kind of like I think you just like cumulate so much knowledge and especially like you and I because we read so many of these books that I think like well anyone would have come up with this strategy like isn't this just common sense isn't just this how you engineer.

Nathan Toups (43:09)

So

I would argue that you should probably get that out of your mind. And the reason I'd say that is because if you actually look at like the, you know, it's like the bell curve joke, right? Where we have like the smooth brain and then we have like the Jedi master. know, understanding with all of the constraints that you have, the lowest friction, most elegant, least moving part solution is

Carter Morgan (43:16)

You think so?

Yeah, right.

Nathan Toups (43:39)

the big brain thing, right? It's the Jedi master way of doing stuff. ⁓ it takes a form of like experience and confidence to pick the simplest solution, right? And to always like, and to show by example, that hey, look at these things. This is the strategy and approach we took. And we found the simplest solution here. I think that should always be a moment of pride because complexity and complicated aspects like slip in so easily

Carter Morgan (43:41)

Right, right.

Nathan Toups (44:07)

and

Carter Morgan (44:07)

Right,

right.

Nathan Toups (44:08)

any time that we're guilty of it ourselves, having a way to do an honest assessment and moving forward and being like, man, you know what? Didn't think about that one. How do we prevent that in the future? Is there a way that we can amend the policy? But I actually think this stuff is hard and that it takes time, especially when you're really good, it might look easy or even feel easy. I forgot who it was.

Carter Morgan (44:25)

Right.

Nathan Toups (44:36)

I don't remember what book it was years ago that I read that was talking about exceptional actors, right? An exceptional actor, ⁓ let's say Tom Hanks or, you know, something like this. might, he prepares for the part, he reads the script, he does, he knows his lines, he really gets into the mind of the character, he does his performance. But doing that performance that day might feel like the most natural, wonderful thing.

Carter Morgan (44:43)

Mm-hmm.

Right, right.

Nathan Toups (45:07)

And it doesn't

diminish the fact that what he's contributing isn't just literally irreplaceable, right? You look at him in like castaway, which is like classic, you know, classic movie. His performance in that is phenomenal, right? He went through all this stuff. He like basically lived as if he was living on an island for a year and a half or whatever and got lean body mass and long hair and all these other things and transformed from this like kind of doughy corporate guy. And it just is so believable. Like you watch him in this movie and you're like, oh, wow.

Carter Morgan (45:12)

Mm-hmm. Right.

Nathan Toups (45:36)

And that doesn't diminish the fact, like he shouldn't be like, man, if he's not struggling to barely get through the next day, he's not pushing himself hard enough. I disagree with that, right? Like think that there's a point in which you are, you've arrived. You can actually just be your, essence of yourself and you're providing the maximum amount of value for what's there. And I think that that's kind of where you are. If like you get into a good role of strategy, you may just look at this with more clarity.

Carter Morgan (45:44)

Right.

Nathan Toups (46:05)

and everyone around you and you go, oh, this seems intuitive to me. It seems natural, but that's exceptional actually, right? Like if you do this and you aren't causing outages and you now make it easier to roll back and you do all these other things, that's actually the super valuable thing that you're bringing to the table. And the best part is it was fun or it felt like a game, right? Right?

Carter Morgan (46:10)

Right.

Right. Yeah. Yeah. Well, 100%. Right. I think all

the time about how it's hard to compete with someone who thinks they're having fun. And, and I guess that, you know, like now that I'm taking a step back and thinking about it from my perspective, like even just that, that first chunk, which is like, Hey, for our front end, we need to like rewrite a significant amount of the front end to decouple. didn't rewrite any of the business logic in the front end, but you know, from like an architecture perspective to just couple it, to have that migration seam, that's a completely unintuitive idea. Like you're like, Hey, we need to rewrite.

our back end, right? And the very first thing we need to do is actually change our front end in a completely non-functional, you know, in a way that does not implement business function at all. And I think I could see a less experienced thinker being like, what are you talking about? Like, we have so much to get done here. And the very first thing you want to do is something completely unrelated to the core work that's going to happen. But it is only that, you know, I guess,

experience or maybe knowledge gained from hosting a podcast where you read a software engineering book every week, ⁓ you know, and where you say like, hey, but this is necessary.

Nathan Toups (47:30)

Well,

it also gets back to this idea of like, you know, I've talked about this before, but slow is smooth, smooth is fast, right? There's this idea from special ops or the Marines maybe that talked about this. And again, you can think about this with a very concrete example. You're tasked with pulling a bit on the shore, right? And if you just try to frantically do it by yourself, you can't do it, it's way too heavy.

Carter Morgan (47:41)

Yeah.

Mm-hmm.

Nathan Toups (47:58)

If your whole team is trying to pull it five different directions, you're all working really hard. Nobody's debating that you're not working really hard. You're all grunting and groaning. One of you is pulling it this way. One of these pulling this way. The two of you are going this way. If you take a step back and you throw this thing on your shoulder, all of you, and you decide to walk in the same direction together, it might be that you're walking slower than you would have if you were by yourself with no boat. But as a group, you can now move this boat with purpose in the right direction.

Carter Morgan (48:22)

Right.

Nathan Toups (48:28)

And so this idea that you now are more effective at accomplishing the goal, which is moving this boat from one place to the other, where you couldn't have done it ad hoc and crazy. You couldn't have done it with everybody does their own thing. ⁓ You come up with a policy and a strategy, you do this thing together, and now as a cohesive unit, you're doing stuff that was absolutely impossible before, right? And that is such a simple like, that's such a simple little like example, but it's literally what we're doing with software development, right?

Carter Morgan (48:56)

Right, right.

Nathan Toups (48:56)

Are we investing

in things that actually are moving stuff to the direction that we want? Do we have leadership and a strategy that says, hey, what if we all threw it on our shoulder and walked in the same direction? They go, that's a great idea. You would think anybody would do this, but until somebody actually said it out loud, you are the genius for actually getting everyone to be on the same page, right?

Carter Morgan (49:19)

That makes a lot of sense and I appreciate the brief detour into ⁓ my software engineering therapy session. ⁓ But it's a. Yeah, and also God.

Nathan Toups (49:31)

No, no, we're in a similar, but we're like, we have some really cool, we're balancing this sort of like ideal architecture with how do we ship value on a regular basis. Because we have a bunch of processes that this one organization I've been working with where they do a lot of things manually in Excel. I think I've talked about this a little bit. And we have this like really cool Databricks data engineering pipeline stuff that we're doing. Some of it's really kind of,

Carter Morgan (49:41)

Right, right.

Nathan Toups (49:59)

re-imagining how we even think about any of the data that's coming in, coming up with like really nice patterns. And so we've kind of figured out this kind of cool way of giving these short-term gifts of chaos, plus always moving it in the right direction of the bigger picture. So it's like, we play this little game of, I solve a little bit of short-term pain directionally towards this ideal architecture?

Carter Morgan (50:23)

Right, right.

Nathan Toups (50:25)

Which is such a fun again. It's a fun thing to think of it's like looking at a puzzle and going like Can I move this directionally in the correct way and is it the right balance with my long-term goals? And this is why this book has actually come in at such a perfect time because You know not just having this as a group chat Writing it down setting out your intent Diagnosing the problem. It also makes it much easier to communicate with other stakeholders that might go. Why are you any time?

on this large long-term architecture because we have fires that we need to put out here, right? And so this way we can get buy-in on like, okay, ⁓ you you actually, let's turn off the burners in the kitchen that are, of the stuff that's burning down. And we also need to like put out the fire, right? We need to turn off the source and put out the fire, right? But yeah.

Carter Morgan (50:58)

Right, right.

Yeah, it's a, before we kind of cover the last chapters, I was just looking at through some of the notes I highlighted. I just wanted to point out something ⁓ Will Larson says, because I think, you know, when you're thinking about like, again, coming up with strategy and especially ⁓ when you're first starting out and first starting to do strategy, it can be hard. can be hard to know what the right thing to do is if you don't have a wealth of experience. I will say that Will Larson says,

that he recommends reading. He recommends reading broadly. And I've noticed great benefits in my career just from all the reading we do on this podcast. And I hope that you, the listener, are getting some of those benefits ⁓ too by osmosis just from listening to the podcast. As always, if you're ever covering a book and you're listening to the episode and thinking, that sounds interesting, pick up the book, read it. ⁓ But if you're kind of like, well, I...

don't know if I can just kind of manufacture strategy from whole cloth or I don't have the wealth of experience necessary to create strategy. He, in the Calm Strategy documents, he says, these documents capture a different approach that I've consistently found more effective, identifying approaches that are already working well within the company and eliminating the less effective competing approaches. So kind of like in Made to Stick, how they say like, hey, you don't need to come up with these.

fantastically sticky ideas. You just need to be looking for the naturally sticky ones in the wild and then leveraging those. It's kind of the same with like engineering strategy. Like just look around. Do you notice any teams that are doing something really, really well? And if they are, go have lunch with them, go set up a Zoom meeting with them, you know, just find out what they're doing and then try to apply it to yourself. And then, you know, conversely, maybe it's not something that you need to start doing. Maybe it's something you need to stop doing. And

Nathan Toups (52:57)

Yep.

Carter Morgan (53:07)

In the final chapter, he's talked about how much strategy can you do? And he says, it's all just a matter of altitude, right? Which is that, don't try to implement a strategy that you don't have the authority to enforce. If you find yourself gravitating towards that, you're going to be frustrated. It's all just a matter of coming down to the right altitude where you do have the ability to influence your team or your org or what have you.

Nathan Toups (53:33)

Right.

Carter Morgan (53:35)

And that's kind of where you need to be focusing on implementing your strategy.

Nathan Toups (53:42)

Yeah, I concur because if you try to be strategic at a level that's not appropriate, you will get incredibly frustrated if you're emotionally invested in it. It's just like any friend from your hometown who's like will tell you how they'd fix the budget in the United States government. I'm like, doesn't. Great strategy, bro. But no one cares. You have no authority to make any impact on this. Though I do feel the frustration, right?

Carter Morgan (54:00)

Right,

Yeah, yeah.

Nathan Toups (54:10)

You look at some systemic problem and you feel powerless against it. ⁓ In an organization, it's figuring out the strategies that actually can have high impact and or within your domain. Or can you be compelling to maybe somebody that's one or two levels above you? I did something similar to this when I I realized systemically when I was in the platform engineering team in a company called Flyer that we really were not.

meeting our own standards on developer experience, and that we needed to use GetDX, which is this phenomenal software. I had to go to my skip and really pitch this idea. And I just started making the rounds doing this, saying, hey, if we should use this as a pilot on this one project that I have control over, that we were trying to deal with a lot of engineering strife that was going on,

Main thing I realized is that Boots on the Ground had a completely different story of the health of things from management. And management is who is talking to executive leadership. And I was like, I need quantifiable data on how to have a real conversation about this without pointing fingers, but saying, hey, there's a disconnect. And I pushed it to executive leadership as if we can pilot this here, I actually think this is applicable to the rest of the organization. Now this is presumptuous of me. If I didn't have a

an enterprise sponsor, you if I didn't have an executive leadership sponsor, the whole thing would have fallen apart. But I caught the attention of ⁓ our chief product officer. He was very interested in the fact that maybe this could work out, right? Somewhat skeptical, maybe it was too high in the sky, but we ended up rolling it out. It was a success. And then we actually were able to roll it out to the rest of the organization. And ⁓ it was something that I felt a lot of pride over, right? It was one of those where...

I used the strategic approach. held myself to a high standard of having data to back it up. I tried to pull, rally the troops and get people along. I had no authority to do this other than, hey, don't you want to make an environment that we're all happy to work in? ⁓ Wouldn't you like to know why this exceptional team, which we all know is exceptional, is exceptional? Like, is there data that we can look at and say, why is the struggling team over here? Why is this exceptional team over here? And it was really cool. ⁓

And I honestly, again, I wish this book had been there because I think I probably would have been able to make more compelling arguments built off of this. That would have been been really nice. One of the things I loved in the, I'm sorry. Yeah. Oh yeah, that's right. So one of my favorite thing in the final words for the book was there's a little section on operating your strategy improvement policies. So this is basically like, how do I do continuous improvement?

Carter Morgan (56:37)

Well, let's wrap up. go ahead. No, you wrap up with your thoughts and I want to make sure we get to our hot takes.

Nathan Toups (56:56)

on my strategies, it's kind of meta, but he's basically said, write your stuff down, review your strategies on a quarterly basis. There's all these other things, but he he talks about the gripes that people might have, which is I'm too busy for strategy. And he gives you sort of like three things. He's like, hey, look, if you're not tracking your strategies, start tracking them. If you haven't worked on a single strategy in the past six months, pick one, pick one strategy.

If you implement a strategy that's been prohibitively time consuming, focus on practicing ⁓ a strategy. Let's see, if you've implemented a strategy has been prohibitively time consuming, focus on practicing a strategy instead. So practicing the execution of an existing strategy, basically. And he says, you don't have, if you can't do, if you don't have time for those three, maybe you should just, what is it?

if you don't have time for these three, then maybe you just don't view strategy as particularly important. You should spend your time doing something else, which I thought was kind of fun. Same thing as like, I can't lose weight. And you're like, well, do you count your calories? Are you working out? Are you doing these things? They're like, no, I'm I don't do any of that. Okay, well, I don't think you really want to lose weight. Like that's kind of the same idea.

Carter Morgan (58:14)

Right, right. Well, let's get some of our hot takes and then move on to who will, you know, I stand to wrap up who would you recommend the book to. The only thing I'd say is that I don't disagree with this in theory, but he says if a strategy starts out bad but improves quickly, that's better than a mostly right strategy that never evolves. Like.

I think I read this, was right after he's talking a bit about like how you shouldn't evaluate a strategy based on its outputs necessarily. Like that is one dimensional along which you want to evaluate it. ⁓ I think he mostly gets this all right, but I was just a little like, I bristle a bit of engineers, like I just know the kind of engineers who are like, it's done when it's done, right? Like, and it doesn't matter and like, you know, like we...

we will do things because it's correct and we don't really care about the output. I'm like, I don't know. It's a business guys. Like we have to make stuff that makes money. And so it's not really anything Will Larson said, but like I could see an engineer reading that and being like, well, it doesn't matter that we screwed up really big in the beginning. So long as we got better, I'm like, it might matter that you screwed up really big in the beginning, right? Like it's, you try, it's better to be correct and, and ship value. ⁓ then, ⁓ you know,

have

The process is good and it's good to have an ever evolving, ever improving process. like, you know, you can't just point to the process and say, but look how much better we're getting. Like sometimes you just need to be good from the get go. So I don't know. Yeah. No, no, limits of whatever company you're at. I guess that's just common sense for, you know, any piece of advice.

Nathan Toups (59:54)

My two hot

takes are actually quotes from not in the book. ⁓ And they're both on some, I was just looking up some quotes from famous folks on strategy. ⁓ I think this, what you just said, this ties into this Peter Drucker, very famous Peter Drucker quote that says, eats strategy for breakfast. Meaning, if you have folks that just won't follow the strategy, right, they have, it's done when it's done, right? That's a cultural thing. ⁓

What that tells me is that I don't need accountability because I'm such an artist. I'll go off onto the mountain and come back with the 10 commandments and when it happens, it happens, right? And you're like, I'm sorry, but that's not gonna help us. We might die in between those moments. And so maybe you can come back with two commandments and we could decide whether we need to keep going. ⁓ And ⁓ the other one was that Dwight D. Eisenhower says, plans are nothing.

Carter Morgan (1:00:25)

Bye.

Yes.

Ha ha

Nathan Toups (1:00:50)

planning is everything. And the reason I bring this one up too is that I think that crafting engineering strategy is really about meditations and thinking deeply. And that it actually is less important that you have this like perfect plan. And it's more important that you're spending time planning, right? You're spending time thinking strategically of, we have this problem. We think that if it gets expanded out to this, it's gonna be even a bigger problem. Here's what we can do to minimize this, right?

We have some really cool upside. How can we use this upside to benefit us in other parts of the business, right? Just the practice of doing this takes off the burden of having to have the perfect strategy, right? ⁓ And just spending time being like, can I get so good at coming up with pitching a strategy in a high impact but low turnaround time thing? And then we also get good at abandoning strategies that aren't serving us well. And these other things, I think...

Carter Morgan (1:01:33)

Right, right.

Nathan Toups (1:01:50)

There's something to be said for this, ⁓ even outside of the formality that we have in this book.

Carter Morgan (1:01:55)

And I think as software engineers, we need to get much more comfortable operating in that kind of planning space because in a world with large language models where producing code has gotten cheaper, there was something to be said about like, let's just start. We'll get in the flow. We'll kind of find it along the way. But right now, that skill to kind of get in the flow and crank out a ton of code is not nearly as valuable as it used to be. And because you can crank out code so fast, it's easy to...

Nathan Toups (1:02:04)

Yep.

Carter Morgan (1:02:24)

Get something that works and be like, okay, great. Moving on. But if you just spend a little bit of time thinking about it and planning and coming up with the right architecture, like it can make your life a lot easier in the future. And so I think we've talked about this a lot, but like, we just now live in a world where like, if your skill is I translate English to code, like you've been replaced by a robot, but I happen to believe, and that's kind been the whole thesis of this podcast, right? Is like software engineering is much, much more than that. In fact, that's

like this whole podcast is a testament to the idea that software engineering is more than that because as almost a rule, we have never read any very language specific books. The closest we ever got was advanced react. And we kind of made an exception because react is like the most popular front end programming framework by far. ⁓ and so already software engineering is not translating English into code, but I think if that's something you've taken a lot of pride in, like, yeah, just, you know,

Try to level up, try to move more into the strategy direction. ⁓ Spend time planning, spend time thinking, and that's where I think a lot of our leverage is gonna lie in the coming days. As far as who we're, I mean, what are we gonna do differently in our career? Because we read this book. ⁓ For me, I just wanna take that strategy evaluation framework he talked about ⁓ and apply it to especially.

Nathan Toups (1:03:35)

Love it.

Carter Morgan (1:03:48)

I mentioned last week where like, just need to be better about like documenting, like we have a strategy right now. And it was roughly articulated in kind of my initial proposal doc, but like, I think it'd be good to go and like write down specifically like, okay, what was our strategy for, you know, this big rewrite and what is our strategy kind of moving forward? And then I just want to be better like six months from now, just looking, evaluating it using his framework, giving it a score and saying, okay, you know, how did it do for us when we implemented it? How was it doing for us right now?

What do we need to change?

Nathan Toups (1:04:19)

Yeah, I love that. Yeah, part of riffing on that is just giving myself a beat to think a bit more before doing something. I'm pretty contemplative. again, in Claude, I spent a lot of time in planning things like this. I do think about these, of hyper-local strategic pieces. The other thing I've kind of indirectly with this is sometimes we have these spectrum and development frameworks that we're using increasingly, which has things like a FD, what?

Carter Morgan (1:04:33)

Right, right.

Nathan Toups (1:04:48)

functional design review and some other stuff. But even if I've made an architectural choice for something relatively small, recently, Databricks, and I'll bring this up for like two seconds, ⁓ we wanted to wait a standard way of naming things in Azure Key Vault ⁓ so that we could use it in the Databricks ⁓ secret storage. And I just wrote a little ADR of just like, here's our design decisions, here's how we do namespacing, here's how these things, you know, here's the...

the updates to the libraries, here's the ones that need to be updated in the future, just a little quick little ADR sitting next to my code for the code review so that I can sort of like say, hey, this is a very deliberate choice. We should make a very deliberate new ADR to how we do secret storage if we want to in the future. But like this is an elegant pattern. I had examples of folks in the industry that use the same pattern with other libraries. So anyway, like I'm already trying to say like, can I fit, you know,

altitude appropriate strategic thinking even into smaller changes to say, look, this is a purposeful design decision. This wasn't vibe coded.

Carter Morgan (1:05:56)

Well, what about ⁓ book recommendations? For me, it's the same as last week. Just I think if you're in leadership or adjacent to leadership, go ahead. You've given more general purpose recommendations for this?

Nathan Toups (1:06:02)

Same.

Yeah, so, you know, I said solid career development book. So, you know, if you're an engineering leader, I agree on this. if your aspirations are to be someone who is thought of as a strategic thinker in your organization, this book is an incredible framework for just how to grow as a strategic thinker. Even if your impact is low now, looking for those opportunities, thinking about how you can solidify your ideas, looking at good case studies. ⁓ You know, if this kind of topic sounds interesting to you, this is a must read, must read book.

Carter Morgan (1:06:39)

I'm glad we read it. It's been a good, I was thinking like, wow, a three-parter, it's rare that we do those. And then I was looking at our next schedule. We got another three-parter coming up. We've got software architecture, the hard parts, modern trade-off analysis for distributed architectures. I'm excited about this one. This is another Neil Ford, Mark Richards, Promo, Satelage, and it looks like have a new contributor this time, ⁓ Jamak Degani. I will try to learn how to pronounce that better if I did it wrong. ⁓ And yeah, we've got a...

So that's going to be a three parter. I'm excited. Fundamental software architecture was, of course, the winner of our March of Madness style bracket last year. that'd be nice. That'd be nice. Yeah. OK, with that, thanks, everyone. You can always find us at bookoverflow.io. You can find us on Twitter at BookOverflowPod. I'm on Twitter at Carter Morgan. And Nathan has worked with his consulting agency, Rojo Roboto, at rojoroboto.com, with his newsletter at rojoroboto.com slash newsletter. We'll see you around, folks, next week.

Nathan Toups (1:07:14)

Right? Can't wait. Hopefully we have those guys back on because they were awesome. Yeah.