Beyond Archetypes: Rethinking What Makes an Effective Staff Engineer

The most influential piece of writing about staff engineers in the last decade has to be Will Larson's Staff Engineer Archetypes. He argues that the "staff engineer" title covers at least four very different roles: the team lead, the architect, the solver, and the right hand. This taxonomy gets cited extensively as advice for people trying to become effective staff engineers.

For many engineers aiming for promotion, these archetypes have become a roadmap. In fact, during both of my promotions to staff engineer, my manager linked me to the "staff engineer archetypes" and asked me to consider which of these roles I was aiming towards.

While these archetypes definitely exist, I think they represent bad practical advice when presented as targets for engineers. Archetypes do not make good goals for career progression.

The Problem with Targeting Archetypes

Let's take the "team lead" archetype as an example. Larson describes this as an informal technical leadership role: someone good at scoping work, planning projects, and maintaining the relationships needed to successfully ship. If you want to fill this role, shouldn't you start trying to do these things?

No! You don't become a technical leader by trying really hard to be a technical leader, much like you don't become a writer by trying really hard "to be a writer". You become a technical leader by doing good technical work until your skills and relationships emerge organically.

I wrote about this process in my post "Ratchet effects determine engineer reputation at large companies." To get good at shipping large complex projects, you must start by shipping tiny pieces of work, until you're familiar enough with the system and you've built enough trust to take on slightly larger pieces.

At each stage, if you do good work - "good work" here means "deliver shareholder value" - you will very naturally be given opportunities to work on more complex and important things. If you try to jump ahead, you're going to run into all kinds of problems:

1. Important projects are usually assigned top-down, not bottom-up. You'll either be trying to muscle out the planned engineering lead for a project or pitch your own (complex, important) engineering task to senior management. Good luck with that!
2. You likely won't have a good enough relationship with senior management to know what their real priorities are.
3. If you're not yet trusted to execute, you may get assigned "minders" (often current staff engineers) who will ghost-lead the project through you.
4. You'll likely make poor technical decisions.

The other archetypes face similar challenges. If you want to become a successful architect, you don't get there by studying software architecture in isolation, because you can't design software you don't work on. The "solver" and "right hand" archetypes both rely on having an enormous amount of trust and influence that can't be aimed for directly, because trust and influence accumulate over time.

What Actually Defines a Staff Engineer?

The idea of "aiming for" a particular staff engineer archetype reflects a misunderstanding of what the staff engineer role is. What is the defining attribute of the staff engineering role, then?

A staff engineer has to be useful to the company. Of course, a senior or mid-level software engineer ought to be useful too, but all they have to do is execute on the job in front of them. If they end up not providing value (maybe their project turns out to be unimportant, or they don't get the support needed to succeed), that's their manager's problem, not theirs.

In contrast, staff engineers are expected to deliver value regardless: to make the project work, or to find something else useful to do if the project truly can't be salvaged. This is an unfair expectation. Often projects really do fail through no fault of your own, and sometimes it just isn't possible to conjure useful work from thin air.

That's actually by design: the staff engineer role is supposed to be unfair. Something many engineers don't realize is that all senior management and executive leadership roles are unfair too, in the same way. That's just part of the deal: executives are given power and great compensation, and in return they get thrown off the boat in bad weather.

"Staff engineer" is the first engineering role where you are held largely responsible for outcomes you don't control.

Developing a Staff Engineer Mindset

Developing a "staff engineer mindset" thus has very little to do with the archetypes. Instead, you should:

1. Develop the habit of constantly asking yourself "is this useful to the company" (and answering correctly).
2. Lose the habit of worrying about if you're being treated "fairly". Instead, try to think about your role in terms of incentives and consequences.

At the beginning, you won't look much like any of the staff engineer archetypes. You will look like being a level-headed engineer who can be trusted to move projects forward with a minimum of fuss, and who can be re-tasked to different work without complaining. You'll also look like someone who's paying a lot of attention to what their manager's actual priorities are, and who is thinking hard about how to fulfill those priorities (instead of their own goals).

If you do this for long enough, you'll eventually find yourself in one of the staff engineer archetypes. However, it probably won't be the one you're "aiming for". The whole point of being a staff engineer is that you're willing to fill whatever archetype the company needs at the time.

Community Reactions and Context

This perspective has sparked interesting discussions across developer communities. Many engineers report feeling pressured to conform to specific archetypes as they approach senior levels, often leading to identity crises when their natural progression doesn't match these predefined roles.

In discussions on platforms like Hacker News and Reddit, engineers have shared similar experiences of being encouraged to "pick an archetype" during performance reviews, only to find that their most impactful work didn't fit neatly into any category.

Interestingly, Will Larson's original staff engineer post was pretty clear that these archetypes are more of an anthropological description of some of the varied niches staff engineers fill, not a how-to guide for succeeding in the role. At the time, the "staff engineer" role was fairly new and people were still trying to figure out what it even meant. Pointing out that there were a few very different ways to succeed in the role was a genuinely novel observation.

The staff engineer archetypes are a good list of ways an engineer can be very useful to their organization - but only once they've built a deep relationship of trust with their organization's leadership. Advice on how to succeed as a staff engineer should be about how to build that trust, not about what to do once you have it.

This approach resonates with many experienced engineers who have observed that the most effective senior engineers aren't those who consciously try to embody specific roles, but those who consistently demonstrate reliability and business acumen while maintaining technical excellence.

The critique also highlights a broader pattern in engineering career development: the tendency to create overly prescriptive frameworks for roles that are inherently fluid and context-dependent. As one engineering manager commented in a discussion: "We've taken a role that's fundamentally about adaptability and tried to turn it into a checklist. That's counterproductive."

For engineers aspiring to staff level, the key takeaway might be to focus on delivering consistent value while developing the judgment to know when to lead, when to architect, when to solve, and when to support - whatever the situation demands.