The Staff Engineer's Path

Nathan Toups (00:00)

you should aim to be multiples of value more than you're being compensated,

Carter (00:11)

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

Nathan Toups (00:23)

Doing great here, everybody.

Carter (00:25)

Well, as always, like, comment, subscribe, share the podcast with your friends and coworkers. If you share it on LinkedIn and and tag us or email us, we do have some free licenses to the game Vim Adventures, which is if you're trying to get better at your your Vim or Neo Vim abilities. This is a a fun little game. I've been enjoying playing it. And we are excited this week. We're we're doing the staff engineers path. checked a bit about last week. I'll after we kind of do the author introduction and book instruction, I'll share kind of why.

This book's particularly special to the podcast. but this is by Tanya Riley. Tanya Riley for her author introduction. We have Tanya Riley has over twenty years of experience in software engineering, most recently working on architecture and technical strategy as a senior principal engineer at Squarespace. I'm so curious how the business is doing these days with like vibe coding.

Nathan Toups (01:10)

And actually, you know what's funny? I was just looking

Carter (01:12)

Yeah.

Nathan Toups (01:14)

on LinkedIn. I think she's actually a data dog now. So this is out

Carter (01:17)

that's cool.

Nathan Toups (01:17)

outdated, yeah.

Carter (01:20)

Previously, she was a staff engineer at Google, responsible for some of the largest distributed systems on the planet. Tanya writes about technical leadership and software reliability at noidea.dog. She's an organizer and host of the Lead Dev Staff Plus Conference and a frequent conference speaker and keynote. Originally from Ireland, she now lives in Brooklyn with her spouse, kid, and espresso machine. That sounds like you, Nathan, except swap Brooklyn for Costa Rica.

Nathan Toups (01:44)

I f I feel like if our

lives had crossed paths I'd wanna be friends with with Tanya a lot.

Carter (01:49)

Yeah.

book introduction. for years, companies have rewarded their most effective engineers with management positions. But treating management as the default path for an engineer with leadership ability doesn't serve the industry well or the engineer. The staff engineers path allows engineers to contribute at a high level as role models, driving big projects, determining technical strategy, and raising everyone's skills. I'll say I think that's something our industry does really, really well is offering the divergent individual contributor and management.

paths

and people I talk to outside of the industry are frequently surprised that you can get like a you can get manager, director, VP level money without ever managing everyone. I think the the I'm I'm gonna give the industry

Nathan Toups (02:34)

Yeah, I

Carter (02:35)

credit.

Nathan Toups (02:36)

my my brother in law is he's he's a periodonist and he didn't I don't he was he's been doing some like podcast interview type stuff. He did not realize what high income earners software engineers could be who've moved up to these

Carter (02:50)

Right.

Nathan Toups (02:51)

higher places. And like he was like talking to me recently. I was visiting Louisiana.

Carter (02:55)

Thirty two dollars an hour.

Nathan Toups (02:56)

Yeah. And he was just shocked because these guys are all, you know, these guys and gals are they're having to figure out how to like

sock away their money and invest it and do things that, you know, you don't think of as normal folks, but these folks are not normal folks. They are high income earners and have get a lot of the upside of these companies that they help build. And this ties into the staff engineer stuff. I mean this we'll we'll see this, you know, thinking about doing high impact work is, you know, kind of an interesting theme that comes up.

Carter (03:26)

Yeah, well, I'll give my thoughts on the book. I I really love this book. I mentioned it at the end of the last episode before anyone new. This book is kind of the progenitor of the podcast. I had gotten a staff engineer role at like a one of those fang adjacent companies, found out when I joined that like this company suffered from title inflation. So it maps more closely to like a senior engineer role at Google. but anyhow.

But but when I got in the role, I was like, I should read up on like kind of what it means to be a staff engineer. And so I I picked up this book, and then I kind of got very interested in this idea of I I learned so much from this one. I was like, I I feel like I should be reading more technical books. I think that would make me a lot better engineer. And so that's how you and I connected, Nathan, was we were both doing the Georgia Tech masters at the time, and I was like, I should find a buddy to to read these books with. And I was like, if anyone's gonna be a you know a sicko.

And

just want to do a ton of extra reading for nothing. It'll be someone who enrolled in a completely voluntary master's degree. and

Nathan Toups (04:27)

Yeah, that's

Carter (04:28)

yeah, it it's it's been gravy from there on out. So I I really enjoy this book. I think this is I'm I'm kind of surprised by people I talk to in the industry who just don't have an understanding of kind of the larger industry, except for their very small slice of it.

Yeah, I I have a I have a buddy I work with right now who he's kind of only ever done kind of like the the Utah startup thing and he's kind of frequently shocked when I kind of describe more like Silicon Valley stuck type companies and how they function. and I just think this is a great book if you yeah, ever finding yourself curious, like what a staff engineer, what what does that mean? Or or in particular, like I think a lot of people can conceptualize okay, like I'm a junior engineer, I'm a mid level engineer, then like I'm a senior engineer, but I like lead a team. That makes sense.

What does it mean to

Nathan Toups (05:17)

Right.

Carter (05:18)

be an engineer that's not leading a team, but is maybe working across multiple teams, right? That's more at like the director level than maybe necessarily like the manager level. and this is just such a great book to help get your brain churning on that a little bit. What do you think, Nathan?

Nathan Toups (05:34)

Yeah. I was a little I'll be honest, I was a little worried because we read Will Larson's book on staff engineer, and I was like, How much is this going to overlap? Like, how redundant is this? And it really isn't. I'd say these are actually they complement each other quite well. And I was pleasantly surprised. I was like, actually, I'm getting a lot out of this book with a different perspective and focus than I did out of Will Larson's book, which I'm a huge fan of.

And I I was kind of thinking about like why did I like these books for different reasons? And Will Larson, of course, has a an entire book on strategy. And it I think this is the same thing. Will Larson's book is sort of like, What is a staff engineer? And what are sort of like why do companies need them? And like strategically thinking about this role and how you get this role. Where this book is much more tactical, like it

It kind of feels like what we do in this podcast a bit, like it's very conversational, where it's like, hey, you might be

Carter (06:30)

Right.

Nathan Toups (06:31)

in this situation, you should try this, you might be in that situation, you should try this. And so it's very cozy, I guess, and dense with really good insights. Like I I can see why someone picks this book up and goes, Yeah, I got a lot out of it, which I was looking at reviews online and people in the forums. I like to do a little bit of research on that side. And people love this book. And I understand why. Like I if you if you look at why.

I also I'll give a a little piece of feedback. I was at a startup, the first role that I had taken that was a staff role. And I had another guy who's on our team, great guy, used to work at Google and Looker, and he told me about both of these books. He was like, Hey, I highly recommend now that we're in a staff role, what is our expectations have shifted a lot? And he actually said that the Will Larson book he felt was a little intimidating.

is in like he had a lot some impos

Carter (07:25)

really?

Nathan Toups (07:25)

imposter syndrome after reading it. But that the Tanya that the the engineer I mean the staff engineering path is one that he felt was really approachable and that he that he really enjoyed and that he felt comfortable doing the explorations and the sort of the thought experiments that she encourages you to do. And I can see his perspective. I I still love both books for different reasons, but I understand why someone might gravitate towards one

