Discussing Staff Engineer by Will Larson: How to Navigate Technical Leadership Beyond Senior Level

Carter Morgan (00:00)

I think a lot of it just comes down to like, you might read a book like this. You might think, ⁓ I have to get to the real engineering. I got to get to the Silicon Valley style companies where I'll finally be happy. It's not necessarily the case.

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 am Carter Morgan and I'm joined here as always by my co-host Nathan Toops. How you doing, Nathan?

Nathan Toups (00:31)

Doing great, everybody.

Carter Morgan (00:33)

Well, as always, make sure to like, comment, subscribe. can share the podcast with your friends or coworkers, share it on LinkedIn, share it in the work Slack. Anything to spread the podcast helps us grow. And if you'd like to, ⁓ spend more time with Nathan and I, can always book a coaching session with us on Leland. are there and, ⁓ we are already coaching a couple of people from the podcast. so we'd love to talk to you about anything you might be needing help with in your career. And we are excited about the book this week. This is a book that's been on the list for a long time.

And we're finally getting around to it. It is Staff Engineer by Will Larson. Let's talk a bit about Will Larson first. Will Larson is currently the Chief Technology Officer at Imprint, a modern co-branded credit cards company. has over 15 years of experience scaling engineering teams at high growth companies with previous CTOs at Carta and Calm and senior engineering positions at Stripe and Uber. Larson is a recognized thought leader in engineering management, having authored four books on engineering leadership, including An Alleyan Puzzle and Staff Engineer.

It maintains the widely read engineering blog Irrational Exuberance. And elegant puzzle, I've heard about this one a couple of times. Have you read that?

Nathan Toups (01:39)

I have it ⁓ on my to-do list to add to our backlog.

Carter Morgan (01:43)

Yes, yes,

that is his management book. ⁓ Whereas this is more about being a staff engineer. And let's read the book introduction. The full title is Staff Engineer, Leadership Beyond the Management Track. It's a pragmatic guide for software engineers seeking to advance their careers beyond the senior level without transitioning into management. Based on interviews with over a dozen staff engineers from companies like Dropbox, Etsy, Slack, and Stripe, the book addresses the critical gap in resources for navigating the technical leadership path.

It covers essential topics, including staff, engineer, archetypes, strategic thinking, technical quality management, and career advancement strategies for individual contributors who want significant organizational impact with remaining hands on technologists. This essential resource provides both theoretical frameworks and practical advice for engineers and their managers navigating the unique challenges of staff plus engineering roles. Yeah. So I don't know. That's a really great description of the book. Sometimes I feel like we read these descriptions and have to actually explain what the book's about. Nope.

That's what this book's about. And so we, we read it. I'll say that this episode is a little different from our usual ones in that this book is comprised out of two parts. There's the first half, which is like the meat. It's all the points he wants to make. ⁓ and then the second half is a collection of stories from the engineers he talked to, to kind of assemble the book, just the way the timing worked out with this episode. I was traveling last week. Nathan is traveling this week, so we're recording at a different time.

I did not get to read all of the stories in the back, but I did read the meat of the book. And he kind of says the stories are roughly optional. So if at any point Nathan references a story that I haven't heard of, that's what's going on here. But we felt confident enough in getting the idea behind this book to be able to cover it in a single episode. All that being said, Nathan, give me your thoughts on Snap Engineer.

Nathan Toups (03:34)

So yeah, so I've been transitioning from going, I think maybe I'm going the opposite direction that you've been recently, which is I've been in a bunch of very early stage startups and then transitioned into some larger startups. I'm still in pretty small ones, right? In the grand scheme of things, know, sub 1000 employees. The one I'm in currently is around 60 employees is still pretty small, but hierarchies start to show up. And I've been in a staff role for the last couple of jobs that I've been in.

Carter Morgan (03:40)

You

Nathan Toups (04:04)

What's funny is that there is no real playbook. It's really strange to get this title because the expectations do change. In each organization, it's got that Conway's law piece to it. It's like, we know that you're not on the management track. We know that you're an IC though that is experienced enough to be ⁓ a larger thinker in the organization, but your job starts

getting a little fuzzier, right? You're writing less code, you're doing these other things. And I just kind of had to figure it out at each organization. And I think this book would have been really helpful like two years ago, maybe two and a half years ago, to understand like, do I fit within these archetypes? ⁓ How do I make sure that I'm maximizing my value versus doing something that feels comfortable? And I actually, like the language that this book uses and I'm pretty excited to jump into it. ⁓

This is a pretty narrow topic, right? So I will say that one thing that we're really diving into here is that this really is about staff plus engineering. This is not like Gerge's book that kind of goes in all encompassing talking about all the different paths you're going on. This book is really sort of those decision point books where you're like thinking about, I want to be a manager or do I want to stay on the IC track? And what does it actually mean to stay on the IC track?

And I think that this book, it's beautifully structured for that. And if you're not interested in that question, then ⁓ we can have a larger discussion. But I think for me personally, selfishly, this is like scratched and itch. And I think he understands why he has a lot of credibility on this topic.

Carter Morgan (05:50)

Yeah, this might be the perfect episode to listen to if you're kind of early in your career or a manager or not really, or are not even aware that this is something that exists. Something I really enjoy about our field and software engineering is that we do have those two separate tracks. You can go into management or you can kind of keep rising up as an individual contributor. And I find that there's a decent amount of people in our field who don't even know that who think that at some point, and honestly, at a lot of companies, if they're not as like

techie, there might not be two separate tracks. You might cap out at senior engineer and then after that to move up, you've got to go into management. ⁓ I'm not sure if this book would be applicable to lots of our audience just because the very nature of the staff engineering role is that at most companies, senior is the terminal level. Once you reach senior, there's no expectation for you to move up. You can say senior for the next 30 years of your career and just be fine. ⁓ and a lot of people.

actively make that choice. You know, when I was at, ⁓ AWS, they were, there's a little different L five is like the mid level position and L six is the senior position, but L five is the terminal role. You're not expected to move up after L five. And I met lots of brilliant engineers who just stayed at L five. They didn't want the increase of responsibilities ago in L six and they did a great job as L fives. ⁓ the book is definitely targeted towards like,

Silicon Valley type tech companies. We're going to talk about that a lot through it. ⁓ I'm, I'm a little burnt out on Silicon Valley tech companies at this point in my career. I've kind of worked for them a lot. ⁓ I found them and granted I was at some during the pandemic, my most recent one, I found to be very mismanaged. And I actually read Tonya Riley's the

staff engineers path, which is kind of like a compliment to this book prior to doing my last role, which had a staff engineer title. And it actually wound up being like not a great fit because I found out that they were using staff the way other people use senior. was weird. And, and so, ⁓ yeah, this is a very Silicon Valley tech heavy. I'm just encountering this book at a weird time because I have recently left big tech and joined a 30 % startup and I found it very refreshing.

Nathan Toups (08:02)

Right.

Carter Morgan (08:15)

that I don't have to worry about any of the crap in this book. And so I, yeah, it's just, I've just encountered this at a funny time, right?

Nathan Toups (08:25)

Yeah,

no, this is interesting too, because I try to read through. I do think that I agree with that critique. And I this will be really, really nice to dive into. There's not a distinction in this book between the inevitable bureaucracy that is big tech and the freedom that the role gives you. So I will tell you what's appealing to me is I'm, you know, there's this, and we should probably read this at some point, it's called The Barbarian and the Bureaucrat.

Carter Morgan (08:41)

Right.

Right.

Nathan Toups (08:53)

talking about how there's two types of personalities when you bootstrapping a startup and you need barbarians to be the early stage folks. They're the ones who can just like get stuff done. And then you mature into bureaucrats because when your business is mature, you understand who your audience is, you know how to grow. The barbarians really don't fit in anymore, right? Like they're not the right people to create a stable platform that is going to grow into a multi-billion dollar company. need those bureaucrats, except...

Carter Morgan (09:02)

Right.

Yeah.

Nathan Toups (09:23)

there is a role for a barbarian if the organization structures itself properly. And I do think that if you look at the archetypes that are in this, if you kind of read between the lines, this is not what Will Larson's saying, this is what I'm saying. Some of the archetypes are a way to have barbarians live amongst the bureaucrats. And I think that if you are that type, and this gets, and we'll get into those where I think, for instance, like the solver or ⁓ the

Carter Morgan (09:41)

Interesting.

Nathan Toups (09:53)

