Staff archetypes are anti-patterns
Why the Staff+ archetypes are counterproductive and what to do instead?
Staff Engineer: Leadership beyond the management track by Will Larson identifies 4 archetypes for Staff+ roles:
Architect
Tech Lead
Solver
Right hand
I used those archetypes a lot when I was a new Staff Engineer. I have used it as a reference hundreds of times and shared it with tens of thousands of people.
These archetypes are great because:
They frame a simple, memorable shared language for how high impact engineers operate
They acknowledge that there are different paths to becoming a force multiplier
They clearly indicate what areas to grow more —as we’ll elaborate soon.
But as I gained more experience over the years and across companies, I realized that the most impactful Staff Engineers I know, aren’t any of those archetypes. They’re all. Plus more!
What makes me respect them isn’t the archetypes but their ability to switch hats as the situation calls for it. They are all rounded great engineers and technical leaders.
This post elaborate why those archetypes are anti-patterns and how the most effective Staff Engineers work.
🤖🚫 Note: No generative AI was used to create this content. This page is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs. (why?)
The problem with archetypes
I have been following Will Larson’s work and highly respect his insight as someone who has catapulted my career into technical leadership. This is not a criticism of Will but rather an observation that was solidified with many examples over time.
First, what is an archetype? Below is an excerpt from the book:
The more folks I spoke with about the role of Staff-plus engineers at their company, the better their experiences began to cluster into four distinct patterns. […] In literature, recurring character patterns are called archetypes […] and the archetype term is helpful for labeling these frequent variants of Staff-plus engineers.
So archetype is roughly same as pattern, variant, or flavor in this context.
My counter-argument boils down to the title vs role distinction which we have covered before.
In a nutshell:
Title defines responsibilities towards an outcome with narrow ownership. For example:
Front-end developer, develops front-end and doesn’t necessary touch backend or do QA or DevOps. Those concerns are handled by other titles.
Project Manager, manages the project and leaves the customers, strategy, empowerment and other aspects to other people with appropriate titles.
Role frames around the impact and broader ownership. For example
Software engineer uses engineering disciplines and methods to create technical solutions. That may involve coding, architecture, testing, operation, etc.
Product Manager effectively acts as a mini-entrepreneur for a product. That may formulating hypothesis, market research, collaborating with design and engineering, and even marketing and budgeting if the situation calls for it.
So let’s go through the 4 archetypes and diagnose what exactly goes wrong when they are treated as informal titles.
1. The Architect anti-pattern
Architecture is just ONE of the concerns of good engineers and effective technical leaders. Other concerns include QA (quality assurance), operations (e.g. DevOps/SRE), security, database, etc.
We need well rounded engineers (generalists) who own knowledge, mandate, responsibility and that requires:
Up-to-date and hands-on experience with the very artifacts that’s used to implement an system architecture.
Full accountability of the decisions made as an architect. And being on-call is the minimum guarantee to manifest that accountability.
I’ve been in the industry more than 2 decades and am yet to meet someone who specializes on architecture but hadn’t turned into the dreaded Ivory Tower Architect (ITA).
In recent years the word architect has got a bad rap in the software industry (examples 1, 2, 3, 4, 5).
What do you think ITA’s did?
Renamed themselves to Staff, Principal and Distinguished engineers!!! 🤦♂️
The nature of the task stays the same: draw boxes and arrows, act as a tech-translator prolonging the undeserved career of high level engineering managers, and call the shots without accountability.
They changed the facade without upgrading the interior.
It works in the broken organizations with poor leadership who can’t tell the difference between confidence and competence. That’s also the equivalent of painting yourself to a corner career-wise.
The tech translator is objectively bad for the organization because shields leadership and engineers from each other.
Sometimes even, there’s a tech committee in place which itself acts as a tech translator for the tech translator!
This is not a joke! It’s a patch to a broken system. Engineering leaders need to understand engineering without the need for a tech translator. There’s no way around that. Not even AI! 🤣
For the tech translator, it’s career dead-end. You can only go to so many meetings before your technical axe is blunt and engineers learn to work around you. The practitioners tend to converge to mandate-heavy initiatives like governance and compliance —more on that in a minute— but are light in implementing automation.
If you choose that path, beware that your career choices are limited to equally broken organizations.
2. The Tech Lead anti-pattern
Previously we’ve elaborated that the main value proposition of the Staff+ role is to own a technical solution that spans across multiple teams.
If the scope is one team, Staff Engineer is an overkill. There are different schools of thoughts about the role of Staff Engineer.
Some see it merely as a career level to justify the pay or years of experience
Others, see the change in the job title from Senior Engineer to Staff Engineer as a signal for a change in job description and impact.
I’m in the second camp. Staff Engineer is not more engineer than Senior Engineer. It’s a slightly different type of job acting as a force multiplier, hence the title change.
For the tech that is inside one team, the engineering manager is expected to be technical enough to cover that need. If the EM is merely a team lead doing admin stuff and babysitting the engineers, they’re not doing their job.
Tech lead can be used as a patch to cover for incompetent EMs, but as we’ve elaborated previously, this is an anti-pattern that is harmful for the team, tech and product.
3. The Solver anti-pattern
We’ve all seen those super-skilled coders (also known as coding machine) who can solve problems that are too complex for others and deliver solutions in record time.
That technical moat is respectable. In a way the Solver is the opposite of Architect.
However, to go ahead and call them Staff Engineer creates more confusion than clarity.
There is, however, a need to distinguish between a “regular” Senior Engineer and a high-impact Senior Engineer if the title and pay are hardly coupled.
The change in the title should communicate a change in responsibilities which requires different skillset:
Senior Engineer: hard skills (coding, troubleshooting, etc.)
Staff Engineer: soft skills (influence, leadership, negotiation, etc.)
Principal Engineer: business acumen (connecting profit to code, etc.)
There needs to be a way for companies to reward outcome without drastically changing the title. It’s totally fine to have Senior Developer 1, Senior Developer 2, Senior Engineering 3, … to signal the reward.
Coupling the pay bands to title is one of the most common career ladder pitfalls.
Those ladders fail to communicate that the expectations, responsibilities, and the toolbox of Staff Engineer is fundamentally different than that of a senior engineer. Without soft-skills the code machine is just a glorified Senior Engineer not a Staff Engineer.
Does a team need Staff Engineer? Not really.
There are cases when you can temporary have the Staff role at a team level:
When the Staff Engineer is new to the company, having a smaller scope allows smoother onboarding.
When there’s a new Engineering Manager in the team, they can use the help of a Staff Engineer to get hold of the tech
When the company is committed to confuse employees with no clarity in the career ladder.
4. The Right Hand anti-pattern
There are 100 ways to get this wrong and I haven’t seen a proper implementation in my career. The wording ("right hand") implies that the Staff has a borrowed or delegated authority.
But authority over what?
The tech.
The tech doesn't talk or listen. Staff MUST go through EM and PM to deliver an impact. That's what makes it tricky but also valuable.
Lack of mandate is one of the most common frustration among Staff Engineers and for good reason: it’s much easier to pull the mandate card to get sh*t done.
However, I believe that the lack of mandate is actually a perk because it forces you to resort to other tools:
Follow me leadership: show how it’s done instead of telling people what to do
Strategy: strategy is a powerful tool to build alignment around a common goal
Mentorship: good leaders bring the best out of people, great leaders create new leaders.
Open TODO: communicate your priorities to gain volunteers for your initiatives while demonstrating transparency
etc.
I call it “learning leadership the hard way” because once you learn how to lead without the mandate, you’re much less likely to abuse the mandate when you have it (e.g., if later in your career you decide to switch lanes and become a engineering manager).
When you're a manager, people respect you knowingly or unknowingly: your jokes are funnier, your concerns are taken seriously, even your f*rt smells good! 😆
As it turns out, people have a soft spot for the person who is in charge of their raise, promotion, vacation planning, etc. Who would have thought?
Staff Engineers don’t have mandate over people.
The lack of mandate unlocks quality feedback from the engineering community that’s much less likely to reach the managers on the reporting lines. As it turns out, people feel more connected with fellow engineers when their words are less likely to be used against them. Is that surprising? 😄
Recap
Archetypes should not be treated as job titles.
Breaking a role to multiple titles is bad both for the company (more bottlenecks) and employees (turning to one trick ponies).
The most effective Staff Engineers can act as any of those archetypes depending on the needs and situation.
Architect is not a full time job. Tech translator and tech governor are career dead-ends (unless you’re planning to spend all your career in broken organizations).
Avoid fake work like plague. Always trying to put what you do into the context of business value.
Change in the title communicates a change in responsibilities which requires a change in the toolbox to do the job.
Staff Engineer is responsible for the technology and its main potential is realized when that tech spans across teams.
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
The simplest way to support me is to like, subscribe and share this post.
If you really want to support me, you can consider a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections and my online book Reliability Engineering Mindset. You can get 20% off via this link. Your contribution, also funds my open source products like Service Level Calculator.
You can also invite your friends to gain free access.
And to those of you who support me already, thank you for sponsoring this content for the others. 🙌 If you have questions or feedback, or you want me to dig deeper into something, please let me know in the comments.
This reminds me how re-orgs love to shuffle titles and redraw org charts, thinking that changes the work. But if we don’t understand how people actually create impact beyond their boxes, we just move problems around. Leadership job is also about constantly realigning roles with REALITY.