Second Look: Team Topologies, 2nd Edition

Carter (00:00)

I feel like we had a word for this back in the day that was not nearly as sexy as Forward Deployed Engineer.

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

Nathan Toups (00:24)

Doing great. Hey everybody.

Carter (00:25)

Well, make sure to like, comment, subscribe, join the Discord, share it with your friends and coworkers. leave us a five star review. I have a my boss and like the CEO do this podcast, which I I think they mostly do just to like battle test like our live streaming capabilities and things like that. But it has like 10 listeners and and so I'm constantly mocking them. I'm

Nathan Toups (00:48)

Are you shaming are you shaming your boss right now?

Carter (00:51)

straight up shaming them because I'm a little salty that they don't ask me to join them.

'Cause I am the only experienced podcaster at Leland. Anyhow, all I'm saying is that I I frequently look at the amount of reviews our podcast has on Spotify and theirs and one, we're crushing them. but if you could just keep giving us five star reviews, this will continue to boost my ego. So please leave a five star review if you haven't. wait yeah.

Nathan Toups (01:13)

If you wanna damage if

you wanna damage Carter Zego, get a four star review and some salty feedback.

Carter (01:18)

Dang it.

We did get a we did get a review for the mobile app. Cause I I've been really developing the mobile app at work. And we got a one-star review on it. It was really funny because the review was completely we're a marketplace, and so the review was really complaining about some poor services rendered by the person on the marketplace. And it was and sort of like, I want to start review, that's lame. But then the final sentence of the review was like, however, the mobile app.

Has a very clean UI and is very easy to use. So there's that. I was like, woohoo! That's my domain.

Nathan Toups (01:51)

Yeah. Dang.

Carter (01:54)

anyhow. So leave me, leave me a five-star review on wherever you interact with me, whether it's through here or my work. and we have a fun little thing. I don't know if you guys have heard of the game Vim Adventures. It's online at let me make sure I get it. It's just Vim dash adventures.com.

but it's a really fun kind of like overhead game. Think about like like old school Legend of Zelda. But I had floated on the podcast a couple weeks ago when we read Pragmatic Programmer that I wanted to get better at Vim and that I wanted to get better at using my keyboard without using my mouse or my trackpad. anyhow, found my way to Vim Adventures, really enjoyed it. and actually got in contact with the developer of the game and said, like, hey, we we love this and we're hoping we could share it with our audience. And so

he gave Nathan and I some free licenses and he also gave us some free licenses for the audience. So if you are interested and want to get better at your Vim skills and play what's really a very charming, fun game, just share the book overflow on social media. You can be on Twitter, I guess you could do on Facebook, but I don't know, people really do that. LinkedIn is probably your your best avenue here. tag us, tag Nathan or I or or the podcast itself. and you can also send a copy of the

of

the link to the post at contact at bookoverflow.io. Anyhow, if you do that, we're gonna be selecting a few listeners to receive those free licenses. So yeah, if you wanna get better at BIM, this has been I've been having a lot of fun with it.

Nathan Toups (03:25)

I I love that you're like leveling up your command line skills. I think I played this game years ago. If it's the one I'm thinking about, I played this game years ago and it was really helpful. just mostly because you can get comfortable with a subset of command, I should say you. I got comfortable with a subset of commands

Carter (03:39)

Right.

Nathan Toups (03:42)

and I was like, I really should really understand how to get around this. I think especially if you're using Cloud Code in the terminal and you're using more of the, you

Carter (03:48)

Right.

Nathan Toups (03:49)

know, TMUX and some more advanced setups, you know, getting comfortable with NeoVim and Vim.

In general, I think the you know, the primogen will get happy as well because

Carter (03:59)

Yeah.

Nathan Toups (03:59)

he's he's like a maximist for this and I I I think it's just good. Yeah, good in general.

Carter (04:04)

Yeah, I that was really what pushed me over the edge was was doing a lot more work in the terminal these days with cloud code. Cause I just it's just annoying anytime I have to actually open up VS Code and and start looking at that. I use the other one I use a lot is I I don't even know how you pronounce it. Git2E, git UI, G-I-T-UI. It's just this nice little command line tool that it just gives a a very easy representation of like

your staged files, what's changed in each of them. And so as the agent

Nathan Toups (04:34)

Yeah.

Carter (04:35)

is working, I I usually see what's coming online there and I'm inspecting the code. so that and then combined with my new novice Vim skills is I'm

Nathan Toups (04:45)

That's awesome.

I I think that's so cool. And next thing you know, you're gonna start having a public dot files folder that you used to sync around places and

Carter (04:52)

Yeah, yeah.

Nathan Toups (04:54)

I've I've been toing all this plus you know, because I do client work, I I have it's really important to have sandboxes that are separate from one another.

Carter (05:03)

Right, right.

Nathan Toups (05:03)

And so then you get into this whole thing, you're like, okay, well, I now I need reproducible environments. I'm gonna be able to hop from one to the other and have it be familiar. And so you start you'll start going down this rabbit hole and

I will take like a quick shout out. This is not paid. exec.dev, who which is created by the one of the founders of Tailscale, is a really nice virtual machine sort of SSH virtual machine as a service that's really good for agentic workloads. And so I've been increasingly moving my stuff. I have I have a Proxmox server at the house, and then I also have Exec.dev. And I've been kind of like hopping between, but

All of a sudden I have to do this meta thing where I'm like, okay, bootstrapping an environment. I've been using a a new tool as well called Agent Works, which kind of like helps you do this faster. we'll put links to all that stuff. I maybe we should do a special episode periodically on like what's our exist what's our current setup? That

Carter (05:59)

Yeah, right.

Nathan Toups (06:00)

would be kind of fun. Like what are what's my daily driver tools that I'm using?

Carter (06:04)

Mine will be a little boring, but

yours will be much more

Nathan Toups (06:07)

Hey, boring's great. I

I think it's I think the listeners too, you know, I've gotten feedback and stuff that I'll be surprised by, I had some conventional background and it's cool to hear this, or

Carter (06:18)

Right, right.

Nathan Toups (06:19)

I heard you use this tool and that's really neat. I love that tool as well. And I think it's just it can be kind of lonely sometimes because you'll see these power users where I'm like, I'm not that cool. Like I'm not doing all that the craziest you know.

workflow stuff. I have appreciation for that, but I actually like to keep my tool set boring. But boring is still a relative thing, right?

Carter (06:40)

I I did get sold on by a coworker. I I've for years I've been like a just like an whatever the default Apple keyboard is. I'm like, who needs like a fancy mechanical keyboard? And then I got sold on like it's like a new fee