versus the other. It you know, this book has a lot of practical advice, like, hey, you're in the situation, you haven't found

Carter (07:59)

Right.

Nathan Toups (08:00)

the room, you haven't, are you trying to make impact within the first week, or you know, all these kind of kind of really good tactical things that you really need when you're in this in these positions.

Carter (08:11)

Yeah,

I think I mean how many books have we read at this point? I know end of last year it was forty or maybe even over forty. yeah.

Nathan Toups (08:15)

Ooh. Actually Book Overflow lets us

calculate this because I have if you go to bookoverflow.io slash works and we have covered fifty-seven fifty well this also includes essays.

Carter (08:29)

Fifty. Okay. So that's

filter out the essays.

Nathan Toups (08:33)

Yeah, I can filter out the essays.

It's if it's just books, forty eight books.

Carter (08:37)

That w where's our MCP? We need the book overflow MCP.

Nathan Toups (08:41)

Hey, you know, maybe don't don't

don't threaten me with more features on this tiny website.

Carter (08:46)

Yeah, yeah, don't don't tempt you the good time. Yeah.

yeah, it's so fifty so that so what'd you say? Fifty four, fifty three?

Nathan Toups (08:57)

So we've read we've read forty eight books. it's fifty fifty three works. Yeah, forty eight.

Carter (09:00)

Fort 48 books.

48 books. Okay, great. So forty-eight. So that's forty-eight books at this point. You do get an appreciation reading that many books for how many are well authored. because we've read several books that have great content, but

Nathan Toups (09:16)

Mm-hmm.

Carter (09:17)

aren't as I I think conversational is a good way to put this. yeah, just really she she's a very skilled author, and I appreciate that. We always we try to get as many authors as we can on, don't always get all of them on.

I will be sad if we can't get Tanya Riley on. I've just I love this book so much.

Nathan Toups (09:32)

Yeah. Me too.

Me too. Cause I feel like it would be real I would love to expand on some of the ideas that are in here. I'd also love to hear her perspective. You know, I think this book came out in 2022, which again we we keep talking about this, right? This inflection point between the ubiquity of AI

Carter (09:49)

Yeah, right.

Nathan Toups (09:50)

tools. I would love to hear her views on staff plus engineering and expectations with augmented AI. Just, you know, I don't know where she would fall.

on on the spectrum here or w you know, yeah. So hopefully we get the opportunity. I think that would be really valuable to see, you know, sort of what is what does she think four years later and will there be a second edition of the Staff Engineer book, Staff Engineer's Path?

Carter (10:16)

I'm gonna shoot my

shot. I'm connecting with Tanya on LinkedIn right now. She is she's principal, a d a data dog. All right, Tanya.

Nathan Toups (10:22)

Yeah, there

we go. Principal at Datadog. Pretty cool. That's a I know several folks who've been in and through Datadog and have a lot of have a lot of respect for their engineering practices. even though Datadog,

Carter (10:34)

yeah. Yeah. Where

Nathan Toups (10:36)

I will say, one of the reasons that Datadog's so big is that they have the what they call the Hotel California method where you know it's very easy. You can't check

Carter (10:43)

Yeah.

Nathan Toups (10:46)

out guys. Like so, you know, if if you're not careful.

you will get so hooked on data dog specific observability features that it's pretty painful to get off the platform.

Carter (10:55)

We we need her. I

she lists herself as living in Albuquerque now. And I I love the the mountain west energy this podcast has. We gotta we gotta get more of that. all

Nathan Toups (11:02)

nice. Yeah. Yeah, that's cool.

Carter (11:06)

right, well enough about where Tanya Riley lives. Sorry, Tanya, it's on LinkedIn. Hopefully you don't mind our audience hearing that you live in Albuquerque. okay, let's talk about the actual book. I love it. Starts out strong with chapter one with an office space reference. where the chapter

Nathan Toups (11:21)

Yeah.

Carter (11:22)

is what would you say you do here?

Nathan Toups (11:25)

Yeah.

Carter (11:26)

yeah, and just gets this idea of like what is a staff engineer? And I think one of the topics she hits on really well. I think kind of the way to I think to understand everything about your career as you progress, not just a staff engineer. And we should make it clear for any new listeners or you know, like people who are new in the industry, generally the progression for software engineer is gonna look like junior engineer, title level, just plain software engineer.

Senior engineer and then staff engineer. senior engineers, there are generally, and again, this is like general, right? One per team, two per team, you know, like that. These are that's kind of like the team lead software engineer. And then staff engineer is going to be and she she says sometimes they're at a per team level, but where I've I've seen it at kind of like because we're in kind of Silicon Valley techie company speak here.

They

tend to work a little more at like the director level.

Nathan Toups (12:25)

Mm-hmm.

Carter (12:27)

and then are coordinating across teams. Although she says it isn't unusual to maybe have them on a team and reporting to more of a manager. but she talks about this idea of local maxima, which is that if you're a team and you're just making your own technical decision, you might see something that maximizes the value for your team. But if you compare it against the larger organization, it might be

then it or basically, yeah, like the value you deliver your team will be higher than the value you'll deliver the whole organization. Just the the job of the staff engineers to basically look at those decisions and determine when is the local maxima different from the the greater maxima, which is like, okay, I see that by you making this decision for your team, it might deliver more value for your team, but it's actually delivering less value for the whole organization than if you were to go with

this decision, which actually delivers lower value for your team specifically.

Nathan Toups (13:22)

Yeah.

And I she brought up a really good point too, which was, you know, the the sort of example was, hey, you know, there's some software that's really easy to get set up real quick, you know, down and dirty. But if you or you could do the software that you think might help more long term, but it's gonna cause you to go through maybe two or three sprint cycles to get it set up. And then for your one team, it really makes no sense, right? You just do the do the scrappy version and just get it over with. But

Carter (13:50)

Right, right.

Nathan Toups (13:50)

If you could look across the teams and go, you know what? This is gonna have such a huge and positive transformate for transformational change across the entire org. If we just like bite the bullet, do the two to three sprint cycles and then deploy it to everybody, this is gonna have a huge, you know, d disproportionately positive outcome for the organization. And that you really have to have to make that sort of calculated risk, right? Because you really are asking to kind of interrupt flow short term.

You need to have that sort of like larger horizon in perspective. and and then of course she immediately goes into, well, isn't this the job of the CTO? Like w w wouldn't you want

Carter (14:28)

Right, right.

Nathan Toups (14:28)

just the executive technical leadership to do this? And it's a valid point in the sense that if your organization's small enough, sure, like the CTO is gonna kind of play this role, right? And kind of have wrap their mind around everything. But the organization's large enough,

there's no way that they can have that perspective on literally everything in the system. That you need to start having other sort of, you know, technical leadership roles that kind of dig into making sure that, you know, excellence is sort of applied, you know, in a broader in a broader spectrum.

Carter (15:01)