There's certain types of little archetypes in here where a solver, which is somebody I kind of fall into, somebody who kind of floats and hops around and looks at juicy problems and maybe doesn't quite fit into any product team, but maybe looks at this bigger picture stuff. Well, barbarians are good at breaking down barriers that are artificial and doing all these other things. And so ⁓ I do think that if you kind of read between the lines, there is...

something there. think also for early stage startups, and again, not what's said in the book here, I wish it did, is let's say you know you're confident that your startup's going to double or triple revenue, it's going to double or triple the headcount. If you want to position yourself that when the time is right to be on the IC track, that you know that you don't want to transition into management, you don't want to become director of engineering, but instead you'd like to become principal engineer or something like this, right? ⁓

Setting yourself up for success so that your little packet or when you're having a big conversation with the CTO and you say, look, I know how I can serve this organization better as we grow. I'm not going to be a good manager. I want us to create an IC track and I would like to be the beginning of this. This is another good book to give you that template if you think you're going to make that transition. so that's where I, like, if you look at these as like, how could this be useful? ⁓ Even if you're not technically in some, you know,

three levels of management, highly bureaucratic organization that has a very mature business model. And so anyway, that's sort of like my optimistic view of like how I think this book could actually be a little more useful.

Carter Morgan (11:30)

Yeah, I'll say what this book does a great job of is giving that vision for, okay, what does individual contributor leadership look like? I guess I would disagree with the idea that like staff engineers are a way to still be a barbarian in a bureaucracy because in my observation, at least like at the, like the Silicon Valley tech companies, like it's all bureaucracy. Like that is what marks a successful engineer is who can most successfully

navigate the bureaucracy. Um, and I don't even mean that necessarily in a bad way. Like, like, I think one of the mistakes I've made in my career is like working for AWS and AWS is a very impressive feat of engineering and the component I worked on private link. I mean, this thing generated like a billion dollars a year in revenue. was, um, deployed across

35 different data centers and 350 hosts. Like it supported critical operations. Like I remember when HBO Max changed their name to Max. was my problem for some reason, because HBO Max is a huge customer of ours. Like the New York Times, Apple, like lots of stuff was built on the foundation of PrivateLink, right? And because of that, there's lots and lots of like telemetry and deployment, automated deployments and rollbacks and setups. It's very, very impressive to manage this whole thing.

And also because of that, you move very, very slowly when building PrivateLink. It's such a critical infrastructure for so many external businesses and also just for AWS in general. A lot of AWS is built on top of PrivateLink. And I made the mistake of thinking like, this is true engineering. This is how engineering should be done. And it's not true at all. That's an excellent example of critical engineering done at massive scale.

⁓ but it's, will kill you if you're trying to operate like that, for example, at a startup. ⁓ and so in a situation like that, being an effective technical leader does include managing the bureaucracy and, and, ⁓ yeah, working within it because it's very critical to have a bureaucracy to keep this component. That's the backbone of a lot of systems in the modern internet working, but it will kill you.

if you try to implement that stuff at like a startup. ⁓

I guess with like staff engineer roles, I see a lot of that. you, how do you manage the bureaucracy? How do you keep your leadership happy? How are you coordinating across teams? How, you know, this is the point the book makes a lot, which is that your effort is going to be measured across years. And that can be tricky because...

When you're a junior, your effort is measured pretty immediately. am given ticket. I complete ticket ticket is successful. Done staff engineer. mean, you might be setting a technical vision that you might not see whether or not it was correct for two years. And that can be tough because you can feel like, yeah, like you have to have good instincts. got to be. Feel very confident in your vision because otherwise you flail around for two years and you don't know what worked.

Nathan Toups (14:50)

This is good. And I think this is good for us to have a little bit of a debate before we get into the meat of the book, because I still think that there's a meat a middle way in that there are startups that there's the scrappy early stage when where you literally you are the two pizza team. And I think that this hierarchical structure probably is ⁓ overkill in the way that they prescribe some of these. But. I've played the role of like founding engineer.

Carter Morgan (14:55)

Right.

Right.

Nathan Toups (15:17)

in organizations where you are expected to have an opinion, let's say on one of my favorite, I'm going to pick on them because I love Stripe. Stripe is a really cool company. They obsessed over their API early in the organization. Their staff leadership, as they even have in the interviews, were personally obsessed with the API infrastructure early on in the startup. That was a multi-year investment that paid off huge because they

Carter Morgan (15:18)

Mm-hmm.

Nathan Toups (15:47)

just blew their competition out of the water because developers loved the Stripe API. Stripe API is beautifully architected. Maybe some people internally in Stripe are like, oh yeah, you don't know where the skeletons are, to the outside observer, documentation's amazing, the reliability is impeccable, and it was an obsession they invested in early on. And I think that there's a big gap of like, there's a lot of startups that get past the two pizza team.

Carter Morgan (15:51)

All right.

Nathan Toups (16:17)

and are not at Amazon level. And what I mean is that you get to the 100, 500, 1000 engineer level, these orthogonal decisions, how do we build this? Those things will just destroy what we call developer productivity or developer experience. And I do think that staff thinking, engineering really pays dividends. It's these folks that can kind of come in and again,

Carter Morgan (16:22)

Right.

Nathan Toups (16:45)

maybe we can talk about some of the key points here, these archetypes. Early on, you're probably just a tech lead, right? Early on, and tech leads even also will, this is one of the archetypes period. You're not a manager, but you kind of have responsibility for the outcome of some of the engineering efforts inside of a team. And you're like this sort of technical lead, right? That's where this term comes from. ⁓

an architect, right? So again, founding engineers and early stage engineers, CTO will fit this role as well, is that you're architecting the, you're responsible for the direction and the quality, right? Of the product that's going forward. Again, at early stage, that's probably the CTO or some of the early, you know, senior level engineers, you're just kind of being scrappy, making decisions, changing stuff on a regular basis. But you still have this sort of like higher order thinking. You're still having to do stuff that's not structured and not just out of a ticket.

Right? ⁓ You're still having to come up with systems thinking that comes into this. And I think as the organization grows and it matures, some folks thrive in this and some folks really don't. Right? Some folks are really smart, but you really kind of have to give them the five things that they have to focus on. And other folks, you give them this more abstract business problem and they really thrive in that ambiguity. They're the ones who are like scrappy and working across teams and doing this stuff. And I think

If you're not VP or CTO level, right? And your organization's grown large enough that let's say there's a platform engineering team or somebody who's doing internal tools or, we see this a lot, right? Actually in the stories at the end.

There's the infrastructure and internal tools teams, and then there's like the product teams. And it gets tricky because when we talk about staff engineer, I think it's a lot easier to be successful as a staff engineer if you go towards the platform and infrastructure side, because you're thinking in these like abstract ways where a product team having a more terminal folks and like a product manager is probably a perfectly fine way of structuring. You know, you don't necessarily need someone who's pontificating on whatever.

Carter Morgan (18:40)

Right, right.

Nathan Toups (18:56)

So yeah, anyway, last little note before we really get into the book. I remember being so confused that staff was a higher title than senior. Like when I first heard about it, somebody was like, oh, we're gonna offer you staff. And I was like, I don't know. Is that below senior? Like I remember the first time I'd ever heard about it and they're like, are they, or I had somebody who was like, oh, he just got staff. And I was like.

Carter Morgan (19:06)

⁓ yeah. ⁓

I know. Yeah. ⁓

Nathan Toups (19:24)

What does that mean? That seemed like a downgrade to me the first time I heard it. So if you were in that boat, it's okay. It is confusing to the uninitiated people. A lot of people would think that a senior is a higher title than staff.

Carter Morgan (19:36)

Right, staff

sounds like what we should call mid-level. Right. ⁓ And mid-level isn't even a thing. It's just software engineer is the title.

Nathan Toups (19:40)

Yeah, yeah

And

then depending on the organization, then it's principal. And then if you get into this super rare category, but it's called distinguished. ⁓ And a distinguished engineer is up there with VP level at most organizations where you're not managing anyone. You probably invented a compiler or created a programming language. Or you're such a deep expert in some area ⁓ that

Carter Morgan (19:49)

Yes.

Yeah.

Nathan Toups (20:11)

you being this distinguished engineer is this, and I think we've talked about this a little bit in the Unicorn project, right? They kind of outline this.

Carter Morgan (20:19)

It's funny, at my new company, ⁓ they're just, and you find this at every company, but at this one, they're just some engineers who aren't as aware of what the market for Silicon Valley looks like, and they weren't aware of levels.fy.i for looking at compensation. And we were talking, someone was like, there any engineers that make a million dollars a year? And I like, yeah. And they were like, no, there's no way. I'm like, yeah, let's look it up.