Nathan Toups (06:55)

Yeah.

Carter (06:56)

which mechanical keyboard. And I was like, I'll just get one for the office. And I wound up loving it so much I actually bought one for home too. No.

Nathan Toups (07:01)

I'm if you're on the Discord, you know this

already, but I'm on a code V3B, which is no longer I think it's no longer made, but it's just it's kind of got that old IBM mechanical keyboard look to it, but it's got backlit stuff. And it also has

Carter (07:15)

Nice.

Nathan Toups (07:16)

some dip switches that does Apple hotkey mapping. So, you know, yeah. I like it. I've I've had it forever. Yeah,

Carter (07:21)

That's cool. Mine has a knob to control the volume, which

Nathan Toups (07:26)

I I actually there was a time I think it was

I can't remember, there's a company out of Austin. This is gonna drive me nuts now. Company out of Austin that had some pretty awesome mechanical keyboards and then it broke eventually. and when I replaced it, I replaced it with this, and I've I've had this for probably ten years at this point, maybe

Carter (07:44)

wow.

Nathan Toups (07:45)

more. So it's it's it's made all the moves with me. It's it's been to Costa Rica twice.

Carter (07:50)

There

you go. All right. Well, this is a book podcast, not a keyboard podcast. As much as we might transition it to be a keyboard podcast for an episode in the future. Keyboard

Nathan Toups (07:59)

We're gonna start a keyboard overflow. The

Carter (08:02)

overall. We every week we buy a new keyboard. This is just

Nathan Toups (08:05)

Yeah.

Carter (08:06)

a yeah. okay. this is revisiting team topologies. Manuel Pais and Matthew Skeleton have come out with a second edition.

We'll give you the quick author introduction and book introduction. Matthew Skelton is a co-author of Team Topologies, organizing business and technology teams for fast flow, head of consulting at Conflux. He specializes in continuous delivery, operability, and organization dynamics for software manufacturing, e-commerce, and online services, including cloud, IoT, and embedded software. Manuel Pais is the co-author, recognized by Tech Beacon as a DevOps thought leader. Manuel is an independent IT organizational consultant and trainer.

Focus on team interactions, delivery practices, and accelerating flow. Manuel is also a LinkedIn instructor on continuous delivery for the enterprise. And the second edition of Team Topologies reemphasizes its core message: clearly articulated intent and purpose are fundamental for achieving agility and speed within organizations. Five years since its initial publication, the principles have proven effective across diverse sectors beyond original expectations, including pharmaceuticals, law, HR, and healthcare.

key

themes in this updated perspective include the critical role of cognitive load as a design principle, the shift from viewing organizations as efficient machines to flourishing ecosystems, the prioritize fast flow and empowerment, and the increasing applicability of team topologies principles to whole organization transformation, including multi-company portfolios and nation states. dang. One of the big changes here is clarifying the concept of a platform team as a platform grouping.

And the approach is presented as an ever-evolving process, not a static implementation, with strong emphasis to continuous learning and adaptation, particularly in the face of emerging technologies like AI. So we did not reread the entire book. There's like a new foreword, a new afterward, some case studies, and then just like some various corrections throughout the book. So that's about what we read. Nathan, give me your thoughts on this revisiting team topologies here.

Nathan Toups (10:07)

Yeah, and so you know, quick quick context for the listeners. We few I guess beginning of last year, we covered this book. There's two episodes dedicated to it. Plus, we actually interviewed Manuel País as well, who was an awesome, awesome guest and has already said that he'd come back on to talk about second edition. I know we don't know the timing for that, but he's committed to this, so happy to happy to share.

I would say that this book is a it's a modest, like it's a modest revisiting of the first edition. And what and I'm and I mean that in the sense that it was already a good book. I think we we have the critiques that we have, you know, who the exact audience is and things like this. But if you hadn't read the book yet, go ahead and just get the second edition. It just improves, it makes some corrections, it expands upon ideas. And obviously there this is this is kind of a new approach to some old ideas.

That have evolved over the last five years. the case studies are actually like really useful if you're trying to figure out like how do you actually implement this. I will say though, if you've read the first edition and you're like, what am I missing out on? I I guess I'll have two kind of head pieces to this. One is, you know, if you have a a in continued education engineering budget and it's on your plate to like improve flow for your teams, like go ahead and buy the second edition.

There's some really useful stuff in there. If you're paying this out of your own pocket and you've already read the first edition, you probably could read some blog posts or watch some videos online and get most of what you need out of it. You're not missing fundamental core arguments in not getting the second edition. I think maybe that's a little different with like designing data intensive applications, which you know has I I think we're going to tackle that down the road and it's some major changes. but yeah, I I

It's I I'm glad they they revisited this. It feels like they're probably gonna have a cadence to this. I have I would be s shocked if there's not a third edition that comes out in another couple years.

just

Carter (12:12)

Right.

Nathan Toups (12:12)

because AI and the expectations of teams is changing so quickly. but yeah, that's that's a lot more general thoughts than I thought I was gonna share initially.

Carter (12:22)

Yeah, it's good. The book updates just a little, kind of touches on AI, a little bit, which is always nice. I think I I I agree with you. It's like if you haven't read the first edition, then great, pick up the second edition. there's this is a modest improvement over the original. but I think it is interesting. I think the idea I found most interesting out of

they're they're what they cover is this idea of like platform teams and and changing them to platform groupings. Nathan, you have traditionally in your previous work done like a lot of platform teamwork, right?

Nathan Toups (13:03)

Yeah. And I will say I I do feel, I mean, I know that they didn't listen to me in our last episode, or at least I should say they'd already finished the second edition, I think, by the time we had covered the first edition. but I felt I I was looking back at our transcripts from our previous episodes and I was like, you know, I make I in smaller teams and earlier stage startups, platform and enablement kind of get overlapped.

Like a good bit. Like we kind of have to be pretty hands-on to doing and again, we can get into some of that terminology and definitions, but a platform team is separate from an enablement team. And this new framing that they have kind of says, hey, there's this sort of fractal pattern where you're going to you'll have this platform groupings, which is like enabling self-service and reducing cognitive load. It's like the whole point of a platform team.

But enablement is really about how hands-on you get to make sure that people are successful, right? And you may have heard this sort of buzzword around forward deployed engineers. A forward deployed engineer is straight up an enablement engineer, right? Like that is what

Carter (14:10)

Right, right.

Nathan Toups (14:11)

your focus is. If you, if you work with customers, it's external facing a forward deploy engineer is making sure that the the product's actually working the way it's supposed to, that they understand the features, that you can give feedback so that you can develop and