Yeah. And we we have this a little bit at my company where we only have the one engineering team, but because of like vibe coding there's like kind of ev everyone wants to be an engineer and and we have we have our mono repo. And I I always say like that is my job as the principal engineer is to protect the sanctity of the mono repo. And I I don't let anyone who's not an engineer contribute to it. But you know, sometimes they'll want to set up their own little websites, kind of like top of funnel stuff. And we have this is very like a local maxima versus

What's the upside of local maxima? Greater maxima? Is that is I don't even know why you'd

Nathan Toups (15:35)

Yeah,

I I don't know. Global? Maybe global maxima? Yeah.

Carter (15:38)

Global. It's global. It's global

maxima. Yeah. anyhow, and and they're just constantly want to be like, well, I'll just spin up my own little database and you know, have my I've got my fly.io account or or whatever, and I'll do this or that. And we've kind and and it's one of those things where it's like they can move a lot faster. And we've kind of had to provide the framework and say, no, we actually have this this little Cloudflare stack. Like we want to do everything on Cloudflare because what happens if you get hit by a bus and now we have

You

know, you you have this on your personal account or you leave the company and so it it's very one of those kind of like local versus global maxima.

Nathan Toups (16:17)

Yeah. It it it's interesting too, because each each organization is gonna have to have figure out how they rein stuff in. I'm I'm working with a client where it's really exciting. There's a finance team that's starting to protot and we're really sp very specific in words that we use. So we say, Hey, you're welcome to use Claude and Claude Code to prototype ideas. It helps us a lot with helping us understand. But we we we have this idea of like a scorecard, right? Or a readiness for production.

And so we make it really clear like, hey, you can do all this stuff. You can even like have your own sort of bespoke things. If the business relies on it, we have to go through this scorecard system. We have to get you into the you know the proper tools and these other things. So we don't want to stop them from being scrappy, but we also want to make it really clear like, hey, if you get something that comes out of this system over here, we don't support it. It is not something you should rely your business on. We haven't vetted this thing. And but that's like a

That fits the culture there, right? There might be some regulatory frameworks or reining in, you know, gung-ho folks that you'd maybe don't want to have that much leeway. And yeah, I think again, staff plus, which maybe for the uninitiated, right? There's staff, then principal, then I guess distinguished is if we're gonna talk about yeah, just sort of and sometimes you'll throw a senior in there, right? Yeah, there you go. yeah.

Carter (17:33)

Distinguished, right? Then Supreme. I'm gonna I'm gonna

get that title one day. yeah. There's only one in the whole world. yeah, I I think

Nathan Toups (17:45)

Wow, yeah. That'd be good. All right. Yeah.

Carter (17:52)

here's the I actually wanted to ask you about how this went in your career because something she mentions like this is the real sign of staff engineer and as you're getting

more and more senior. People quit telling you what to do. Right. You, your job is to come with your own backlog of work. Your job is to be kind of constantly looking at business priorities. And, you know, you should be working closely with your manager or director. But at a certain point, you should be telling your manager or director, like, this is what I'm doing. My my manager, he says he always likes the word I intend to, right? Like, and so you should be basically saying, like, I intend to do this, I intend to do that.

And at that point, you're kind of just looking for vetoes, not necessarily for sign-offs. and and I think that's something I struggled with when I made that transition. Like I always want to be a team player and I want to be like the good soldier. And so when I kind of started making that transition from like, wait, people aren't gonna tell me what to do anymore. Like, I have to tell people what I'm going to do. It was a bit of a rocky transition for me.

How did that go for you in your career?

Nathan Toups (19:03)

Same. I so you know I've kind of always identified to be in these like early stage scrappy startups. And then I joined a startup that was Series C funded. And for me, it was the largest company I've ever been in. There's thirty 300 ICs. And what I and I was staff on that on that in that company. I was shocked at how little.

I I was shocked at how much freedom I had at setting my own agenda. And I think I wasn't prepared for that either. I looked at it as like, I'm actually like a startup within a startup, right? Like I it got on my side, it was a kind of a familiar pattern in that you have to do the same thing in an early stage startup because no one's nothing's set up. You have to figure out who your customer is, you have to figure what the business does. And it's pretty disorienting, right? I think everything up to staff, there's still pretty clear marching orders. Even a senior level

Carter (19:56)

Right.

Nathan Toups (19:57)

engineer.

You know, maybe you start doing staff-ish things and finding work, but you could have a very good career as a senior engineer, basically doing whatever your product leads tell you to to do.

Or in maybe you're

Carter (20:10)

Right, right.

Nathan Toups (20:11)

pushing back as a a good engineer should, right? A good engineer should push back and say, Hey, I saw that you committed to delivering this next week. There's no way we don't know what that is, right? It's like these are fuzzy things.

Those are that's totally fine, but you're still operating within the framework of like somebody gave you something and you're coming back with like yes or yes or no, right? The the professional sort of idea that Martin that Uncle Bob has brought up. But yeah, I I remember like I've made a couple of like high impact projects. I I've talked about this in the past. there's a developer experience initiative. So this is a very staff here here this is a this is a good example. When I kind of came

Carter (20:50)

Right.

Nathan Toups (20:51)

into my own.

I was asked to work on this. I was embedded. I was embedded on the platform team. I was this, I was a staff platform engineer at this company. We are trying to get, you know, reduce cognitive load, make it, you know, the same defaults be the right thing, make sure that we're having a consistent way that you can just write business code and not have to think about infrastructure all the time, right? That's like a big part of our platform team. But I noticed the disconnect between leadership and

The engineers. I heard engineers grumbling, I heard middle management grumbling, and I heard executive leadership grumbling. And none of them had the same view of the world. And I was just like, this is crazy. You know, so I started talking about this idea to folks. I'm like, hey, you know, how should we approach it? And I realized the only way we could do it to solve for this one team that we were on that had a lot of dysfunction was to actually look at the entire org. And so then I had to go in like find engineering managers across teams and say, hey.

I think if we went about it this way, this would be the right way. And you know, so I had to, I kind of like made up a set of work for myself. And it was it was the most successful thing I had done at that company. It it ended up, you know, lasting much longer. And there was a couple other areas where one of them I got way too into the weeds, and we'll get into this part here where I realized that too late in the process that what I was doing was actually not the most valuable thing. I should have pushed back on a couple of the framing things earlier.

Carter (22:12)

Right.

Nathan Toups (22:13)

and so again, that's the other part is it there's a it's a lot of pressure. It's a lot it's really weird to talk about what you're supposed to do as a staff engineer because there's not just like a playbook. And again, if you read this book and you read Will Larson's book, that's the big takeaway. Like this the reason people can't easily define what staff engineer is is that every organization has different expectations. Every organization has shortcomings that you need to overcome.

you have to fit your personality and working style into the working style of what's expected. And we'll see this in the chapters to come. it's kind of nuts that it's kind of nuts to think about that like the way I behave in one organization could be exalted, right? People could go and like, wow, this is this

Carter (23:01)

Right, right.

Nathan Toups (23:02)

is what a software engineer is like. And then you go to another organization, they're like, Why did you take three days to write an ADR?

And you know, get a design document

Carter (23:09)

Yeah, right, right.

Nathan Toups (23:10)