I got, pulled up Amazon levels.fyi and I was like, yep, here we go. You have to sign up as an engineer. 1.4 million. Like that's a, you know, I think even principle got close to that. I think that was like 900,000 or something.

Nathan Toups (20:50)

Yeah, with the total comp. Yeah.

Yeah. Yeah. uh, yeah.

Yeah,

it's crazy. I didn't realize, I was like, ⁓ I didn't quite understand this. So I actually was in Georgia Tech and people would talk about levels.fyi and all these other things. And I didn't really understand how insane the total comp was out in Silicon Valley. In the midst of that, I had a friend who was working at Twitter at the time, ⁓ pre-Elon Musk days. I will tell you, I think I've mentioned this before.

Carter Morgan (21:13)

Yeah, yeah.

Nathan Toups (21:28)

Twitter was a hot mess before Elon Musk. People don't talk about this, like they glamorized the before days, but he had, I think like six different managers within a year, you know, constantly trying to figure out, cause you know, they still don't make a profit and they never did. ⁓ his total comp was nuts, right? You know, he was, he was making good six figures just by itself cause it's Silicon Valley. He was an SRE. I don't remember what level it, I think he was senior. I don't think he was staff.

Carter Morgan (21:31)

Yeah.

Yeah, yeah.

All

Yeah.

Nathan Toups (21:57)

But his RSUs basically doubled his income, right? And ⁓ so his stocks that he just got his comp, it's not options, like what early stage startup gets. ⁓ And he just was like, it was the, when he told me, I was like, that is the craziest amount of money I can imagine. And he wasn't even at these like upper echelon compensation levels. ⁓ And yeah, it's, it's, it's I will say very few people.

Carter Morgan (22:00)

Right, right.

Yeah.

Nathan Toups (22:27)

are in the 99th percentile of what Silicon Valley is looking for in talent, right? And that's why their compensation is so high. These people are super rare ⁓ and they are hard to replace. And we even saw this, right? Like look at Mark Zuckerberg, know, infamously has been doing tens of millions. I think there's a rumor that was one as a contract. was like up to a hundred million dollars in total comp over some contract length to hire AI talent. That's nuts. Like absolutely.

Carter Morgan (22:33)

Right.

Yeah.

Nathan Toups (22:57)

absolutely nuts and that blew out all of the levels at FYI step two. If you're a PhD in AI, this is a good time to be alive. Put it that way.

Carter Morgan (23:01)

Yeah.

This is your COVID market. Have at it. Well, so I mean, we've alluded to some of the points in the book, but maybe we talk a bit about like, so what does staff engineers actually do? Cause that's, that's kind of the key construct here, which is so staff engineer it's after senior, which is the terminal level at most positions. Staff engineer is not a direct leadership role. You don't typically manage other engineers. And I'll say that is a bigger difference.

Nathan Toups (23:09)

It's nice.

Carter Morgan (23:35)

outside like in Silicon Valley versus non Silicon Valley companies is non Silicon Valley companies. I see this more often like where it's either like, there's no such thing as a staff engineer. ⁓ And to move up, you have to go into management or ⁓ you have like quasi like hybrid engineers slash managers like you're a tech lead.

and you actually have people management responsibilities, like you're in charge of promotion cycles and things like that. ⁓ And you have to figure all of that stuff out.

But then you get to kind of like the Silicon Valley companies and yeah, you, have what is the staff engineer role where you don't have direct people management responsibilities and your job is kind of coordinating larger engineering projects and

From what I've seen, especially at kind of like the thing level companies, what really sets a staff engineer apart is cross team impact. ⁓ that was my last place. They use the title staff engineer, but then they had like multiple staff engineers assigned to each team. So it was just a weird dynamic and it wasn't like a staff engineering position because again, from what I've seen, that's really what makes a staff engineer is cross team impact. So. Will Larson outlines, ⁓ kind of some,

key categories of what makes a staff engineer. says they set technical direction. They are responsible for mentorship and sponsorship, so growing engineers. They provide engineering perspective. They're in charge of exploration, like taking on ambiguous problems. And they do a lot of glue work, which is doing needed but invisible work to keep teams moving forward. Tanya Riley is the, ⁓ if not the inventor of this term, certainly the one who popularized it. ⁓ As far as how much code you write,

It's a spectrum. Some staff engineers write some code, some write none code, but according to Will Larson, all write less code than they did prior to becoming a staff engineer. ⁓ which I think is an interesting, this is an interesting in the AI era, because I find that frequently tough to explain, like friends or relatives. And they say, like, are you worried about AI taking your job? And I always say like, well, writing the code has never been the hard part. And that frequently shocks people. like, what do you mean? Cause to the lay person.

Nathan Toups (25:51)

Great.

Carter Morgan (25:56)

course that's the hard part. Code is weird. Code is scary. But yeah, as you move further and further up the ladder, you're doing a lot less writing code. But yeah, mean, I don't know, Nathan, what do you think about all this or ⁓ anything to come?

Nathan Toups (26:10)

Yeah, so

in my current company, my title is actually software architect, which is a bit of an old school term. From a levels standpoint, it's above senior engineer. And these are my responsibilities. Like what you just outlined was what I do. And it was a little weird because before I was a staff engineer on a platform engineering team and that was actually

Carter Morgan (26:18)

Rime, Rime.

Mm-hmm.

Nathan Toups (26:37)

pretty clear that I'm sitting across a lot of teams, right? We're thinking about the platform. We're thinking about developer experience and doing these other things. In this role though, I'm at a blockchain company and I'm actually trying to navigate usefulness. I'm technically under the growth part of the organization. And my role is to kind of guide the... Technically, we're actually under what we're calling the research and innovation lab.

Carter Morgan (26:55)

Mm-hmm.

Nathan Toups (27:06)

So it's really fun because I get to play all the time. get to work with, have a technically, guess, a tech lead over a couple of engineers and we're rapidly prototyping and building weird stuff and talking to other teams and figuring out how we can be useful with those teams. And so sometimes even within the organization, it's a little weird to talk to folks because they're like, what are you working on? Cause there may be working on a particular product and we're like, ⁓ we're showing how we can do this really weird thing with this technology and coming over here because

these guys have been pushing this off for a long time because this is like a hard problem to solve. And so I'll write technical specifications or have proof of concept or show how if we do this bit of work and that bit of work and we put these things together. And then I'm also in this sort of like mentoring and sponsorship standpoint. If I see a project going on somewhere else in the organization, I can put my stamp on it and say, I think this is worth, I think there's a there there. I think that there's something really cool here.

they figure this out, this will actually help this other team, right? Like I'm kind of looking at how do we navigate prioritization, and I'm not always successful. Some of these are high risk. We actually have it in our vision document for our team that we should take on high risk projects. We should take on projects that other teams are worried that if they fail, they'll waste all this time. We try to figure out the cheapest way possible to work on a high risk project and then try to qualify whether it's actually.

Carter Morgan (28:26)

you

Nathan Toups (28:34)

worth investing time in. ⁓ We're big enough that we can do this, right? Like there's enough engineers in our company that we can kind of take on. There's enough tech debt. There's enough weird things that are as an organization we're interested in. I love this. I love this because I'm not on the leadership track. ⁓ I'm not on a product team. Cause I think, you if we go back to the Google's book, they really don't talk about staff engineers at all in that book. They talk about software engineers becoming

Carter Morgan (29:02)

Right.

Nathan Toups (29:04)

product leaders, right? And Google's very product oriented. And I think that was the, the path was I go into engineering management or I go into product, right? If you are a higher order thinking software engineer and you really want to get into, and this is how the current CEO at Google got into that, right? He moved into product, but he's a software engineer and he really understood the product hierarchy at Google and then became CEO. Staff is this sort of like weird,

newer title, I think in the same way that Google made up the SRE title, we've now made up platform engineering. You could obviously look at this and go, is this just a navel gazing way for Silicon Valley to give a track to retain talent so that these people don't go off and become CTOs at other early stage startups? Right. I think that that's possible. It's like, can I give these out of the box thinkers who are highly creative a way?

Carter Morgan (29:38)

Mm-hmm.

Nathan Toups (30:00)

of doing something within our organization and solve problems in a way that we're struggling with. mean, to me, and maybe this is a cope because I'm trying to justify why I'm in the organization and why I'm a barbarian popping around at this ⁓ startup. But ⁓ I don't know. I'm loving it, I guess, right now.

Carter Morgan (30:23)

No, I

think it's good. And I think one of the great things about reading a book like this, even if you're not at a place where staff engineer is really a thing is this does give you an idea of like, okay, what does higher level engineering leadership look like? Because I think, especially if you're like an early stage startup or you can work at places and it's not just startups, right? We're like the tactical tornado, which is what John Osterholt talks about someone who kind of just