make fixes. that is different than platform, but I would say like there's sort of these overlaps depending on the context. And I think this book, this update has kind of like framed that a little bit better. It was a little confusing before. And I think it was really only talking to like large organizations where you really have a discrete platform and you have a discrete sort of enablement. And they don't, you know, they don't they're not really the same. So I I will say like I I s

Yes, I this speaks to me a lot. Of course, I'm also back into consulting. So this really speaks to me a lot. it's a really good framework for like how I'm gonna communicate. I identify a dysfunction. I think that we could do things better. I'm curious about your opinion. Now that you're you know now that you've been in this startup for a while, some of this might feel like a lot of formality to you. Like I I would be curious if like your thoughts on how much do you think this applies to you at at this stage?

Carter (15:21)

Well, I I think the problem is is that not a ton applies to me right now. And and we're just we're a small company. our dev team's only like ten engineers. And so they're just like

Like I'm not I'm not disputing any of the value that this book has. And we think about we we try to think about stuff kind of increasingly like from a platform perspective. Like we're trying to get some kind of universal search set up for the site. And instead of tasking like one team with like you are in charge of universal search, we're we're trying to think of it more like, okay, develop like universal search as a product for your domain and then make it easy for the other, you know.

Kind of because we divide the team into pods, right? For the other pods to onboard their domain into this kind of universal search framework you've set up. but I I want to I actually want to take this moment. I want to talk about forward deployed engineers because that's a really hot topic. And I I

Nathan Toups (16:20)

yeah.

Carter (16:20)

feel like we haven't talked about that on this podcast.

Nathan Toups (16:22)

No.

Carter (16:23)

I think this is a bad job. I think that this is like when or not, not necessarily like a bad job, but like people are trying to sell like forward deployed engineers as like this sexy thing. Like, you're the forward deployed engineer. And I'm like,

This is like you're not actually working on the main product itself. Like you are to a degree, but like you're I feel like we had a word for this back in the day that was not nearly as sexy as Forward Deployed Engineer.

I don't even remember what it is though.

Nathan Toups (16:50)

Are

you talking about like a like a s maybe like a customer success kind of mm hmm.

Carter (16:56)

Yeah, basically, right? Like

and so I I feel like people are like really hyping up like forward deployed engineers. And it's not that look, this kind of reminds me about like when some people they don't like the word like it's what do they call it? The I think even Mate to stick talks about this idea of like the euphemism treadmill. It's like we don't like the word bum, so we come up with the word hobo, because there there's a stigma attached with being a bum. So so now you're a hobo.

But now there's a stigma with being a hobo. So now you're homeless. Well now there's a stigma with homeless, so you're unhoused. And it's just like, but but none of the reason that we keep the stigma keeps keeping up with the euphemism is because the underlying thing is just stigmatized. And like you can argue and say, well, we shouldn't stigmatize it,

Nathan Toups (17:43)

So

Carter (17:43)

but but changing the name doesn't ch doesn't fix that, right?

Nathan Toups (17:47)

I I can see that criticism. So I and maybe we should detangle this a bit. I think that one of the problems is forward deployed engineer has become like the new hotness. And I and I'll say this as somebody who I was in DevOps. well, first I was a Sysaman, then I was in DevOps, and then I've had a focus in SRE, and then everything started calling it platform engineering, and there's overlaps and some companies.

really abuse those titles. They really are different jobs. You could make these arguments for it. But I will tell you that very few companies hire DevOps engineers anymore. Right. You're either an SRE or platform engineer. And even if you're a platform engineer, a lot of times your expectations is really that you're doing DevOps or SRE. It's super confusing. And I've even done this in the interview process where I'm like, okay, what do you actually mean? Right? The history, do you are you familiar with the history of forward deployed engineer or like where that came from? Okay,

Carter (18:40)

I am not.

Nathan Toups (18:42)

so I good, I can give you a little context.

there's a company that is very controversial named Palantir. And

Carter (18:50)

Yes, I do know them.

Nathan Toups (18:51)

Palantir created the term forward deployed engineer, as far as I'm aware. At least they popularized it if they didn't create it themselves. And the idea from them it was they had all these advanced technologies and they needed to do a bunch of custom implementation to make things work for a client, for a customer. And so therefore, this forward deployed engineer was really a software engineer.

Who was doing, you know, sort of bespoke implementations, really getting feedback. They were kind of building custom versions of the product for the customers. And I think in the sense of Palantir, it makes a lot of sense, right? Like they are building really complex, hard to understand to the general public, especially years ago when their AI tools, you know, that they were using, which were really sort of like machine learning, I guess is what we would call this now. they were so

secretive and so out there that it was even hard to communicate like what these capabilities were.

there you go. I muted myself for a second. there How far back okay, yeah, I don't I don't even know. Okay. Okay.

Carter (19:57)

Marshmallow you wanna pick back up? Th you you're only muted for like ten seconds. You you were talking about Palantir, four deployed engineers

Nathan Toups (20:07)

Okay. I'll take yeah, well marshmallow.

So the it Palantir sort of had this, you know, special role of this forward deployed engineer because their comp their software was so complex, right? And so it I think it makes a lot of sense there. It also had a lot of esteem to it because you had to be an incredible software engineer and a good communicator. You had to be able to handle FaceTime with the customer. and so it kind of became this sort of like in their company, sort of like a rock star type position.

But I think basically we've done is we've taken this and done the cargo culting thing and said, hey, if I create forward deployed engineers, I will be as successful as Palantir, right? That and really what we're talking about

Carter (20:54)

Yeah.

Nathan Toups (20:55)

is a customer success person who now is being called a forward deployed engineer because they've got, you know, Claude to help them whip up some code real quick.

Carter (21:02)

Right, right.

Nathan Toups (21:04)

So I do think that like

It's it I it I think it's interesting that I I think there is a role there. And I've I understand this as a consultant. Consultants are kind of like forward deployed engineers, right? Like I I'm doing thing especially if I'm doing contractor work, because a lot of my consulting isn't just making slide decks. That's not really what I do. I'm I'm actually an embedded IC a lot of times with sort of a staff plus perspective on things, right? Like that's sort of the role I take on.

Carter (21:35)

Right, right.

Nathan Toups (21:36)

So I'm still writing a lot of code.

But the way I do it, I have to make sure that I'm doing custom work that makes sense to the to the client, which in this case is one of my customers. And so I I think you know, product engineers, solutions or sales engineers, consultants, they all kind of like share some of the DNA with what a forward deployed engineer is. But unless your product is like truly bespoke and complex, it probably is an overloaded term, if that makes sense.