together. We work fast here and you just like build c show me code, right? In another organization that you'd be considered rude and presumptuous if you did that and you need to write a design document. And this book does a much better job, I think, than Will Larson's in that where you're like, hey, I thought I was doing things right. No, actually, I'm I'm going I would aga I would love to hear more about your perspective though too. Like did you have some aha moments when you're in your first staff role?

Carter (23:38)

Yeah, no, I definitely did. I think a couple things stand out, which is one, when you're younger in your career, you get a lot of points, if anything, all of your points, basically from just execution. And someone can give you kind of like a bum project or a bum assignment. And you if you execute it well, then you know, even if that like turns out to be a disaster for the business, if you have a good manager, they will or even not even just a good manager, but like if

A

good culture that understands that like junior and mid level and even senior engineers are just kind of taking marching orders. They'll say, look, yes, that project itself wasn't great, but Carter did a really good job executing on it. And so I want to give

Nathan Toups (24:21)

Mm-hmm.

Carter (24:22)

him a lot of credit here. As you rise up and become staff engineer, that's not the case anymore. and you have to you own you own what what you work on. And what was frustrating for me was realizing that.

If I went and asked people and kind of said, like, do you think this would be helpful? Like, I'd I'd be happy to do this. They'd be like, yeah, yeah, like that would be super helpful. And then you do it, and then and then people I I my transition was rocky because it was like I wasn't doing high impact enough work. And and I was frustrated because I'm like, Well, everything I've done, people have expressed interest in getting done. And

I think it just it requires a level of insight that I had not needed to develop at previous jobs. in particular level of kind of business insight of like, okay, what problem are we really trying to solve here? What are the big bottlenecks around that problem? I also think it's it's one where I I would have done better with.

coding agents because this staff engineer role I've been thrown into had also it was a completely new stack I had never worked on. It was like Rust with Ruby on Rails and like a bunch of like like yeah,

Nathan Toups (25:46)

that's right. I remember that. Yeah.

Carter (25:48)

yeah. I I didn't love it. and so it's it's I kind of felt like I was fighting upstream and like just it was it was Google Cloud instead of AWS where I but I was very familiar with. and so yeah it

It was challenging in a lot of ways. And I also think there's something to be said for like I I loved Be So Good They Can't Ignore You by Kel Newport. And he talks about this idea of like developing career capital. because basically he he says like rewarding, fulfilling careers are rare and in demand. And so you need to have something you can offer in kind of

Nathan Toups (26:24)

Right.

Carter (26:25)

when you're when you're competing for these rare in demand careers. I think as a software engineer.

I've said it a million times in this podcast. We're very blessed in this industry that generally the harder we work and the more you study, the better you'll get at this job. And the better you get at this job, you will generally be compensated for it. There are absolutely cultures out there that will just take as much work as you can get as you can give them and just chew you up and spit you out on the other side. But even if they chew you up and spit you out on the other side, you'll usually come out a better engineer. And then that will let you bargain in the in the next career.

Or I guess the next job you take. And it's like you said, Nathan, you can be you can be an excellent engineer in one culture, and then you go to another culture and and it's just you're you you don't jive with it. and some people are

Nathan Toups (27:15)

Yeah.

Carter (27:15)

really good at adapting. And and I think, but even if you are really good at kind of mechanically adapting, there's something to be said for like, well, what do you personally what's personally kind of makes you the happiest? What work style works really well for you? And so

Nathan Toups (27:27)

Yeah.

Carter (27:29)

So much of success, I think, in this industry is just placing yourself in the right positions so that you will naturally succeed. it's all just about kind of being selective, but you can only afford to be selective if you are legitimately talented at the job. And when you are seeking out a new job, it's not just I have to take anything I can get, or you know, because I need to provide food for my family.

And I almost wonder if people get in these kind of like negative cycles of like, I'm not good at my job. So I get let go. So I have to take anything I can get. So I wound up, I wind up with another crummy job, which doesn't help me kind of develop my skills. And I'm floundering in that one. So I get let go, right? Or I wonder if some people could just get into like one job where like they've got the right manager or they've got it's the right kind of business, it's the right kind of culture, and if that would kind of let them like like a virtuous cycle almost.

Nathan Toups (28:24)

Yeah.

I it it is it is interesting because I I think another we're still mostly touching on the first chapter, which is a big positive one, which is a lot of this too is developing a new set of skills, right? It really is a different job. I think that's how one of the things we're trying to like really push through here. Your communication skills are have to be at at another level than they were when you were a senior engineer, right? You are having to

work across aisles, look at competing objectives, making sure that the communication channels. I think sh she lists like five axioms, which is like, you're a leader, right, not a manager, right? That's like part of it. That this is it's the you know, the technical role, you're autonomous, you have to set you have to help set technical direction and that you also have to communicate well. Right. And so like these kind of pieces, those all exist in the lower jobs, right? You should be developing

These these ideas. And I've definitely, I mean, I think Carter and I've both seen this. There are folks straight out of college who you can just see are natural thought leaders, right? They

Carter (29:32)

Right, right.

Nathan Toups (29:33)

don't they they understand their place, right? They understand that they're brand new, but they'll kind of gently introduce a new idea or show why this kind of new tool is excellent or that maybe we're thinking about the business direction the wrong way.

And you should absolutely cultivate that, right? You don't have to be a manager to be a leader. You can be a leader just through your insights and and in that portion. And yes, I agree. Like we're we're very lucky that we get to kind of push we get to have a career where we don't have to go into the to the manager track. Cause I will say it it can, you know, I I for I always forget what this one is, but there's that, you there's that.

Phenomenon where you can get promoted into incompetence. Like you, you, you meet some incompetent person and you're like, how did you get here? Right. Like, how why you're you're so incompetent at your current job? How did you get to this point? And it's because the job below where they are right now, they probably were competent. You know, they probably were were pretty good at it. And then they just got to something that was outside of their depth. And being a manager is a career shift. It's like a fundamental career shift. And some people just shouldn't do it, right? Some people should not become managers.

They're bad managers, even if they might have been fantastic software engineers. And you know, if that was the only way for you to succeed, quote unquote, is to go and push up that path, it would be we'd lose a lot of talent and there'd be a lot of value on the table that we we we're not getting. And so, you know, I think this culture shift really happened in the general industry with the rise of Google, as far as my can understand. I mean, maybe some other companies were doing it, but Google

I think really popularized the dual track and making

sure

Carter (31:14)

Right.

Nathan Toups (31:14)

that they had the same prestige that the manager track had. And and of course, I think that I think this is great. And again, I I think that it it seems quite mysterious until you have books like this, the the Staff Engineer's Path and in in Will Larson's book, you I would see the name staff and I was like, What does that even mean? Like I remember the first time I saw it, I like, wait.

Is that better or worse than senior? I don't know, cause senior sounds like it's like, the senior, you know.

Carter (31:40)

Yeah, right, right. Staff sounds like what

like title level engineer should be.

Nathan Toups (31:46)

Right. And I think about my wife used to work at a a CPA firm and I'm thinking their organization the sta like a member of the staff was not senior. Right. Like it was like that was

Carter (31:55)

Right, right.

Nathan Toups (31:56)