Nathan Toups (30:39)

Mm.

Carter Morgan (30:53)

codes and codes and codes and codes and just creates lots and lots of different features and doesn't really take any consideration into how this is fit into a larger maintainable architecture. ⁓ Where that is really, really valorized or not even that it's valorized like in the sense that like leadership is explicitly claiming, yes, this is a good thing. We don't care about architecture, but more that your leadership can maybe be busy dealing with other stuff. ⁓

which is kind of the day-to-day people management, growing revenue, that they don't even think about this. And so if you join as an engineer and you're thinking, okay, I don't really want to be a manager, ⁓ but I do want to be a good engineer. So what does that look like? I think the naive approach is just like tactical tornado. Just I'm going to crank out so many tickets. I'm going to write so much code. It's going to be great. And then your leadership will say, whoa, this guy, he's cranking a lot of tickets, writing a lot of code. That's good. Where...

So then if you want to start thinking, well, I'd like to be a force multiplier. I'd like to grow the company. I'd to set us up for success. What does that look like as an engineer and not a manager? That's where all the concepts in this book really do apply very well. Setting technical direction, mentorship and sponsorship, exploration being glue. That is stuff that needs to happen at any company. the amount of time you spend on each part will differ depending on the size of your company. But I have felt that joining

My, you know, this, my current company, a startup, ⁓ I am doing a lot of this stuff. And like last week, I spent a lot of time, ⁓ on our telemetry because we were not in a great place with telemetry. had some very basic metrics, but we didn't have more custom business metrics. so, ⁓ that was something that didn't have to immediately get done, but I kind of took scope of the feature work for the week and said, okay, I think we're in a good place with this. I don't think we need to be, ⁓ we need full capacity on this. So I'm going to.

pop off for a bit, really dive into telemetry and get all that figured out. ⁓ And yeah, like I think that's the kind of thinking, I don't think I would have thought about that if I hadn't been reading books like this or understanding this space a lot more. I think I would have said, hey, look at this big backlog of tickets, of quick features to follow up on. I'll just get a lot of those done. ⁓ But yeah, I am glad to be at a place right now

where like again I'm just I'm very burnt out on the Silicon Valley thing.

Nathan Toups (33:25)

Yeah, totally.

No, and I completely agree. And again, I think this is a book where if you read this just at its surface level, it's very prescriptive on, I want to work my way up through the ranks at one of these major Silicon Valley companies. And you could easily look at this and go, you know what? It doesn't really apply to me. I'm not interested. But if you look at it as a framework for a type of problem solving where you have to navigate ambiguity, there are some really useful pieces. And I'll say this because

I was at this, you bring up that nasty little startup that you're in, the best team I've ever been on, and again, we'll go back to this one, is this FinTech company. And there was only eight of us. We even had a principal software engineer, partially that title to acquire that talent, right? He was like a VP of engineering at another company. We needed him to really help. And he loved writing code. ⁓ He came in and this is the first time I'd ever seen a software engineer who...

obsessed over understanding the business to a degree. He did not just say, ⁓ tell me what I need to do and I'll work on it I'm super smart. He goes, I need to really understand how our business operation functions because I think our approach might be wrong. Right. It was one of these like sort of out of the box. And then he realized one of the reasons we were struggling was because the way that we structured the code wasn't easy to be tested. Right. He identified the fact that he, was a big fan of ⁓

Carter Morgan (34:27)

Mm-hmm.

Mm.

Hmm.

Nathan Toups (34:53)

inversion of control dependency injection type tooling. He was also like a Java background and we had a big Python code base. And so he's like, I'm going to introduce some ideas from Java world into this Python code base. I'm sure some of the Python programmers were like losing their mind, but the code was not maintainable. It was just a complete mess. It's sort of like founder code, right? And he needed to make it into something that was, you know, evolvable over time. And he is one of those sort of like 10 X programmers.

And this is before we had all the augmented AI tools. And I remember within like a week and a half or less than two weeks, well, less than a sprint cycle, he had implemented this dependency injection framework and had gotten test coverage like over 90 % on these like critical code paths. And then with confidence, he actually knew also he found bugs, but left them in the current implementation.

so that he could kind of with the refactoring legacy code pattern that we talked about, right? He made it behave the way that it was expected to, but also annotated where the issues had actually come from and that they needed to be fixed. And he separated these things out. And it was a maturity that he brought to problem solving that after that categorical problem was solved, we knew that we could rely on the CI CD pipeline around that code base moving forward, right? It was one of those things where like,

Carter Morgan (36:14)

Right.

Nathan Toups (36:18)

lots of apprehension, lots of fear. Every time we want to do a code deploy, we're like, this is going to break everything. And he brought this maturity that we were like, ⁓ this is how we should be engineering, right? solve these problems categorically, make it so that you don't think about it anymore and then move on. And it just had a huge impact on me. it, it come back, I come back and think like, how would this guy solve this problem? You know, like what, what am I doing that I'm running in circles because I've just assumed the premise, the premise

Carter Morgan (36:23)

Right, right.

Yeah.

Nathan Toups (36:47)

was given to me is correct, should I question the premise? Should I do this thing? that was this higher order engineering that, again, I think of this guy, name is Brian, and we actually had three Brian's on the team, so I'm not revealing who this was. All three Brian's were awesome, but three Brian's on a team of eight people was ⁓ really special. But yeah, so anyway, I saw this and I was like, this is cool. He was a leader without being a leader.

He was, he solved these kind of cool problems. And of course he would move on and solve all the juicy stuff. Like he loved working with and then empower other engineers and was sponsored things. We got in a crazy whiteboarding session one time and I convinced him of an idea by the end of it, which was like nuts. Cause I was senior level at the time, right? So he was just like, he was like, no.

Carter Morgan (37:37)

Yeah.

Nathan Toups (37:41)

Nathan's right on this. And I was like, okay, this is cool. Like he's got no ego, you know, like it was like a neat, it was like a neat experience where, yes, we had titles, but we were beyond titles. That was like sort of the engineering. And I think we talk, they talk about this too in this book, right? Is that staff in a bigger organization can kind of be this nice, I think in one of the stories later in the book, they actually say this person was the director of, I think platform or something. And then they moved.

Carter Morgan (37:53)

Right, right.

Nathan Toups (38:11)

laterally from director of platform engineering into a staff position. And when they were director, people would be pretty standoffish because they saw them as sort of like the management track, like, management's coming in, they're telling us how to do stuff. But when he was staff, it was like, well, this person doesn't have an agenda. Like, they just really care about the engineering excellence in the organization. And it was easier for them to negotiate maybe a change in the organization. And again, that's a big Silicon Valley

technical bureaucracy thing. But I think that's also pragmatically why this title exists in this large organization is like, how do you have soft power? How do you wield this like soft power and influence people?

Carter Morgan (38:55)

Why, and is a lot about, ⁓ soft power. ⁓ Will Larson talks about that idea that really as a staff engineer, yes, you have some authority, but most of your authority, almost all of it is derived from the actual, managers and to be an effective leader, you actually have to be a more effective follower. and that's

Nathan Toups (39:12)

Yeah.

Yeah.

Carter Morgan (39:21)

You have to kind of be constantly aligned with your management. And I think it's really, I don't know. I, in my career, I've been fortunate. Like I have a good resume. I interview well. And so when I do join companies, I have the ability to be very selective about what I join, even in, you know, when I was looking for a new job a couple of months ago, it was a pretty frosty market.

I still had several offers on the table without exerting myself too much. ⁓ And I know that not everyone's like that. I know a lot of people just kind of have to take the first job that comes their way. I guess what I'd say is I would hope that anyone who's at the staff engineer level would have the ability to kind of ⁓ negotiate or, you know, would be an attractive enough candidate that they are receiving offers from multiple companies because so much of setting yourself up for success.

is being selective in who you work for because especially as an individual contributor, you need to be really aligned with your manager. and if you don't trust them or you think they don't have good judgment or you don't like working with them, that's going to be really, really tough. ⁓ yeah, I, I just, and, then it's also hard to, like, one of the things I don't like at Silicon Valley tech companies is like, it can be nice when you do the interview loop because. And. ⁓

I don't know how this would be at other, like maybe if like real deal staff engineer level, but I know what a lot of Silicon Valley tech companies are doing, like a mid level or a senior loop. You're actually not usually interviewing for that particular role. You're interviewing for the generic mid level senior position. And then once you get that, you are like assigned to a team. Like Google is infamous for their team matching process, which is awful. Like you can get the offer and then still take six months to be assigned to a team. I like this from like an interviewing perspective.