Carter (22:08)

Right.

And I think I don't know, maybe something that gets to me about forward deployed engineers is

Nathan Toups (22:12)

Yeah.

Carter (22:13)

I don't know. I I think one thing I really like about software is the kind of infinite scalability of it. It's that's actually something that AI is making really interesting. Is traditionally software has had very high fixed cost and very low marginal cost. And not only does AI reduce those high fixed costs up front, but

Companies that are very AI, like they're selling like AI products, actually do have marginal costs on the software they deliver because of you know, because of the tokens that they have to spend. so that it's interesting. That's a bit of a tangent, how how the whole business model is changing. But I really like this idea that like you can build a product, a small team can build a product, and then that product can be consumed by.

Tens of thousands or hundreds of thousands of people. And for deployed engineers, just by like necessity, don't do that. Like I get that they kind of do that. They're working with a specific customer and then they come back and then they, and then based on the feedback from that customer, you know, you might make improvements to the product, which will then benefit all the other customers. So I get that in isolation. and I and I'm not discounting the importance of talking with customers. Like, obviously, you have to talk with customers.

But I also really admire in like product development, like good strong vision for what a product should be. Like one of my favorite products in the world is Linear. Do you do you use linear?

Nathan Toups (23:50)

You know, I've never used it in I've I've dabbled with it, but I've never used it on a team, actually.

Carter (23:55)

Yeah,

we so we use it. and and I actually I love Linear. because I always say like every developer wants to make a project management software. That's all they want to do, right? Because like they have a very clear idea of like what good looks like, or it's just like it's like a toy project. but then you look at something like Jira, and Linear is basically a complete reaction to Jira, like in a good way. Basically, like saying, like, this is a huge convoluted mess. and Linear got on my radar because Jerger Oraz does like a roundup every year.

like he sends a survey out to like his readers and asks them, like, hey, what kind of tools you're working with? And Linear was the first project management software that ever appeared on the list of like, we are enjoying these tools. and so if you use Linear, you can tell that it it's a huge exercise, not in what can we add, but what can we restrain? Like what what do we take away to to have a good product experience? and there's just so much care.

And craft put into it. which I think is really, really cool. And I don't think you would get to make those kind of same judgment calls as a forward deployed engineer. And and for me, and this, you know, maybe I'm wrong here, right? I have always viewed that kind of what what I'm describing earlier, like linear, like owning the product, having the product vision, thinking holistically about a system as kind of the more prestigious,

role in software engineering as opposed to like the I'm working with one specific customer just trying to solve these specific problems. so so yeah

Nathan Toups (25:29)

Yeah, I I I

Carter (25:30)

it

Nathan Toups (25:32)

that makes sense. And and I do think I think the crutch is if you're really using forward deployed engineer as a sort of a wrapper around becoming a services business, I think that is the wrong use

Carter (25:41)

Right, right.

Nathan Toups (25:42)

of it. If you really do have a product, and and by product I mean you have a core engineering team, they build a product, they really are focused on the product and they're not doing they're not focused at all on sort of bespoke implementations. But the product that you're building itself is this sort of like

Composable platform software as a service thing. I think that forward deployed engineers really makes sense if the world hasn't quite wrapped its head or you haven't even figured out how to make this into like a zero touch product. You know, I and so I do think, you know, there the the companies that I know that do use forward deployed engineers, Enthropic, OpenAI, perfect examples, right?

They definitely want to get their foot in the door in the enterprise. They want Fortune 500 companies to use their tools. They absolutely have forward-deployed engineers that are working embedded with those teams to make sure that they're using the tools in a way that they're maximizing you know the enterprise features that are coming out of that.

Carter (26:45)

Right, right.

Nathan Toups (26:46)

Cause some of that's hidden hidden knowledge, some of that's that, they never thought about the things that this fortune

10 company is running into from a compliance and governance standpoint. And so therefore the forward deployed engineer needs to go back and like talk to the internal teams and help, you know, you know, find the right pattern for it. But if you're not that type of product, and you're not building a product that's for other software engineers, basically, I do think that it's overused, right?

Carter (27:17)

Right.

Yeah, I I like the way you phrased it. Like, are you are you a services business masquerading as a a tech company? and I guess if if I were considering a forward deployed engineer role, that's what I would want to suss out. Right. Like

Nathan Toups (27:34)

Yeah.

Carter (27:35)

'cause I I it's just one of those things like, I don't know, sometimes maybe I'm some some maybe I'm a little too reactionary sometimes, or like there'll there'll be a new hotness floating around. I'm like forward deployed engineer, like

I don't w what is this? But may may I get maybe I gotta get it with the get with the times, Nathan.

Nathan Toups (27:50)

Right.

No, no, no. I think this is a good point there. Like I'm trying to think of like a you know, I could imagine a world in which let's say your company's built some cool Kubernetes data mesh service discovery

Carter (28:03)

Right.

Nathan Toups (28:04)

thing. It's pretty hard to wrap your head around. And you could imagine a case in which the customer's big enough that you'd apply a forward deployed engineer, which is somebody who really has to understand the inner workings of the system.

But it's also sort of like got that customer success side. That's that's the type of role where you're like, there is a type of person who I think would actually thrive in that environment where they they want the varied work of I'm gonna sit with this embedded with this customer for a while, but I I also keep one foot in the like I know everything deeply about how this product functions, and that's a kind of like fun problem to solve, like a more implementations side. But that again, if we get back to this team topologies.

That's what an enablement team is all about, right? They kind of have to understand

Carter (28:51)

Right, right.

Nathan Toups (28:52)

a deeply complex problem. And then they're reducing cognitive load. I think the book actually kind of doubles down on cognitive load here. And and I would say, I'll even say to you, Carter, even if a lot of these sort of like more formal pieces do not apply, I think that there are some like there's some foundational pieces that are even applicable to a startup, which are where's the friction?

Right.

Carter (29:17)

Right, right.

Nathan Toups (29:19)

If we have a new X as a service, right? we have this new auth service or we have this new, you know, global search or whatever. Are you building it in a way that I don't really have to understand the inner workings of it? All I have to do is understand the API day to day, and therefore I can get my job done. So it's like the very sort of like clear product that's built internally. I think you can still directionally kind of take these, you know, you know, are we thrashing here because of the Conway's law?

Or do we have a stream aligned team? Like if do we have a clear path

Carter (29:49)

Right, right.

Nathan Toups (29:51)