if you became a staff accountant, that was just like, your means you're not just doing the trial period of you know, can you hang? and so I was confused from

Carter (32:04)

Maybe it means like

Nathan Toups (32:05)

that too.

Carter (32:05)

maybe we do it in our industry because it means like you get a staff, like a big like like a scepter that you get a rule. Yeah. Yeah, like a bow staff. That's

Nathan Toups (32:11)

like a like a bow staff. Yeah. You get nunchuck nunchuck skills. Yeah.

Carter (32:16)

Yeah. If I have my own company, we're gonna hand out bow staffs to our staff engineers.

Nathan Toups (32:20)

Ooh,

that's good. You become you get a wizard's beard and a bow stuff.

Carter (32:23)

Yeah.

I want to make sure we talk about the archetype, she says. actually, this is not a Tanya Riley. This is a a Will Larson. He describes four archetypes. And I think we covered this in when we described when we did Will Larson's staff engineer book. He said she describes him as tech leads, architects, solfers or solvers and right hand as tech leads, partner with managers to guide the execution of one or more teams, architects responsible for technical direction and quality across a critical area.

Solvers

weight into one difficult problem at a time and right hands, add leadership bandwidth to an organization. She also says, like, you know, you might cross over into many of these different archetypes. but I think this is kind of a good way of understanding the dimensions of this role and that you don't necessarily have to be like in fact, she kind of counsels against like this idea of like the super coder or whatever who's like prickly and difficult to work with, but it's just such a genius that everyone kind of

puts up with him or her. 'cause like you said, Nathan, I mean staff engineer it's it's a leadership role in in most

Nathan Toups (33:30)

Yeah.

Carter (33:30)

ways.

Nathan Toups (33:31)

Yeah. It's and I will say again, those are such four different skill sets that you really can gravitate towards one or the other, right? Yeah y and we saw this in the Will Larson book, and i I will say it's kind of cool. Will Larson's book came out a year before this book. So Will Larson's came out in 2021, this get book came out in 2022. So there is some influence there. Obviously, you know, the Tanya was aware that the Will Larson book existed.

And I'm glad again, I'm glad that there's two different perspectives. I know that for myself, I gravitate towards the architect and the solver side of of that of that equation. I really enjoyed those kind of problems. Really juicy problems that folks haven't figured out is the type of thing that makes me really happy. And then the architecture side of like, is there some elegant pattern or principle that we can, you know, put into this and let me think deeply on it and come back with with some designs.

That's how I complement teams quite well. And so I know that I would I'm in those, but I've also been, you know, I I've I have a client where I work really closely with the CTO and I do feel like I'm the right hand on a lot of stuff. I can represent the ideas, you know, the CTO is maybe defending this one perspective or trying to move towards a new pattern strategically for the organization. And I'll kind of act as a surrogate for that, right? I'll be like, hey, you know, this CTO really has been pushing this through. We should be delivering on this by next quarter.

Let's make sure that your project ties into this. You know, it's just and so like again, you kind of you can kind of like weave between these as needed. But it it's I find it to be a lot of fun. If if these sound a lot of fun to you, highly recommend, you know, investing in thinking this way.

Carter (35:17)

Yeah,

I I love the way she in chapter two talks about is this idea of the three maps. She says you got a locator map, a topographical map, and and a treasure map. The idea with the locator map is that you just have to know where you sit in your organization, right? Like cause it's a big difference. Like, are you kind of a central services team that is enabling other teams, or maybe are like you responsible for a critical area? Like maybe you are the checkout team.

And like you own responsibility for the checkout page in particular. the topographical map is this idea of like, okay, what you know, what are like it's like culture, it's politics, it's like what what are the potential hazards you might encounter when trying to get from one place to another? This is gonna be a little more unspoken. This is where you're gonna understand, like, okay, it turns out that, you know, this other staff engineer actually has.

A fixation with TypeScript or whatever. And so if you're gonna do anything

Nathan Toups (36:18)

Right.

Carter (36:19)

over there, like it you're gonna have a hard time, or or the opposite, my boss jokingly, but like he he doesn't like TypeScript. Like he wishes we did everything in pure JavaScript, to which I have told him frequently he's insane, right? And he is he's mostly joking. Some people aren't joking, right? And so you might know, like, okay.

Nathan Toups (36:34)

Yeah. I think I think that's

the DH H hot take if I remember correctly. So

Carter (36:38)

That that man is nothing but hot takes. and then or or you know, you might like sometimes I would only learn like months or years into a job, like, these two directors, they can't stand each other, right?

Nathan Toups (36:55)

Ryan.

Carter (36:55)

And you know, and so if you are if you're doing anything that kind of crosses between them, like that that's gonna be tougher. Maybe avoid that. and then there's this idea of the treasure map, which is like, okay.

Now you know where you are. You have an idea of kind of the hazards along the way. But where are you going? Where is the, you know, the pot of gold at the end of the rainbow? And something that kind of goes along with that idea is that as and as you become a staff engineer, you've got to be more and more comfortable with delayed gratification. She says, programmers like coding because it's like it's like a little mini performance review with every keystroke, right? Or I guess at this point with every prompt, where it's like, great, like the code works.

as a staff engineer, you're gonna have to become more comfortable with this idea that you're gonna embark on initiatives where it's not going to be clear that it's necessarily working for months. I mean, Will Larson talks about this idea of it being a year's. and

Nathan Toups (37:49)

Right.

Carter (37:50)

now that is definitely very like the Silicon Valley big techie style companies. I'm at a startup now. Nathan's done a lot of work with startups these days. I'd say at a startup if you're doing something that you're not sure if it's gonna be working in a year.

Like I don't know. Start stone tend to have that luxury. but

Nathan Toups (38:09)

Yeah.

Carter (38:10)

yeah. What were you gonna say?

Nathan Toups (38:11)

I and she brings this

up she brings this up. I think it might be in chapter three. I can't quite remember. Maybe it's in chapter two, where yeah, the maps are super important. I'll well, two sides of this. I'm really the the topographical map, I had that's probably my my, you know, biggest growth opportunity that I've had in the past because I'll c I I tend to come into situations like sort of bright eyed and bushy-tailed like a puppy dog.

Like just ready to, you know, collaborate and play on stuff. And I sometimes I'll realize, like, actually, there's a lot of politics I have to navigate, right? Or there's like certain yeah, even if it's a good idea, maybe somebody has some scar tissue from using a way of doing distributed systems. And if you even mention it, you're just gonna get shut down and lose credibility, right? Like there's kind of dysfunction that you might have to overcome that you need to be aware of.

Because you might know that it's still in the best interest, right? Like, this person came from an organization that like used and abused event sourcing and didn't really know what they're doing, and it was just like a big tingled mess. But you look in this company and you're like, actually, this would fit the shape of the problem we're trying to solve quite well. How do I get buy-in? Right. Like these are the kind of like top a topographical map pieces, which is like, do I can can I get

Other people that this person respects to also consider the idea and then make a good case to like address all of the reasons that this could blow up in our face and while we're how we're minimizing that risk. These are the kind of like it that seems like a lot of political calculation, but it's just kind of part of being a persuasive person, right? You just kind of have to say, Hey, look, this is a good idea. Prove me wrong. Look, if anything that I've presented to you here is bad, or if you can give me a counterexample as to why it's a waste of time, please do that. Right.