Because it can be nice to not feel like I'm competing directly against other candidates. Like I'm competing against the bar. And so long as I pass the bar, I'm in. I hate this from like a, where you work perspective. Like it's really tough because you can just get like assigned to a random team with like people you don't really know management. You don't really trust. mean, a huge reason why I joined my current startup is because I was, I was kind of only looking at startups this go around. This was the one that gave me the most face time with.

the CEO and the CTO throughout the engineering or the interview process. And over that time, I just came to trust their judgment. And I just thought, you know what, especially when you're going to start up, like you had to be ride or die with these guys. ⁓ and I felt that too. And that like, there's a, there's an amount of like fight picking you can do in private, ⁓ to hopefully change their opinions or determine direction.

Nathan Toups (41:51)

That's great.

Carter Morgan (42:15)

There is like zero fight picking you can do in public because especially as an individual contributor, you need to be aligned completely with what they do. That's where you derive all of your authority. so if at a certain point you don't trust the decisions they're making, like it's just game over.

Nathan Toups (42:31)

Right. Yeah. You know, I've been in a slew of early stage startups and then kind of moved into some of these more, you know, series B, series C level startups are a little more mature. And so I really appreciate what you're looking for with, you know, working at Leland and doing this work. I like that if the company is small enough, I can slack the CEO, you know, if need be and...

Carter Morgan (42:56)

Right, right.

Nathan Toups (42:58)

probably have enough visibility to do these things. I think that that's a lot of fun. I like working with people collaboratively like that. The book really does give us an indication though that, and I've been in this trap before, said, if I only had more authority, then I could do these things. And the book does a great job of squashing this idea, right? The book...

Carter Morgan (43:18)

rhyme.

Nathan Toups (43:25)

it actually does a really great job of showing you that actually the title isn't going to give you the authority. The track that you're on is not going to give you the authority. You actually have to earn this authority from the bottom up. And I would say that the best CTOs and CEOs, yes, they have the title, but they also legitimately have earned it. They have the respect, the good companies have the respect from the staff and do these things. Emulating this in a place where you don't have authority actually has a lot of

benefits, right? Like a staff engineer doesn't hire and fire folks typically. You know, you get to like, so therefore you're not in this side step of, if I interact with this person, are they going to fire me? Right? Like you get to like sidestep a lot of these interesting pieces. And they even, there was one, there was actually a title that I had never heard of. ⁓ where was it?

Carter Morgan (44:07)

Yeah.

Nathan Toups (44:19)

technical advisor to the head of infrastructure. So, and there's these kind of interesting things where I'd never heard of this role. And they also, it was almost like hand to the king, right? ⁓ It was this role, and I was like, that sounds like it would be a lot of fun. If I was gonna be in a big organization, being the technical advisor to the CTO or the technical advisor to some VP of whatever, that would be a lot of like,

Carter Morgan (44:22)

⁓ yeah, yeah.

Nathan Toups (44:47)

That is in alignment with what I love, which is working with a lot of people, looking at juicy problems, being an extension of the vision of that office. And that's this idea here is that, OK, CTO has vision about what the technical direction of the organization is, but there's not enough time in the day for the CTO to talk to 1,000 engineers. So is there a person that can help with the technical vision and be the surrogate and then coordinate back with the CTO on some regular basis?

I thought this was interesting from like, I know that you're a bit jaded by the larger organizations, but amongst a larger organization, that's kind of a cool role. And I think it's like a good example of how a staff plus path could get to like a certain type of unique individual ⁓ who fits into that. anyway, very few people ever get a role like that or even maybe find it appealing. But I thought it was cool to see somebody who was on that trajectory and like loved being in that role.

Carter Morgan (45:43)

And if you get that, you too could make $1.4 million, according to levels.fy.

Nathan Toups (45:48)

Right.

And I will say, you know, this gets us back to like our interview with Jason Fried recently, which is like, don't chase the money. Right. And I think this book actually, if you read between the lines to, ⁓ if you think, man, if I became staff engineer, then that's like senior plus plus. Right. And it's not, I think this book tries to do a good job of saying, this is a different job. This is a different job than being a senior engineer.

Carter Morgan (45:58)

Yes.

Nathan Toups (46:18)

And it's not for everyone. think in ⁓ my thoughts on this is that ⁓ I do think, and I'll get into more of this in the hot takes later, this book doesn't address like the Peter principle problem, which is that like, think that, I think actually in the comments a while back, somebody in the comments was talking about what they would talk about like title inflation. And were we worried that maybe more people are just getting the staff title?

because it's a hiring tactic, they want to get talent from some bigger tech company or whatever, ⁓ I do think that this is a real risk, right?

Carter Morgan (46:46)

You

yeah, I the place I used was using the term like everyone at my last place was one title higher than they should have been. Right.

Nathan Toups (47:04)

Right, right,

right. And it does two things, right? Number one, actually I was doing a little bit of research on some of the people in the stories and I was like, where are they now? Because a lot of these are from like five years ago. And some of them, like one of them moved from the startup where they were staff level and they moved to another company, I can't remember, it Uber or Stripe or something, and they're senior level now, right? So like they were interviewed as a staff engineer talking about all the staff engineer stuff, but whatever new company that they're in, they got their...

Carter Morgan (47:15)

Right, yeah, yeah.

Right, right.

Nathan Toups (47:33)

hierarchy and band changed. And that doesn't necessarily mean it's a promotion or a demotion, by the way. I just want to put that out there. If you have a staff level and you're at a Series C startup and then you go to Google, you're not going to be staff. I can almost 100 % promise you, unless you did something so exceptional that you were actually operating at a VP level and they were like, oh, this person invented...

Carter Morgan (47:41)

for sure.

Nathan Toups (47:59)

you know, memcached or something. And we want to hire them in as staff ⁓ because they're, you know, doing cool open source stuff, Or something. Most likely you're going to go to that bigger company that has probably higher standards for what this means and how you navigate stuff. And you're probably going to be one bump down or whatever. Yeah.

Carter Morgan (48:01)

Yeah.

Yeah, it's tough.

It's interesting the way you think about your career because on the one hand, I think we have to be pretty clear-eyed about our careers and say like, these are jobs and it's not necessarily like that you're going to find a ton of like joy and excitement out of your job. But there's also the truth that like you shouldn't hate your job and you should be able to find some sort of ⁓ momentum or energy from it. Maybe not all the time, right? ⁓

I think for example, I'm going into work in a couple hours and I'm not dreading it. Right. And I, and I'm excited about some of the problems I have to tackle. Would I rather be at home? Of course, 100%. But I'm excited about somewhat the day offers had, I just remember in college, like I didn't really have an idea of what I wanted to study. And I remember thinking like finance, like I think I'm going to go into finance. And so I was doing my finance class and I hated it.

And I thought to myself, I remember doing my homework and thinking, but I can't hate this. This is what I want to do with my life. I was like, what are you talking about? Like you can't do something you hate as your, your job or your career. ⁓ and I think like Jason Fried said, like this book, you kind of read between the lines. You can't chase the money. ⁓ the money's nice, but at the end of the day, you need to be doing something where you get.

A decent amount of fulfillment out of it. And the people interviewed in this book and staff level roles seem to really enjoy what they're doing, but not everyone would. mean, when we were looking for a job a couple of months ago, my wife and I were talking about it. Like, do we want to move to Silicon Valley? Do we want to go do that thing? Do we want to try to work our way up through the ranks at Apple and become like a senior engineer or a staff level engineer? And just in my heart of hearts, I was like, no, that's not what I wanted out of my life. Like, and.

Nathan Toups (50:20)

Yeah, same. ⁓

Carter Morgan (50:22)

And maybe I'll change maybe in a couple of years, you know, I'll, you know, have played and become more competent technically. And I feel like, know, what I really would like to work at a place where you're just purely thinking about the technical stuff, but right now it's not what I want right now. really like being at a place where I get to think a lot about the business and the product and see how the sausage is made from all the different angles. ⁓ that's what's given me motivation, energy right now, but

You just need to be aware of what you're getting into when you get into a staff engineer role, because it's not just, I'm a senior engineer, but I get paid more. It's like they say, like you're writing a lot less code. It's a lot of like internal politicking. It's a lot of courting efforts across teams. It's a lot of keeping your manager, your sponsors happy. That is death for some people. Some people really thrive on it, but you know, different people are different. You just got to know who you are.

Nathan Toups (51:15)