of ownership for the search product that we have or whatever? You know, or do every time I make a change to the chat tool, do I have to think, man, how is this going to impact the search tool? Oops, you know, like and all of a sudden, like I'm having to keep this is my problem with AI stuff. And I wish they had talked about this more in here,

Carter (30:08)

Right.

Nathan Toups (30:09)

which is I'm we and the AI tools are having to take an incredible amount of cognitive load.

on our shoulders,

Carter (30:17)

Yes.

Nathan Toups (30:18)

right? I have to keep track of the context windows. I have to keep track of the like what I should or should not share. I'm being asked to make impacts on the system that are ended up touching five things if I'm not careful. Where before the AI tools, I would have said, hey, let's come up with a strategy for doing this. We'll break it up into these parts. I'm gonna make sure that I'm only, you know, impacting the piece of the system this so that it doesn't do the other things. And I think

the willingness to take on larger chunks of work that are higher risk has increased because the AI tools will like just do it, you know, if you ask it to. And I

Carter (30:54)

Right.

Nathan Toups (30:54)

think this book brings up a really good point, which is that agents also follow our Conway's Law

Carter (31:01)

Right.

Nathan Toups (31:02)

patterns, right? We still need to build we we like if if we're using a bunch of agentic stuff and we're touching a bunch of parts of the code all in one fail swoop and we're, you know, having to keep a huge amount of cognitive load, that's the part

I don't I don't know about everybody else, but like that drains me. You know, like I I'm like,

Carter (31:17)

yeah.

Nathan Toups (31:19)

man, like I have to touch Terraform and this and three repos, and then I'm doing

Carter (31:23)

Yeah. Yeah. Right.

Nathan Toups (31:25)

that. I'm having to like usher it through. I hate that. Like I really do. I'm I I so then I'm like, okay, well, how can I reduce the friction? Is there a way

Carter (31:33)

Right.

Nathan Toups (31:33)

that I could deploy this part of the system and not have to touch or think about the other three parts? Right.

Carter (31:38)

I think that's what's so interesting about AI agents is previously, if you had to like make a change, and then that change, which you think should only touch like three files, actually involves you need to touch like 40 files. You as a developer would be like, hold up, stop. We've got to fix this before we even do any of this. I'm just gonna fix this. But the agents can just brute force their way through it. That you, if you get lazy, can

Just kind of give yourself permission to not fix anything. And I I've been I've been thinking a lot about this idea of like code cleanliness. And in the past, I've been a big fan of like good, clean, readable code because it makes it easier for humans to work with. If you can just kind of dive into a file, understand what's going on, and then contribute to it easily, you move faster, you ship value faster, right? Agents are better.

At working in messier code bases, at least these days, I I'm at least I'm finding. And so when I go, well, we we just have this, we have this project, or anyhow, the details are important. But anyhow, there's this key part of this project, and I go in and I start looking at the code that the agent wrote, and I was just like, this doesn't like this is messy. I can see that this is messy, and it clearly wasn't a problem for the agent to generate this messy code, because like it did.

And it could iterate on it, but the more I was looking like the reason this code is messy is because the idea we are trying to like express here is itself messy. Like I basically wanted this process to have three stages to it, and for each stage to have very clear responsibilities. And it it had three stages, what the agent wrote, but this responsibilities were intermingled throughout the three stages, which made it hard

Nathan Toups (33:29)

Hm. Right.

Carter (33:31)

to change any one of the stages.

And so I I took the time like, okay, like let's let's just rework this and make it a little cleaner because this is something we're gonna need to iterate on repeatedly. and I I'm I'm just I think obviously that's always been a value of like clean code, like clean code that's easy to understand is usually easy to understand because it's expressing the ideas it wants to express clearly. if you don't even know what ideas your software is trying to express, then how on earth could you write good clean code?

But I I think, yeah, in an AI age like that clarity of expression I think is more important than maybe just ease of use, which I think is what we've traditionally emphasized.

Nathan Toups (34:17)

Yeah. I the the that clarity of thought, clarity of expression I think is is a big deal and I actually Mitchell Hashimoto, which I keep bringing up 'cause I'm a fanboy.

Carter (34:26)

I love Mitchell Hashimoto.

Nathan Toups (34:28)

So he recently had this have did you hear about his his this post recently that was talking about the whiteboard test?

Carter (34:34)

Yes, yes, I actually really liked that.

Nathan Toups (34:36)

Yeah. So I I'm I this is a standard I hold myself to, which is did I vibe code this or not? and this is actually coming up with one of the one of my my biggest clients right now is that we had a very large and very complex code base. We've been simplifying it. There's like me and a couple other engineers have kind of gone through and taken all the good ideas, but really each of us is understanding and taking code ownership of certain parts of it. And in some cases we're doing like 10x line 10x

reduction in lines of code. so not only are we solving the problem more efficiently and it uses less resources, but we can actually reason about the code base better. And we've kind of come to this conclusion from going a little too AI forward before we were involved to being involved in in having the this idea that like, hey, I should be able to defend the system and understand

Carter (35:30)

Right.

Nathan Toups (35:32)

you know, I I'm

I'm working on this sort of like operator in Kubernetes. And I should be able to understand the state machine. I should be able to understand how a retry logic works. I should be able to defend

Carter (35:42)

Mm-hmm.

Nathan Toups (35:43)

that on a whiteboard, even if I can't tell you every line of code that's there, because I did use augmented tooling, right?

Carter (35:50)

Right, right.

Nathan Toups (35:50)

I should know kind of where it is because we do have some naming structures. I should kind of, you know, I'm I should be responsible for the code quality, making sure that we have good test coverage, but not stupid test coverage. And so

I'm fine with that if like if I'm signing off on this. And I'll tell you that we we're doing stuff where we're not necessarily getting code review from others on everything. We we do have a path where

Carter (36:14)

Right.

Nathan Toups (36:14)

we do code reviews where it impacts other pieces or it's critical paths. But I'm ha I'm perfectly comfortable with like owning the reliability of the system, doing the testing end to end with agents and myself, defending this piece and then having a very clear audit log.

Right. All of this stuff's committed.

Carter (36:31)

Right, right.

Nathan Toups (36:32)

We have really good CI C D. we are changing that pattern a bit, but it I it it's really just like with our conversation we had with Carl recently. I think that these tools are increasingly taking tasks off our plate, not job. And the main thing is we have to be able to reason about the system. Like you can't just this this whole like don't look at the code thing, I think is a bit facetious.

But I

Carter (36:58)

Right, I

Nathan Toups (36:58)