You can be really up front. That's my personality, at least. the other one, the treasure map part, is is also an interesting one because you can play to that or you can play against it. If you're a contrarian, I'm an I'm a natural contrarian, actually. which is weird, right? So like I have the puppy dog side of me, but then I also have this like contrarian. and so sometimes you can see everybody's running one direction, and you're like,

Awesome. This is the direction we should go. We should like all do this. But sometimes you see them running all the same direction, you realize they're running off a cliff. And it's really actually important for you to be like, hey, I think we shouldn't be so gung ho about X, right? I think that maybe we should kind of tamper things down a bit. And here's some examples of why I think things could go wrong or it could blow up in our faces, right? and so you don't know you can't make that kind of case unless you have a treasure map, right? And I think this this ties into she also talks about this like the fog of war.

and the in the in the the risks of you going too deep on one team because you can start losing no first

Carter (41:07)

Right, right.

Nathan Toups (41:08)

of all, you can't see it larger perspective. You start losing that. But then also like people will forget what you're up to, right? Like if you go too deep on

Carter (41:14)

Right, right.

Nathan Toups (41:15)

one team, they're like, What it what have you even been doing? And it's like, actually we've been doing this really cool stuff, but you have no visibility, nobody knows. Maybe your team's not assessing their impact to the rest of the organization properly. so yeah.

Carter (41:28)

Yeah, and this this gets back to like Will Larson's idea of snacking. It has overlap with Cal Newport's idea of pseudo-productivity because that's what's tough is when you're earlier in your career, it's just like I was given my assignments and I completed my assignments. Therefore, I am successful. And you can get into a a position where you are working every day, you are delivering value to the business. Like that's not in dispute.

Right. that you are useful in some capacity, but guess what? They start paying you the big bucks at a certain point. And naturally they start asking themselves, well, are we getting X amount of dollars of value out of this engineer? Right. And you know, I've had that before with with engineers I know. And when I've been close to my managers and I've known they're kind of on the bubble, and and I'll kind of advocate for them and I'll say, I think they're doing well. I think they're improving.

You know, I I'm happy and and they'll they'll tell me they're like, well, no one doubts that they're improving. No one doubts that they're delivering something. Are they worth what we're paying them? And they'll directly

Nathan Toups (42:37)

Yeah.

Carter (42:39)

counter or they'll directly compare them to to other engineers, junior engineers,

Nathan Toups (42:44)

Right.

Carter (42:44)

right? And say, you know, are they one and a half times better than this other engineer?

Nathan Toups (42:50)

Right.

Carter (42:51)

I think that's something that's an unspoken rule that people don't talk about, which is this idea that like,

You can be at the same title and rank as another engineer, but if you negotiated better in your interviews and got more money, I think you're tempted to kind of be like, Well, we're all the same rank, so surely we're all judged the same. No, people will always judge you based on how much money you're being paid. And for what it's worth,

Nathan Toups (43:15)

Right.

Carter (43:15)

I don't think this is like a bad thing. I think it's totally fine to be like this person

Nathan Toups (43:18)

No,

Carter (43:19)

makes a lot of money.

Nathan Toups (43:20)

you should aim to be multiples of value more than you're being compensated,

right? Like that's the whole point. Is if I'm barely treading water and I'm like, I'm maybe doing about what my salary is, or I'm doing less than my salary is, you should be worried, right? You you should say,

Carter (43:34)

Right, right.

Nathan Toups (43:35)

I don't understand what business we're in. I don't understand how we're going to make money. Now it could be that you're in a startup and you know strategically that you're trying to get into the market and you you're just not there yet. And that's why you're raising money and you're doing those things. That's fine.

But you should still be able to project out and say, hey, if we hit our revenue numbers that we're shooting for and we're hitting the growth that we're shooting for, am I justifiable? Like am I doing 3x, 5x, 10x of value contribution? And again, that's also really nice to know because then you can negotiate more salary later, right? You say, hey, look, I've I've demonstrated having millions of dollars of positive impact on these projects that I've tied into the company. If you get if you get good at talking like this.

Then they can debate with you, be Yeah, you you say this, you're padding your numbers. I actually think you've had less impact than you think. You know, that's a reasonable one. Being completely ignorant and being like, I just worked on what you asked me to work on, and you know, I have no idea if it's good or not. You know, that's you won't you can't operate at staff level and the compensation that comes with staff level if that's how you're thinking. One good.

Carter (44:39)

Remember when

I was just gonna say my my dad is a psychologist, and so I'll often go to him for like essentially what is it? It's really just a d a son talking to his dad. I like to think of it as free counseling. And yeah, I I

Nathan Toups (44:52)

Yeah, occupational therapy.

Carter (44:54)

remember this was during a time in my life where it was like I was helping a buddy with his startup, I was working at like a big tech company, my wife was

Pregnant. I was doing my master's degree. We had just moved from Florida to Utah. And we're like trying to get our house settled and things like that. And I went to him and I was kind of like, I'm just feeling really anxious. I'm just wondering how I can not feel so anxious. And he just kind of told me he's like, Yeah, you probably should feel anxious. Like you have a lot going on in your life. the solution to being less anxious is to start getting rid of some of these things.

Nathan Toups (45:28)

Yeah.

Carter (45:29)

and he was totally right.

And I've I've told that to engineers too. Sometimes they'll come to me and they'll be like, I'm just really worried about my standing at the company, right? Or I feel like and I'm I'm really worried. And I've honestly said to some engineers before, I'm like, I think you should be. Like, I don't think you're delivering the value that that the company expects from you. and and like we talked about, sometimes that's just a selection effect. Sometimes it's just like, you know what? My work style isn't really in line with this company's work style. And so

I think we all might be happier if I just went and found something else. Now I've had engineers who come to me and said, like, I'm just really worried and they're like, I think you're doing really well. Like I think this one thing that kicked off this worry, you're right. Maybe you could have handled that better. But in general, I think you're doing great. Don't worry about it. But but you know, like I

Nathan Toups (46:16)

Yeah, yeah.

Carter (46:19)

I think that whole question of like, are you delivering multiples of value on what they're paying you? Like we should be asking ourselves that every day.

Nathan Toups (46:27)

Yep. The the other one that I think is really good that came up in this second chapter was if the users aren't happy, then you have to change your priorities, right? And so I think there was a quote something like, yeah, nines don't matter if users aren't happy, right? Or or nines don't matter if users are unhappy. Meaning that you should you know, it doesn't matter that you have this beautiful high availability, you know.

super elegant CI C D pipeline. If the website breaks every time they try to use the shopping cart, you know, this is this is the

Carter (47:03)

Right, right.

Nathan Toups (47:04)

non-starter. And she also brings up these like there's kind of like interesting stories of like weird things that's kind of been thrown on her plate. And she had I I don't think she was in this personally, or maybe she was, but she has a story about like long-term power outage was happening either in the city or in the building. And the engineers had to like take diesel gas tanks

