Defining The Role Of Staff Engineer w/ Will Larson of Calm

**Dan** (0:02)
Today, we're tackling one of the most ambiguous and subjective roles in the software engineering career path, the staff engineer. Many companies don't even have this role, and the ones that do have a hard time defining exactly what it means.
What we do know is that it's a leadership role that takes a different path. Will Larson, the CTO of Calm, and author of the new book, Staff Engineer, Leadership Beyond the Management Track, joins us to share his research on what a staff engineer actually is, how to hire one, and the differences between leadership and management.

**SPEAKER_3** (0:47)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**Dan** (1:02)
Will, thanks for joining us today.

**Will Larson** (1:05)
Thank you, Dan, for having me. I'm super excited to get to talk a little bit about the book.

**Dan** (1:10)
Yeah, awesome, awesome to have you here.
And if we're just gonna jump right into it, the staff engineer role that, from my experience, might be one of the more subjective roles. Actually, many of the companies that I work with or have been introduced to don't even have that type of role. So for our audience, could you define what a staff engineering role means?

**Will Larson** (1:41)
And this is really why I started thinking about this problem. At my last job, in particular, I started being responsible for coaching all these different staff engineers. And a lot of them were having these kind of existential angst, like, what is my job? And how am I being evaluated? And then, as a manager, you're like, well, of course I have the answers for you, but you're like, I actually, really didn't have the answers for them. So I was like, what do I tell them? And so I just wanted to understand the problem space better in terms of how do I actually give honest, useful advice to folks?
And I just wasn't really sure what to say at that point. And that's where I started by just talking to a bunch of different folks in different companies and trying to understand the space. And so from that, I think the first answer is like, every staff role is a little bit different. There's no such thing as this one standard across different companies, but there are some standards that you can kind of see in the work in the industry. So first, the most common progression is kind of a mid-level engineer, a senior engineer, a staff engineer, a principal engineer, then a distinguished engineer would be kind of on the top of that. A lot of companies don't have all of those. And I would even say most small companies with less than 50 engineers probably shouldn't have any of the kind of senior plus ones, but some do. And so then within them, it's like, okay, so you have a hierarchy, but is this just like a senior, like seven years of experience as staff, like 12 years of experience as principal, like 16? Is it just something like that literal? And it's like a little bit different.
It's really, as I've talked to more folks, this idea of like archetypes is how I've started to explain it, where there's kind of a team lead, who's someone who's like really giving a lot of direction, support and enablement, partnering really closely with usually a product manager and usually an engineering manager about how the team's technology roadmap and execution works.
I've found this idea of the solver, where most companies are now very team oriented, but often you'll find people just like floating around in organizations, kind of bouncing from problem to problem, particularly like the biggest problems that the company leadership sees. So for example, a couple years ago, like GDPR is a great example of a problem that a lot of companies like decided to put off as long as humanly possible. And all of a sudden there's this like actual like mile like deadline looming. And then they kind of like brought in like their solvers to figure out how to actually get on the right side of it.
The other two that I found is this idea of this architect. So it's funny, like in the period of time that I came up in the industry, there's no title like more hated than the architect, right? Where it's like no architects is like the number one goal for like most teams where you're like, you're interviewing a company and let it go, oh, we have architects here, you're like, I just don't think I can come work here after all. Like really, really red flag. Just huge red flag, right? But it's funny, cause it's actually really valuable work. It's just the old style of what an architect is was like top down, ignored the teams, like the impact on the teams of their behaviors.