will say that if you tell me, hey, I finished this thing and I'm like, cool, that's really awesome. Tell me how the billing service interacts with our portal. And then if you're like, let me go ask Claude, I'm not sure. That fails, right? Like

Carter (37:14)

Right, right.

Nathan Toups (37:14)

and this is I've done this too. I'm not like pointing fingers. This is where one of the things are I'm like, I'm uncomfortable.

completely outsourcing it to the point where I'm like, I I said I shipped this thing, but I don't actually understand how it functions. I think that's super dangerous.

Carter (37:27)

Yeah.

Nathan Toups (37:27)

I think that's really and it's okay for us to take a step back and go, you know what? Let me really understand a reason about the system. Somebody's gonna ask me about it because I'm the one who touched the code. And I can tell you, hey, look, I just this just came up yesterday. They were like, hey, what's the what's the max retries that we have on this thing? And I go, there's there's three of them and this is what the timeout window looks like and the other other parts.

And I was like, you know, there's some edge cases that I'm not 100% sure about. Let me go back and look. Right. And I go look at the code and I go, okay, cool. This is how we handle it. I might have even used Claude to help me, you know, remind

Carter (38:01)

Right, right.

Nathan Toups (38:02)

me because there's maybe some environment variables that we said and whatever. That I think is a very healthy thing in the same way that if you worked on something with a team member and you're like, hey, I don't

Carter (38:12)

Yes.

Nathan Toups (38:13)

what did we do with the caching layer? I mean, I know that we influenced it this way. I know we had this whole conversation, but like, what did we settle on? Or what's the staging environment doing? And why is it different than prod?

Those are part of the job. But if you're like, do we even use a caching layer, like you should you you should not be tearing headlights on that.

Carter (38:26)

Yeah, right.

Well, and I'll point out this is not even that different from how things have worked for eternity, right? Which is this I like talk to any developer who, you know, in in the olden days who hand-coded 10,000 lines in a project and then talk to them three years later, right? Even a year later, six months later, right? And like about specific functions. They're not gonna remember specific functions, right? What they're gonna remember is the whiteboard test.

and yeah, I I'm just thinking I I I think more and more about this idea of like, are we getting the abstraction right? like SQL SQL is so impressive. SQL is created like 50 years ago and hasn't changed a ton since it was created because it kind of just nailed the abstraction of working with a relational database, right? I I you know, there there are things that drive me a little nuts about SQL, but for the most part it it really works.

We are looking at redesigning kind of like our payment system. And so one thing I've been really holding the team's feet to the fire on is like, okay, let's talk about all the things that are currently really annoying to do in the current system. And then let's run through how they would work in the new system. Because if they're still annoying to do, then that to me shows that we haven't gotten the abstraction right. And so much just kind of falls into place naturally if you have an understanding of.

what you're building and are modeling the software to represent that appropriately. I mean I I

Nathan Toups (40:00)

Right.

Carter (40:01)

I I wish I had it up, but Grady Booch has he had a great I Grady Booch, I I I see him on Twitter a lot. I know he's like famous, but I forget what he's famous for. Do you remember what Grady Booch is famous for? It's like he's like an old school programmer.

Nathan Toups (40:21)

you're putting me on the spot.

Carter (40:23)

I know, right.

Yeah, anyhow. I'm trying to see like his replies. He he replied to

Nathan Toups (40:31)

he's the

u he's the UML guy. Unified modeling language. Hm.

Carter (40:34)

Yes, yes. He he invented

UML. and he is really active on Twitter because I'm just trying to see him reply.

Nathan Toups (40:41)

Is he?

Carter (40:42)

yes, yes. he and George always didn't read him a few times. Yeah.

Nathan Toups (40:44)

I'm not, so if you're active on Twitter, I you could might you

might as well be on a desert island.

Carter (40:51)

Anyhow, so he he said, he said, In my career, compilers have always generated better code than I ever could have. I find this to be increasingly so with contemporary AIs. But you know what neither can do better than me? Knowing what software to write, what shape it should take, and what I want it to do. The entire history of software engineering has been one of rising levels of abstraction. This is how it is, how it was, and how it shall be in the fullness of time. yeah, and and I I that gets back to this idea of like the whiteboard test. It gets back to this idea of.

even like team topologies, right? It's like you can't know how to align your teams and how to, you know, structure your organization unless you have an understanding of the the problem. And and you can kind of model effectively the the team if you can model the effectively the problem effectively in your head, then you can sort of start to decompose it and figure out like, okay, here's where, like you said, we're thrashing, here's where the friction is appearing.

And

you know, I just I I tell this to to my team all the time. I tell to like interns, it's like there's just no substitute for understanding a system deeply. and I think that's when I start to get nervous with AI is when people seem like glib, like it's that whole you ever watch the big short.

Nathan Toups (42:08)

Yeah, great great movie.

Carter (42:08)

Yeah, yeah,

a great movie. But I but I love when he goes. It's it's it's like a meme now. But he's he goes to like they talk to like the mortgage brokers and they're just like talking about how they're like giving mortgages to people with like no credit scores and like immigrant like illegal immigrants and things like that, right? Just like people who have who have no business owning a home and with if they have no income. And then like the Steve Crowell character like, I don't get it. Why are they confessing? And his assistant's they're not confessing, they're bragging. And like that's how I feel like with a lot of AI. It's like

Nathan Toups (42:38)

Yeah.

Carter (42:38)

I ship this

giant system and I don't even know how it works. I'm just like, that's what are we doing

Nathan Toups (42:43)

I know it's

Carter (42:44)

here?

Nathan Toups (42:44)

it's crazy to me too of like the people that that are just basically making a demo app and being like, Look how amazing this tool is. And I'm like, I mean, it is impressive that you made some like 3D looking

Carter (42:56)

Yeah.

Nathan Toups (42:56)

game that looks halfway playable for like two seconds. but if that's what you think software engineering is, we have a much deeper conversation to be had.

Carter (43:05)

Right, right. Yeah.

Nathan Toups (43:09)

And so yeah, it's

It it is interesting. I mean, again, if you don't want to think about the if you're working a j if you have a job in an industry like software engineering and you find yourself repeatedly just not wanting to do your job, you want the AI tool to do it for you, and you're literally

Carter (43:24)

Yeah.

Nathan Toups (43:26)

like pressing pressing enter for a living, that's

Carter (43:28)

Right, right.

Nathan Toups (43:30)

terrible. That job is going to go away, right? Like if your job

Carter (43:32)

Right, right.

Nathan Toups (43:33)

is to press enter, you're you're done. You're cooked.

Carter (43:36)

Right.

Nathan Toups (43:38)