Right. And, and I will say like I, my career, I've wandered a lot more, right? I, I have not. Yeah. So like I've not been driven like that. that just never has been my personality to me. was, there's one through line, it's my modus operandi has been, am I working on what I think are interesting problems? And I know that that is very like woo woo.

Carter Morgan (51:22)

Right. I'm in my wandering phase.

Nathan Toups (51:45)

sounding, but it, so there's this feedback loop, which is, I be deeply interested in the thing I'm working on? And can I maximize the value in compensation by output of those things? And so when I realized like, yes, sure, I could work on like, you know, chip tunes or something like some weird Nintendo thing, is there a way for me to be valuable and sustain, you know, my family and stuff with that? No.

Carter Morgan (51:46)

Sure.

Yeah. ⁓

Nathan Toups (52:13)

right, like at least not one that I've figured out. So while I would put that under like interesting, weird hobby, it would not be something that I'm going to invest time and energy into. ⁓ Turns out that I just really like the intersection of like humans with ⁓ thinking about how bits flow over the wire, right? A lot, if you really kind of reduce down what I do as I really, I like thinking about the software engineering side, but I also really care about the infrastructure. And we talk about the glue part here.

Carter Morgan (52:20)

right.

Right.

Nathan Toups (52:42)

So one the things that I've noticed in my organization is a lot of people breeze over and have a high pain threshold for getting test environments set up. And so one of the things I took onto my shoulders was, well, our brand new junior engineer should be able to spin up environment. I don't know when, right? That was my like sort of little product piece. And we made a really like scrappy version of it, but I've continuously invested in making this easier and trying to.

Carter Morgan (52:51)

Right.

Right.

Nathan Toups (53:09)

share this with other organizations. And we even have an open source component to our work. And so I've reached out to the community and said, hey, if you're looking to develop on the platform, we solved these problems for ourselves, but you're welcome to use our code. You have a one-click spin-up of this test environment. And feel free to use it. And if you have some improvements or some feedback, we'd love to hear it. ⁓ No one asked me to do that. There's not a single OKR that's like,

sitting there and being like improved developer experience by 15 % or something, right? ⁓ I just know that I categorically wanted to solve this problem. I've solved this in the past. ⁓ And ⁓ I knew that we could have good outcomes from this. ⁓ There's some caveats though. And I will say like part two of operating as a staff engineer, I think we'll tie this back into the book. ⁓

There's some things that you need to be careful about. And these are really alluring, especially when you're stressed. ⁓ They talk about avoiding snacking. I love this terminology, which is this is low impact work that feels productive. So when I'm the spinning up the environment, I have to ask myself, am I just coping right now? Like, I doing this because I know how CI CD pipelines work and I really like local dev environments.

Carter Morgan (54:17)

yeah, yeah.

Right, right.

Nathan Toups (54:33)

Or is this really actually improving? Is this high impact thing that can improve the lives of our team? the other one was stop preening. Preening is another interesting one. Preening is, he defines it as like low impact work with high visibility. So this is kind of being like, hey, look how effective I am. You're doing something that doesn't really matter, but maybe it gets in front of the CEO or it gets in front of other people. And it's like busyness theater if we're gonna put it in the Cal Newport.

Carter Morgan (54:49)

Yes. Yes.

Right.

Nathan Toups (55:03)

And again, quite alluring, but a way to think about preening in my mind is if I look at all the preening I've done over the last six months and I haven't moved the needle on a single thing in the organization, that's preening, right? You've done a lot of stuff, quote unquote, but could you have delegated that? Could I have given that to a junior dev and use this as a sponsorship or mentoring opportunity, which is the answer is yes, you should absolutely. A lot of those preening tasks should be

Carter Morgan (55:17)

Right.

Nathan Toups (55:33)

a mentorship thing of being like, Hey, I've done this thing in the past. I think you'd be good. think you'd learn about Git or you'd learn about CSED or you'd learn about how this weird memory management thing in our code base works. Like, and you know, that's going to take them three or four times as long as you to do the problem because they don't understand the context. But moving forward, you now go, okay, I've trained this junior dev on how to look at our code base and I can give them this like category of tests. Now you're being a staff engineer.

Carter Morgan (56:03)

Well, this, this leads us to our hot takes, right? ⁓ I guess one of my hot takes, for this book is I think a little bit of preening can be good. ⁓ like I think you can't do exclusively preening, but for example, like I w we, the, the project I've been leading at Leland is Leland plus, which is Leland plus is Leland's content library. so for example, like Leland's bread and butter right now is the one-on-one coaching business, but

Nathan Toups (56:05)

Right.

Carter Morgan (56:33)

There are lots of people who don't have the money for that. And so at Leland Plus, it's like a static content library. And it can be really useful because the content is more vetted and more ⁓ niche for ⁓ what people are wanting. So for example, you can say like, this is a letter that a coach you, or this is an essay that got a candidate into the Harvard MBA program. And this coach vouches for this letter, right? Or there's all sorts of like little things like that. ⁓

So Leland had previously been hosting that on like an off, like the shelf product and had seen that there was enough business value in it to onboard it and kind of build it in house. And that way we can kind of customize it. So that was my project. I led the development of Leland plus. And so, and we launched it just a week ago and it's been good. ⁓ With all of that, there were things throughout the process that I noticed as like little pain points that like the ops team was talking about and the ops being like the, the non-technical folks who are in charge of like actually

administering all of the, uh, this like our clients, um, we're like, for example, one of the things like we have a content upload team, were in charge of taking the content from this third party project, uh, product and uploading it to our, our, uh, our system. built the content upload process. didn't build a way, build a way to delete content entries. Um, they just, it didn't make sense. Like we were just uploading, but the only job was to upload, but we got to the point where.

We did need to start deleting things. And so they asked, said, can we just provide you a list of things you can, you, we need deleted and you can run a script every week or something like that. And I thought for a second, I'm like, give me 30 minutes. If I can't build a real deal delete feature for you and like the ops tool in 30 minutes, then we can talk about it. But, but, let me try it. And I did it. I took 30 minutes. I got it all working. said, there you go. There there's your delete tool. Right.

I can see an argument from like the staff engineers, like this book's perspective that like, no, that was a simple task. What you should have done was created a ticket and then assigned it out to a junior engineer and then mentored them through the process. Maybe I can see the argument for that. I also think there's an argument for showing yourself to be the kind of person who can get, you know, decent impact.

decent visibility work done quickly and is unlocking your business partners to deliver more value more quickly. ⁓ So I think you shouldn't have a ⁓ zero tolerance policy for preening.

Nathan Toups (59:10)

Yeah, you're

right. And I do think you should play by your... I would actually... I think that that was actually an example though of high impact, high visibility work. I... Well, and the reason I say it's high impact was that you solved a real pain point for a part of the business. To me, a low impact thing would be like, you're just not quite happy about the font library that we're using. You know what saying?

Carter Morgan (59:19)

You think so? Is that the difference here?

Yeah, I could see that. here's a great

example. We, for some reason, just the way our auth provider was, we couldn't have the password field show up when you signed up on for an account. It was like you had to enter your email and then it took you to like the Auth0 page. And then that's when you entered your full thing. Our CEO hated that. He really wanted the password to show up on the page. We wound up getting that by switching from Auth0 to SuperBase, but

Nathan Toups (59:51)

Mm-hmm.

Carter Morgan (1:00:01)

Maybe preening is a little more like that. Like if I had said, like, know the CEO hates that the password field isn't showing up. I'm going to move mountains to make the password field show up and ta-da look, that's high visibility. It's on our front page. The CEO likes it, but did you really deliver any value? It's not a huge deal to have the user enter the password.

Nathan Toups (1:00:18)

Right. And I think in that case too,

that's a perfect example of you really should be delegating that out. Like you might write the doc that says, you know, a description of the behavior and why it's important and these other things, and let somebody else sort it out. And, you know, maybe you're the primary person doing the code review or something. ⁓ I think being, especially in a startup, being able to be scrappy, right? This is the David versus Goliath thing, right? This is the only time in this...

Carter Morgan (1:00:24)

Right, right.

Nathan Toups (1:00:46)

you're in the most agile phase of your company's life right now. This is the whole, the benefit of being a startup is that you can move faster than the big bureaucrats. And so, yeah, and it's also leading by example, you if anything, you take a lunch and learn out of this and say, you know what, I time bound this, I didn't want to invest half of a week or blow my sprint out of the water. I said, if I could do this in 30 minutes, if I can do these things, I set these boundaries for myself. And then you're showing leadership because you're saying, hey,

Carter Morgan (1:00:49)