Upstairs to get to the data center to like refill the backup generators, right? And like who knew that that would be part of your job, but that was to keep the website up, right? Like while things were going, you couldn't use the elevator, you couldn't, you know, you couldn't do all this other stuff. and that you sometimes, yeah, you have to go down to the data center and stack some do stack and rack or you know do funky weird things. But it really does at the end of the day, you have to remember that like happy customers are what keep you employed, right?

And that

Carter (47:55)

Right, right.

Nathan Toups (47:55)

sometimes you kind of have to go on these really weird detours and your willingness to do this, to to like prioritize that, versus some sort of like, you know, platonic ideal of what a good server setup is, is that's really important too. I think it that that comes down to this like your ability to understand the maps and things like that.

Carter (48:17)

Right,

right. I I really want to talk about because the we're doing the first four chapters of the book this week. And so we spent a lot of time in part one. I really want to talk about part two and this idea of the

Nathan Toups (48:31)

Mm.

Carter (48:31)

the chapter is titled Finite Time. w we we say in software engineering all the time, like it's just it it's all trade-offs, right? I love Martin Fowler when he was on the podcast talking about this idea that like

He doesn't like the term best practices. He likes the term sensible defaults because everything we do in engineering is a trade-off. And everything you do with your career is a trade-off as well. and she talks about five resources: energy, quality of life, credibility, social capital, and skills. And she frames around this idea that like there's 168 hours in a week. So everything has an opportunity cost. I always tell.

'cause I've been I've been hammering this with our junior engineers a lot. and I mentioned on the podcast here this idea that like you're either accumulating capital or spending capital in a job. And I'm just now realizing, like, I wonder if that the genesis of that idea came from reading this book all those years ago. but at any rate, I think I see engineers who they kind of like almost learn the rules of the game. They start to understand, like, okay, yeah, you know, 168 hours in a week.

And so and so is putting in more hours and is getting rewarded for it. But that's not fair. Cause I thought we all kind of agreed to like a 40 hour a week thing. And there's a part of me that's just like, I don't know, like that that's just kind of how the world works. And yeah, I I have this problem sometimes. Like I try really hard to like watch my weight. I I lost like 60 pounds in college. I'd got in like a you know, I got into a place I wasn't happy with, right? And so

I lost those 60 pounds and and ever since then have, you know, you know, really tried hard to make sure that I I stay at a healthy weight. and it's almost like I would watch sometimes I'd see people who are like heavier and they would just be eating in a way that like I wished I could eat, right? Like I wish I could drink

Nathan Toups (50:32)

Mm.

Carter (50:33)

milkshakes, I wish I could just eat slices and slices of pizza. But I I stopped myself from doing that. And I'd think to myself, like, well, that's unfair, right? Like that that that they can do that. I think like, but it's not unfair. It's not unfair at all.

They they have their reward. They they have made that trade-off, which is for them, they've said, I don't mind being heavier, but it's gonna but I I'm gonna get to kind of indulge in all these things that I I don't get to indulge in. and I think I see engineers making kind of like a similar mistake where they say, like, well, this person's getting all this kind of reward or recognition at work, but that's not fair, or they're only getting that because they're putting in more hours. To which I'd kind of say, like, well, what are what are you doing with your hours? Right? Are you

Nathan Toups (51:12)

Right.

Carter (51:13)

Are you playing more video games or even and and that even sounds like I don't even mean that it's like a negative thing, right? Like it could be that you are practicing the guitar more and maybe you're getting a lot better at the guitar. It could be that you're just enjoying more evenings watching the sunset, right? With with a loved one. Like that's not these aren't bad things, right? I have an engineer I work with who's just very good about he shows up at nine, leaves at five. That's kind of all he does. Very, very, very talented.

He has a great relationship with his his wife and children, right? For what it's worth, I have a great right relationship with my wife and children too. You know, so I so I think. but it's yeah, I I think you just

I don't know. Like, you kind of have to know the rules of the game. And once you know the rules of the game, don't be upset about it. You can select out of the game and go choose to play a different game in a different company. Who maybe they look at people who are putting in more hours like, what are you doing? Quit doing that. but at a certain point, like, I don't know. Don't I as they say, hate the, you know, don't hate the player, hate the game, right? Or no, it's the opposite. It's the opposite. Hate the

Nathan Toups (52:21)

Well w and this

gets back to go ahead. I think it's don't

Carter (52:24)

You get what I'm saying. Which one is it? Don't hate the player,

hate the game.

Nathan Toups (52:29)

man, this is gonna be Yeah, yeah.

Carter (52:31)

I think it is. Yeah, it's it's don't hate the player, hate the

game. Don't hate the Yeah, don't hate the player, hate the game. Right. Just that this idea that like don't blame someone for playing by the rules. Anyhow.

Nathan Toups (52:37)

I'm not a I'm not a gangster, so yeah. Right.

Well and I was and this gets back to, you know, one of my favorite books, which is Finite and Infinite Games. which gets to the point of like, you

Carter (52:50)

Great one.

Nathan Toups (52:50)

know, s you do need to identify is this a game worth playing for you? There I never have thrived in the environments where they work you to the bone.

And you have no spare time. I need downtime for me to do my best work. And I think this is the Cal Newport method as well, right? For me to do my best work, I need time to think deeply about something and then time to be away. I like to have think about having boundaries. And I have to renegotiate this. Like it's it's interesting. Recently I've been violating this because I I took on a new client and they're sort of in an exciting moment in in the startup. And so I've been willing to dig into more of my free time than I normally do.

But I also know that this is a temporary thing. Like I can't stay, I can't sustain this. And so I'm having to renegotiate what my boundaries are, when my work hours are, when do I spend time with family? When am I spending time doing continued education? You know, there's there's things I I've struggled with making sure to have enough time to read for this podcast, but I've made it, I've made it happen, but it's not been as enjoyable as it was, you know, eight weeks ago, where I I had had a more predictable sort of cadence to things. And

It this is a this chapter is really excellent. Actually, I mean, we read it right before I finished it yesterday, right before the we recorded today. And it's just a good reminder that yes, there will if you're busy and you're good, there will always be more things to do than you have time for. And you're always going

Carter (54:19)

Right, right.

Nathan Toups (54:19)

to have to you're always going to have to say no to something. And that could be your health. That could be the amount of sleep that you're getting, which I would say is robbing Peter to pay Paul, right?

Carter (54:32)

I agree.

Nathan Toups (54:32)

Those are

not sustainable. you know, and if you've actually we haven't read this on the podcast, there's an excellent book on, it's called Why We Sleep. And he talks about how like if you chronically are sleep deprived, you're basically low-level intoxicated, right? Like if

Carter (54:49)

Yeah.

Nathan Toups (54:49)

you don't if you only get four hours of sleep a night for weeks, that you are you are literally acting not like, you know, test results are the same as somebody who's like keeping a few

drinks all day and and then trying to pass the same test and you're like, I don't want to do that. I w I would

Carter (55:07)

Right, right.

Nathan Toups (55:07)

be ashamed if that was how I was functioning as a person.

Carter (55:10)

Yeah.

Nathan Toups (55:11)