you know, I I

I was actually just having this conversation with my my wife this morning because I I can't remember. It was on one of the other podcasts that I it's kind of up coming that I've been enjoying. It I think it was maybe the creator of Scala or is one of the creators of one of the programming languages. And his argument was basically that we might be going back to both both ends of this spectrum of like what's gonna happen to the future of software engineering jobs might be correct in that

A lot of low value software engineering jobs might actually go away. The ones that basically were doing a lot of plumbing work and

Carter (44:15)

Right, right.

Nathan Toups (44:17)

were kind of taking orders, right?

Carter (44:19)

Right.

Nathan Toups (44:20)

And that we might go back to what software engineering was in a way, which is that these kind of like slightly obsessed, very unique, deep expertise folks, and this sort of like product-oriented folks, and sort of like these sort of, you know, exceptional specialization type people.

Have unlimited work out of them. You know, I I do think that maybe,

Carter (44:42)

Right.

Nathan Toups (44:43)

software engineering isn't such an obvious career path for everyone, but that for those who find the right place for themselves, it's still gonna be a very viable and incredibly in demand role, but it's gonna be different. And the reason I'm bringing this up is that I have a friend who's was a software engineer, he's been unemployed for a while, he's really been struggling.

to find a gig and he's very sort of like he he's he's it's it's

Carter (45:11)

I told you to keep that in confidence.

Nathan Toups (45:13)

Duen? yeah. Yeah. Yeah. Yeah. Yeah. So yeah. Yeah. It's not this is not Carter. but or is it? but yeah, this

Carter (45:15)

making fun of you. I it's not I told you to keep that in confidence. Like it's me. I I haven't been employed for the past nine eighteen months. Like

Nathan Toups (45:27)

guy that I know that I'm also doing a podcast with. No, the No,

Carter (45:29)

Yeah.

Nathan Toups (45:31)

but he's he's I I read everything he's saying.

He's worried that he's even gonna have a job in five or ten years. He's worried about not having fun anymore, that he's like the that the expectations of the role of kind of this mid to junior level engineer is not what he signed up for. and that he's even looking at going down other career paths. And I have a lot of I I feel a lot of empathy for that because I do think that's a really real experience. And then I feel also conflicted because I'm having a lot of fun.

Like I really am having

Carter (46:04)

Me too.

Nathan Toups (46:05)

a lot of fun. And I feel like I'm doing high value, high leverage work. And that the people that I'm working with are also trying to figure out how to use these in like new and exciting ways. And yet I also understand the criticism and the critique. Like I have found myself doing some of this stupid stuff. And I'm like, ugh, I don't want to do that. Like, how do I not do the stupid way of using AI?

Carter (46:26)

Right.

Nathan Toups (46:28)

how do I do it in a in a way that I think is useful? and so

I I do I think we're in this weird world in which, you know, it's not an obvious path. It was an obvious path six years ago, right? Just go

Carter (46:41)

Right, right.

Nathan Toups (46:42)

get a C S degree, go get a good internship somewhere, you know, go to some tech meetups and go find a company and kind of get taken out of the wing. And that that path is not there. but y your company's yeah, yeah, go ahead.

Carter (46:54)

When I well,

no, I was gonna say when I lived in Orlando, I was with my my church. I I was the it's called the the our our congregation is called ward. So I was the ward mission leader, which it's basically the missionaries for our church rotate between you you get it you get a set, it's like two missionaries, sometimes two sets for four missionaries, and then they will be assigned to your congregation for like six months or whatever, right? And so they're kind of constantly rotating in and out. And and my job is kind of coordinate with them and

And help them with you know with the people they were teaching. Anyhow, whenever a new missionary would come through, we don't we always we usually had the missionaries over for dinner every week, which is a lot of fun, like great, you know, passionate young folks. and every time they would come, I'd say, you know, I'd ask if they were in school or planning on going to school after their missions, and they almost all of them were. And I'd What are you studying? And and no matter what they said, I would say, Wrong, you're studying computer science. And this was like, you know, 2021 or something, when the market was just red hot. And I was just like, just go.

This is a this is such a a a path to easy money. Like go do that. but I think it's interesting, like when we had Uncle Bob on, and we should mention that at the top of the podcast. But yeah, check out our interviews with Uncle Bob and Carl Brown. What a one one two punch of interviews. but when we had Uncle Bob on, he was very, very bullish on AI. And I I think he even had some takes about like the AI being conscious in a way that I don't necessarily agree with.

But just from someone who's so bullish on AI, I kind of ask him at the I'm like, okay, well, would you still recommend studying computer science? He's like, yeah, easily. he's like, I think understanding how a computer works like is still a really, really valuable skill and will continue to be a really valuable skill. but my I used to just recommend computer science to anyone who was at all ambitious. And now I'm like, I I'm like you, Nathan, where it's it's it's more like you have to love it. And I think if you love it, there's gonna be

a a lucrative in demand job waiting at the end for you. But that this it

Nathan Toups (48:57)

Right. Yeah.

Carter (48:58)

used to be like very much like a a trade, like a vocation. Like I take English, I turn it into code. That's enough to get my six figure job. And that, you know, probably doesn't

Nathan Toups (49:08)

I I think this is gets into the what the Cal Newport stuff that we had discussed before too, which is that, you know, obviously it's not just a follow your passion thing. That's not what we're talking about. It's really,

Carter (49:19)

Right, right.

Nathan Toups (49:19)

are you willing to put in the work to go deep?

Carter (49:22)

Yes, right.

Nathan Toups (49:23)

And, you know, I don't think you had to go deeper than how do I ace the interview

Carter (49:28)

Yeah.

Nathan Toups (49:29)

with computer science before? But now the folks that I see that are thriving have found a domain of problem solving, right? Like you're very

Product oriented. And I think that's really cool, right? You you really have this focus on like sort of business value. How do we make this? How do we make the factory floor build the widgets that we need to build? Right. Like I think that that it's kind of exciting. At least this is my take of your view on things. It's exciting to be like, hey, we have this clear idea of a product. How do we actually build this product? Like, this is a really exciting thing. And there's also a type of engineer that's like,

singularly fixated on embedded rust. And if they're the happiest, if they can find a job to work on embedded Rust projects full time. Like it's not a product-oriented piece. It's literally like a domain of problem solving that that's if they could get up every day working on that, they could even switch companies from time to time, as long as they're being an, you know, an embedded, you know, super efficient embedded engineer. And I think that we need those types of folks, right? We need folks who can

do the amazing work. and probably would be doing some of that even if they couldn't figure out how to make as much money as they're making right now. Right.