Right.

Nathan Toups (1:01:14)

If you can do this, it has this high impact, relatively low effort piece and you've put a boundary on it, this is the engineering culture we want here. Well, that's cool. That's like, oh, this is the Leland way, right? Or whatever, right? You can give it some cool name. I think that, you know, I'm helping me, we're helping each other. This has sounded really hard to somebody else, but to me, it was actually pretty easy. That's cool. That's like a pay it forward culture thing. So another one I've had to do and be careful about because, you know,

I'm turning 42 this year. ⁓ And so it's very easy to have what they call like the frozen caveman problem. I think this book calls it Chasing Ghosts, which is avoid applying solutions from previous companies without understanding the current context. And so another term for this is cargo culting. ⁓ So this whole idea is this thing worked in the past. And if I just do it again, magically, everything's going to work again. And you really should be skeptical of yourself for this. ⁓

Carter Morgan (1:01:52)

Right.

Right, right.

Nathan Toups (1:02:14)

especially someone like me who's been doing this for a while. And I go, ⁓ back at that FinTech company, we did awesome things with dependency injection. And so if we just add dependency injection, all of our problems will be fixed, right? That would be chasing a ghost. I'm not really deciding whether this is the real most important thing strategically that organization needs to fix to solve some categorical problem. I'm really just saying like, ⁓ we solved a categorical problem with this in the past. so therefore I'm going to

I'm going to champion this, right? And it was awesome. This guy looks so cool. I want to look cool like this guy did, right? That don't do that, right? That is a quick, quick way to undermine your credibility. And what will happen is people will go, dude's old school, like doesn't understand what we're doing, obsessed with these like five things, you know? ⁓ And yeah, so I, again, I, I appreciated this book framing because even if you're not technically a staff engineer, it's just a good piece of advice. Like past,

Carter Morgan (1:02:58)

Right, right.

Nathan Toups (1:03:12)

Performance does not indicate future performance, right?

Carter Morgan (1:03:16)

My other hot take from this book and we've kind of alluded to it throughout this is, is, it, and you talk about this too, very Silicon heavy book, ⁓ Silicon Valley heavy book. don't chase big tech for big tech sake. think there's a lot of people who think this is when you arrive. This is when you, know, ⁓ this is what makes a real engineer. Right. And I always say like, I don't regret any of the big tech decisions I've made. Like they, they pay very well. They've set my family in up.

Nathan Toups (1:03:30)

Oof.

Carter Morgan (1:03:46)

My family and I, uh, uh, very well financially, and they've given me a lot of credibility in pursuing other opportunities. Um, but I actually, I had kind of a funny thought because like we took a pay cut moving from big tech to a startup, not like a terrible, awful pay. was like a 30 % pay cut that, but the thing is that we live well beneath our means. so not only do we still have discretionary income, but that 30 % represented kind of purely discretionary income, right?

The result of that has been that I'm much happier in my day to day. Like I enjoy the work I do a lot more, but it's funny because I was traveling this week. Next year where I was at, went to ⁓ Orlando to go to Universal's new theme park, Epic Universe. But previously when I've done kind of theme park trips, like on Big Tech Money, we've honestly just had as a family, so much money sloshing around that like we could just buy whatever we wanted, like on these trips. Because like when, once you've actually paid for the trip and are in the park,

The difference between like splurging and not splurging is kind of like, okay, I'm either going to spend $300 over the course of this trip on food and souvenirs, or if I just went nuts and just bought as much food and many souvenirs as I wanted, I'd spend a thousand dollars, right? And there was just so much money sloshing around that like that didn't even matter. Like, what are you talking about? $700? That's nothing. We're not at that point anymore. We still have plenty of money to pay for these trips and to buy some souvenirs and to eat well.

But I do think a little bit more when I'm making these discretionary purposes, right? And so I do miss that about big tech is just the money, but it's probably better to structure your life in a way where the thing you do 40 hours a week, day to day brings you happiness. And then the trip you make once or twice a year, you feel a little more constrained than to kind of hate what you do 40 hours a week. But then when you go on the trip once or twice a year, you feel like you have.

a lot of money to spend. So I think a lot of it just comes down to like, you might read a book like this. You might think, ⁓ I have to get to the real engineering. I got to get to the Silicon Valley style companies where I'll finally be happy. It's not necessarily the case.

You just have to know yourself and figure out what it is you're out of. You're looking for out of a career. And that will also change from time to time. Right? Like I think it was really good for us to make big tech money for a while.

It set us up on solid footing. But then once we got that solid footing, I wasn't really interested in continuing that. That to me, getting the solid footing gave me the freedom to say, what do I really want out of my career right now? ⁓ so yeah, just, just figure out what you're looking for. And that might not be big tech. That might not be a staff engineer role. Just got to know yourself. Right. You, Nathan, you got some hot takes.

Nathan Toups (1:06:33)

Yeah, well, I'm from the street rat end of this. the big tech companies weren't interested in me. It was funny is that I actually, if I think if I wanted to go down that path now, I'm much more appealing, but I don't want to. Yeah, look at that. I know, look at that. Hundreds to thousands of views on every episode. ⁓ But I wish hundreds to thousands, yeah. Hopefully that we...

Carter Morgan (1:06:45)

I think so. Yeah. You're the host of Book Overflow. They're banging down our doors to get us to work for them.

Hundreds of thousands? No, hundreds two thousands.

Nathan Toups (1:07:01)

That'll be like a really funny thing in the future. No, I, to me, this is something that's been important to me for a long time. That fulfillment part, I think I'm glad that you found that observation. It's something that I, again, I've tried to optimize for partially because I had to tread my, like create my own path early on. And, ⁓ we did this recently, right? We move, we just moved to Costa Rica.

Carter Morgan (1:07:03)

Yeah.

Nathan Toups (1:07:31)

back to Costa Rica, used to live here. And my wife, her remote job was not okay with her coming down here. So she stepped away. And so it was like, you know, pretty substantial ⁓ adjustment to our income, you know, 35, 40 % reduction in our income. But the unit economics here are way different. So like things are much cheaper. I'm sorry, didn't take that back.

Carter Morgan (1:07:57)

Right, right.

Nathan Toups (1:07:59)

services are much cheaper, things are more expensive. You kind of have to find this sort of like minimalist way, but the environment's so nice, you know, down here that it's very fulfilling to be around the jungle and the beach and the other things that we have. That from a lifestyle design standpoint, you know, yes, the money's less, but we're also in a weird spot where we would do some

Carter Morgan (1:08:02)

Right.

Nathan Toups (1:08:27)

we're doing in the midst of doing some geo arbitrage, we're like, we sold our house in US. Looks like we're gonna be able to pay cash for house down here. We're having quite closed yet, but that's the case. And then all of sudden you're like, man, my monthly budget is completely different. It's like unrecognizable when you're in a absolutely zero debt plus no rent standpoint. And we're living in a place we wanna be in, not one that we're like, ooh, maybe one day we'll live in a cool spot. And so yeah, this gets all the way back to like, there's an old book,

Carter Morgan (1:08:33)

Nice, nice.

Right, right.

Right, right.

Nathan Toups (1:08:57)

super old at this point, but it had a big impact on me in the early 2000s called the four hour work week, ⁓ which was never about a four hour work week. It was really about designing a life that you want. And ⁓ I would highly encourage anyone who's a listener of our podcast to optimize for your life over the money. I think that the money will follow if you really listen to yourself and you really maximize how valuable you are. ⁓

Obviously there are certain paths, like my sister's a park ranger, good example. She's picked a life that's not gonna make a ton of money, right? But she also lives within her means and has probably one of the most fulfilling lives if that's what you wanna do because breaking into that industry has a huge, very high satisfaction score, even with all the crazy stuff going on with ⁓ rethinking about how the federal agencies are. ⁓ But.

Carter Morgan (1:09:33)

Right, right.

the right room.

Nathan Toups (1:09:54)

You know, this is important. And again, I'll put this staff engineering book in that category. ⁓ This is a path you could go on. If you read this book and you go, I feel energized. Like this is exactly the trajectory. I could get, if I could read, you read the stories at end of the book and you see yourself in that person's shoes and you say, I would love that. I would love if I got to go do blah, blah. Then this is a good litmus for you. You're on the right path in life. If you look at this and go, that sounds horrible.

I don't want to do that. Use that too. Listen to your heart.

Carter Morgan (1:10:29)

Pay attention to those impulses. There's a certain amount of eating your vegetables, which is good for you. My master's degree, for example, that was pure eating my vegetables. I didn't necessarily want to be doing a lot of that, but I'm glad I did it. there's, think when it comes to a career, there's only so much eating your vegetables you can do before you just kind of get sick of it all. Any other hot takes, Nathan?