And yet, you know, I'll burn the kennel on both ends if I'm not careful. Right. And so I j I know these things about myself. And so and then it does I think she she does bring up snacking again, just like Will Larson did. And it's it's the busyness theater. If you're not careful, you're like, man,

Carter (55:27)

Right.

Nathan Toups (55:27)

I need to get stuff done. Right. Like, I feel distracted. I've been in meetings all day.

At least I'll get something done. And it feels good and sure maybe it helped a little bit, but that's not why you're here. That's not why your staff engineer is to you know, you're not here to snack.

Carter (55:39)

Right. Yeah.

I I I know we we have said on this podcast before, but I'm just telling you, listening right now, that is among the best career advice. Get enough sleep.

Nathan Toups (55:51)

Yeah, for sure.

Carter (55:52)

it's it's it sounds silly, but I've just any day where I'm just kind of not firing at all cylinders, I'm like, man, I just can't get into something. I I I can't get my, you know, can't get in a groove. Like, what is going on? I think I'm like, I didn't sleep enough. That's all that's going on here.

Nathan Toups (56:06)

Yep. Yep.

Hundred percent.

Carter (56:09)

To the

point where I actually like you can't, you should just get enough sleep at at night. But it it it is something I don't like about working in an office is I I used to do when I would work from home. I'm just like, you know what? Like I should just nap. Like I don't have any meetings. Like if I just if I nap for like 90 minutes and then I can I can make up those other 90 minutes later, but like it's just it's just gonna be way better than trying to kind of like muscle through it. so again, that's the friendly reminder from Book Overflow, just get enough sleep. It really is an underrated.

Cool

and being an excellent engineer. and and I like what you're talking about, Nathan. Just this idea like eventually you got to start saying no. I mean, I feel that in my I I've been not struggling with this, but but just we are preparing to launch this big initiative at work right now, a big customer-facing initiative, which a lot of the company is excited about and writing on. I just will occasionally hear like,

People talking about their projects and like not even engineers, but like the rest of the business being like, yeah, yeah. And so we're doing this thing. And of course, this really counts on Carter's project working. I'm like, great. Like, you know, like I'm excited about it. no

Nathan Toups (57:18)

No pressure, no pressure.

Carter (57:20)

pressure, right? but it's I I've kind of had to hold myself accountable in the sense that like before we launch this thing, I could kind of come up with like an endless series of pre-projects to do and say, really.

For this thing to be successful, of course we need this thing. And there are some things I have kind of called the ball on and been like, no, I I actually really do think like this isn't gonna work unless we get this thing done first. but I I think there were a few things I was kind of toying around with where I kind of realized myself, like, you're procrastinating. You're just scared about launching this really big thing, and you're trying to find other things you can do to delay that. Like you've just, you've gotta.

focus on moving the needle. got to focus on what matters the most. And so I'd say be be aware of that because again, these things I was working with, like I don't even it's not even to me like, we don't really need this, but we but I'm gonna do it to procrastinate. I do think we really need these things, but they're not more important than the big thing I'm working on. And so just just always keep yourself honest, right? Don't

Again, don't fall into that trap of I'm working and I'm working on something the company needs, therefore I'm succeeding.

Nathan Toups (58:39)

Right.

Carter (58:40)

and I know there are people listening right now that are that will bristle at that idea. It's like, what do you mean? How how does it not work like that? and I'm telling you, it doesn't work like that. You have to be working on things commensurate with the value that the company is paying you. And like you said, Nathan, multiples more than what they're paying you.

Nathan Toups (58:57)

Yeah. Yeah, absolutely.

Carter (59:00)

Well, so we so we read these four chapters. This is a three parter, right, Nathan? Are are we doing

Nathan Toups (59:08)

I I put it as a two parter and I regret that. I actually I think it was should have probably been a three parter. we'll see. We'll we'll see if we can muscle through. Yeah. 'Cause

Carter (59:16)

Well we'll keep you posted.

Nathan Toups (59:20)

I realized we didn't quite make it to halfway. So

Carter (59:22)

Yeah.

Well, Nathan, what are you gonna do differently in your career? 'Cause you've read this book?

Nathan Toups (59:27)

Yeah, so we this is something that's kind of personal to me and it just it was a good prompt to remind myself that and I we didn't get too much into the details of this, but protecting your technical credibility deliberately. And so as you move up and senior you could it's into into staff and and beyond, it's a lot it's very easy for you to start being full of hot air, right? For you to start being, well this is the pattern that we should do and then you don't actually execute on it. You just kind of like give a it

Is a very consulting consultant-y thing to do, right? Come and be like, well, if you just, you know, this is the inverse Conway maneuver and like come in here and do that. And you're like, well, that's actually not that helpful. Like we most of the people in the team probably knew that there was some dysfunction. so protecting your technical credibility has to do with also continuing to ship real stuff with your big picture ideas. And so she has some really good advice on how to like be embedded enough or

write code to do handoffs and do these to kind of like help be more hands on. And I I think it's it's exactly what I needed to like focus on. what about you?

Carter (1:00:36)

Yeah, for me, I I just want to be thinking more about this idea of

Nathan Toups (1:00:38)

Okay.

Carter (1:00:38)

like brainstorming a larger technical vision. we are at kind of an inflection point in our company right now where every kind of engineering pod is is launching some key initiatives. And and we've also hired a new VP of sales and like they're really churning on sales. And so it's a little like if these things all hit and we feel good about all of them, then we should enter kind of like a new era of.

Growth and then the hope is that we can raise a series B. And I just want to be prepared. When we raise a series B, we're gonna probably, I mean, double or triple the engineering team. And it's gonna go from Carter is kind of essentially the team lead of these 10 engineers to we've got three engineering teams. And my my hope, and I I believe, you know, my manager's intention is not necessarily that I would remain the team lead of one of them.

But rather move up and and have kind of a more of kind of that staff engineer role over many teams. And when that day comes, I just want to be prepared. It's kind of like, okay, what's important to us? What do we yeah, what do we want to make sure we stick to? What do we want to avoid and just not get caught flat footed when that day comes. And then as far as book recommendations, who would you recommend this to, Nathan?

Nathan Toups (1:01:59)

Is the the the folks that I'd recommend this book to are in the title. So if you're serious about being a staff engineer,

Carter (1:02:05)

Yeah, right.

Nathan Toups (1:02:07)

meaning you're planning to get into this or your staff engineer you feel overwhelmed, right? Those are the those are the sort of like two audiences. definitely check this book out. And I would really recommend if you have the budget, this book plus Wool Larson's book. They're such a good compliment. And if you have the time and energy, do them both.

Carter (1:02:27)

Okay. Well, for me, I I mean I would say the exact same thing. serious about becoming a staff engineer, you want you already are a staff engineer. Like this is we're really so fortunate in this profession that we have these kind of like basically instruction manuals on how to succeed in our jobs. but with that, well, join us next week for either the final part or maybe just part two. We'll figure it out of staff engineer.

By Tanya Riley. You can find us on Twitter at BookoverflowPod. I'm on Twitter at Carter Morgan. Nathan and his consulting agency are at rohoroboto.com. And you can contact us at contact at bookoverflow.io. Thanks, folks. We will see you later.