Carter (50:44)

Right, right.

Nathan Toups (50:45)

like I I feel like if you had to switch it there's a scenario upon which like you would even be a founder of a company because you love building products, right? I I I I could see that

Carter (50:52)

Right, right. Totally, totally.

Nathan Toups (50:55)

in you. At some point in the future you're like, hey cool, I got enough things. I think there's this problem I want to solve. I'm going go do that.

Carter (51:01)

Right, right.

Nathan Toups (51:03)

and so

Yeah, that's I don't I'm very optimistic about that side. And again, that's not for everyone, right? That's it's I in the same way that like, you know, parents put pressure their kids to become a lawyer or a doctor and they don't want to be. Like I don't

Carter (51:17)

Right, Ray. Right.

Nathan Toups (51:18)

want I don't want a doctor that doesn't want to be a doctor. That sounds terrible. Like that's you know

Carter (51:21)

Yeah.

Nathan Toups (51:23)

I want a doctor who had a stethoscope since they were five years old and knew that that was really what they wanted to do, right? Like that's that's the kind of doctor I want.

Carter (51:32)

Well,

with this podcast, I we we talk about making evergreen content and I and that is important to me. At the same time, I'll do this with my manager often where I I call it reports from the field, like where I just kind of tell him like these are just the things I'm noticing working in the code base. These things I'm noticing working with with these people. I'm like, make of that what you will, but reports from the field, right?

I I hope that this is a valuable service we provide as a podcast because so many people who talk about AI online are like thought leaders or influencers or or like or worse, they explicitly make money by selling you AI stuff. Right.

Nathan Toups (52:17)

Right.

Carter (52:17)

whereas you I think that's something that's fun about the podcast is, you know, this is still essentially just a hobby for you and I. We we make our money through employed as actual.

Real deal software engineers. and so I I hope that getting some perspective from people who are involved in the craft every day, and and I think involved at like a pretty ground level. Like I'm at a startup, you are an independent consultant working mostly with startups. Like we're kind of, I think, on the cutting edge for like AI. We're not like building necessarily like AI products, but we are on like the cutting edge of adoption for AI.

assisted development in building any kind of product. so I you know, I I hope you listeners are are getting something out of that. Just you know, and maybe we'll all be

Nathan Toups (53:05)

So

Carter (53:05)

wrong.

Nathan Toups (53:06)

before we wrap up, I do want to give a quick shout out to the probably the most notable addition to the book, which

Carter (53:14)

Okay.

Nathan Toups (53:14)

are there's a set of so in the first edition, little case studies were kind of peppered throughout the book. And I I'm gonna bring up something that we talked about in the past, which was that you know, you kind of I think properly diagnosed the fact that this was very like consultant heavy, right? And this

Carter (53:31)

Right, right.

Nathan Toups (53:32)

is a problem that we've run into.

with things like the DevOps handbook and in other books where you you get it. You become a category authority, you're gonna go do the circuit speaker circuit. this is a way for you to declare your philosophy so that when you go do consulting, you're like, hey, this this person literally wrote the book on this and you know they're a thought expert. But it's also important to see like how companies actually did things in the in the in the differences. I think the biggest thing that's shifted from for the first edition to the second edition

Is that team topologies is not just about software engineering anymore. And this was the sort of like reframing. And I and I knew some of this was coming up because I watched some of their videos in the last, you know, year. things like Wardly maps are popping up more in this book. I think they mentioned it before, but they're in there more. But these case studies, a set of case studies, and I think it's like 70 pages or 60 pages of additional content at the end of the book. And

These are companies from all over the world and even a government. The the the Gov Tech Singapore case study that's in there, which is surprising to see you know, sort of government agencies. there's even a case study of like, I think it's a VC firm or some sort of investment firm that decided to use Team Topology's methodology to sort of like get rid of middle management and have like more flow and value, you know, sort of streaml value streamlined teams.

One of them I wanted to bring up is like a a a perfect example, one that would probably make a lot of sense to even your company in the next couple years. There's the I think it's Yasser, I think it's how you pronounce it, it's Y A S S I R. They

Carter (55:15)

Mm-hmm. Yeah, yeah.

Nathan Toups (55:17)

they they did a case study on how they scaled from 50 to 400 engineers. And

Carter (55:22)

wow.

Nathan Toups (55:23)

I've been in a startup that's in that. I was I joined it when they were series C funded.

They had been going to this transition hiring very aggressively. I think they were we were at 300 ICs when I joined. And all the stress cracks, because y all of your identity shifts, you know, pre 50 engineers and then 50 to 400 is every everything that you thought was a good pattern, you start questioning what worked really well, you know. when you could still slack the CEO or the CTO, you can't do that anymore at 400. The CTO will never get anything done. and so

You know, I I I think these case studies were good. And I also liked that these case studies have the authors kind of chime in at the end of each one of them. So the case studies, I think most of them are written either by an industry consultant or the company itself. And then the two authors kind of like do little commentary at the end. I thought they were useful. I th just I thought it was like a good it was kind of like okay, you've read all this stuff about how to do this system, you've read little case studies. Here's what's actually companies since the first edition of the book came out.

Here's what companies have actually done with this and I I I think it's a pretty compelling you know addition to the book.

Carter (56:35)

Yeah,

yeah. No, I definitely agree. Well, I think that about wraps us up for revisiting Team Topologies. I'm actually excited for next week because I think this is a revisit for me, but not necessarily for you. This is gonna be The Staff Engineer's Path by Tanya Riley. Which have you read this before? This was

Nathan Toups (56:50)

y I didn't realize you'd read this book already. Cool.

Carter (56:53)

the this was the very first book that this this is a book over lore that has not been shared. Yes, this is the very first tech book I ever read when I kind of had that idea of like, dang, I gotta level up my career.

What should I I should read a lot? And so I read this. And then that's what kind of got me along the path of like I should probably find a partner to read these books with. And then let's just make it a podcast.

Nathan Toups (57:11)

No way,

Carter (57:12)

So this yeah, Tanya Riley is if you are a a book, big book overflow fan, and want to thank the the the the one who started all, Tanya Riley has about as much credit as any author we've ever read. So I'm really excited to revisit this.

Nathan Toups (57:27)

That's so cool.

Carter (57:28)

I I really enjoyed this book.

And yeah, you can always find us on Twitter at Book Overflow Pod. I'm on Twitter at CarterMorgan. Nathan has worked with his consulting agency rojoorarbado.com and our website is bookoverflow.io. Thanks, folks. we will see you next week with the Staff Engineers Path.