Nathan Toups (1:10:33)

Mm-hmm.

⁓ yeah, just back to that hierarchy problem. I definitely think, and I've seen this in the past. we had a decent number of staff engineers at one of the startups I was in. Some of them were squarely staff engineers. They really were solving these sort of like ambiguity, cross-functional team stuff. Some folks, we obviously hired them from bigger tech and had struggled in

navigating the ambiguity of being in a series C company. And it was interesting to see the Peter principle in play. Again, the Peter principle being people in a hierarchy tend to rise to the level of respective incompetence. ⁓ This is something we should always ask ourselves is, did I get put into this position? Am I getting energy from it? Or did I get put in this position and I feel like I'm doing the worst job I've ever done. And we're like, why am I even here?

Carter Morgan (1:11:36)

Alright.

Nathan Toups (1:11:49)

That's a hard thing to analyze yourself. And it gets back into like the, you ever heard about the Steve Jobs, like Bozo explosion and a bunch of these other things, it's typically what happens is like well-intended individuals get promoted into a level of incompetence. And that they actually probably were pretty great at maybe one or two levels below, but now they're terrible because they're a victim of their own success. I think that this book doesn't address this.

Carter Morgan (1:12:16)

Yeah, I think we've all seen

it.

Nathan Toups (1:12:18)

I wish that this book had a section of like, was like, when to know that this is a bad fit or oops, I'm a staff engineer and I shouldn't be one, right? Like that'd be really nice.

Carter Morgan (1:12:25)

Right, right.

Yeah, the book,

the book kind of assumes that you want to be a staff engineer. There's a little bit of like, make sure you want, you know, like, ⁓ you want this, but like, if you're reading this book, yeah, it's all about what being a staff engineer is about. So, but I guess, you know, maybe the reading this book would help you understand if this is the next step you want to take in your career. ⁓ I mean, Nathan, so what are we going to do differently? We've read, we've read the book. What are we going to do differently?

Nathan Toups (1:12:38)

Great.

Okay. So, the thing I, that spoke to me, there's, there's this idea of creating space for others. So I am a tech lead on the team. ⁓ I will, I mean, you hear me, I talk a lot on this podcast. So I will fill the room with my talking if I'm not careful, right? I will, I will take things on my shoulders. I like, you know, I'm like bright eye bushy tail, you know, happy, lucky puppy in the room. ⁓ but I need to make room for.

Carter Morgan (1:13:13)

Sure.

Mm-hmm.

Hahaha.

Nathan Toups (1:13:26)

optimizing for mentorship and guidance. I've already started doing this. our team is starting to get cohesion. We've only been a team since March, right? So not that old of a team. ⁓ We're really getting into this high trust scenario. And now I'm putting more company visible initiatives on the shoulders of the team. ⁓ I liked that this book, they frame this as creating space for others, right? So it's like, I want every one of my team to reach

the maximum trajectory of where their career can go, right? I need to think about how do I make space for them to show, take risks and to show that they can step up to something that maybe is beyond what they were hired for. And so I like some of the tooling and the framework. I know it's a little more bureaucratic and I maybe am saying this as a barbarian where I'm like, I need to actually like let some bureaucracy fit in here, creating space for others. That's what I'm working on.

Carter Morgan (1:14:25)

No, that makes sense. As far as me, I think I want to continue focusing on high leverage work without becoming too removed from the business justifications. I think that you can fall into a trap where you're thinking, well, I'm rethinking our whole test suite. I'm implementing these pipelines, blah, blah, blah. it's like, that's high leverage in a way, but is it the most critical problem we could be solving right now? I've been trying to take this tack of like a...

Identifying, okay, what are the business challenges we're seeing? And then how are we solving that in like, like you were talking about, Nathan, in a way with, with that engineer you worked with, we're like, you solve it, it's done. We don't have to worry about it anymore. ⁓ so yeah, I just, want to kind of continue to think about things that way. And then who would we recommend the book to?

Nathan Toups (1:15:19)

This one's probably the clearest audience. The audience is in the title. ⁓ So ICs who are senior level and you're considering a staff plus track. ⁓ I would read a book one going down the management path and I would read this book and you should decide which one of these. If you read both of those books and you're like, ⁓ you need to go join a startup.

Carter Morgan (1:15:22)

Right.

Right.

Yeah, I would agree 100%. Yeah, no changes here. Well, that wraps us up for this week with Will Larsen's staff engineer. The next time you see me, BYU football season will have started and my mental well-being is purely in the hands of our newly named 18 year old quarterback. So that's how I'm going to operate the next several months.

Nathan Toups (1:16:03)

And my ignorance

will be bliss, so I'll be completely unaffected by any of this.

Carter Morgan (1:16:10)

Where were you at again? you at LSU? That's a great school.

Nathan Toups (1:16:12)

I went to LSU. It's a completely, people get so disappointed

that I know nothing about, Nick Saban was the coach when I was there, which is like a legendary time period. Yeah. It's before he became like a professional coach for a little bit and then went to our arch nemesis, Alabama.

Carter Morgan (1:16:18)

I know. ⁓ was he real? Okay, wow. Yeah, yeah. That's yeah, yeah.

Alabama. Yep.

Yep. Where he is legendary. ⁓ that's so funny that you were at LSU and Nick Saban was the head coach. You don't know anything about football or about your, your school's football.

Nathan Toups (1:16:37)

I went to one game and it

started raining and I was like, this is terrible. And I left and that was...

Carter Morgan (1:16:44)

No, I'm

a fanatic. We got our season tickets. We're going to be there every home game this year. It's going to be great. It's going to be great. Yeah. Well, anyway, go ahead.

Nathan Toups (1:16:49)

Amazing. Well, have fun.

We're

a little side note for our personal life. My daughter is a huge fan of the band System of a Down. And so we're going to New York, as all nine-year-olds are, completely age-appropriate music. And we are going to New York to see them as an early birthday present. So that's why, again, the scheduling's a little different. So yeah, we're flying to New York tomorrow.

Carter Morgan (1:17:01)

Okay, as all nine-year-olds are.

That's exciting.

Is she watching K-pop Demon Hunters at all? Have you heard? ⁓

Nathan Toups (1:17:20)

She did watch it. ⁓ She's

been like apologizing. She's been like, yeah, she's like, it's really stupid, but some of the music's kind of good. But I mean, it's not, but it is. Like she doesn't, she's very conflicted.

Carter Morgan (1:17:34)

My son wants me to watch it with him. I said, I'm like, I don't like K-pop. I don't love demons. I'm ambivalent on the hunting. know.

Nathan Toups (1:17:39)

It's stupid. It's, yeah, it's really stupid.

I like watched part of it and I was like, I'm not watching this, so.

Carter Morgan (1:17:47)

We watched ⁓ Fantastic Beasts and Where to Find Them last night. We're big Harry Potter fans. I was just at the Universal with the Harry Potter stuff and we're reading through the Harry Potter books, but they love the movies, but we're at a bottleneck where we can't watch the sixth movie until we finish the sixth book. And so he was astounded. He's like, there's a movie that doesn't have, like we can watch it right now, cause we haven't read the book. The movie's not great, but he had a lot of fun. ⁓ Anyhow, that's what you get if you stick around to the end of the episode. You get to hear us talk about our kids and.

Nathan Toups (1:18:02)

Mmm.

Carter Morgan (1:18:16)

K-pop demon hunters and movies and system of a down. ⁓ but you can also find us a contact at book or flow.io on Twitter at book or flow pod. I'm on Twitter at Carter Morgan and Nathan's newsletter, functionally impaired at functionallyimperative.com. Thanks for sticking around folks. I looking forward to next week. Do we know what we're reading next week? I think we've planned it, but I don't.

Nathan Toups (1:18:18)

You

Ooh,

yeah, it might be finite and infinite games, but we might have adjusted the list. So we'll see. There are folks who are excited that we're going to read this book. It's a little more philosophical and pretty short. several people have talked about how there's a huge influence on them. So maybe we'll do it. Otherwise, I need to go look at our backlog and see if that's not accurate anymore.

Carter Morgan (1:18:40)

Is it that?

No, I think it is, Finite and Infinite Games. I don't know if we had explicitly said we're reading it, but it's the next thing on the list. So that's, we're committing right now. It's Finite and Infinite Games. Look forward to it, folks. All right, we'll see you around. Thanks for listening.

Nathan Toups (1:19:04)

We're doing it. It'll be a good one.