Staff Engineer vs Engineering Manager
#
Excerpt #
When do you need a Staff Engineers? What’s the accountability model with or without? What’s the difference between Staff Engineer and Engineering Manager? What should the staff engineer be accountable for? These are the questions that this article tries to answer with lots of colorful illustrations and examples.
Staff Engineer vs Engineering Manager #
When do you need a Staff Engineers? What’s the accountability model with or without? #
These are actual questions Iâve got in the past few years:
An EM: I donât want to deal with people anymore. I want to focus on the tech. Is Staff Engineering for me?
A Senior EM responsible for multiple teams: I have too much admin work. Should I hire a Staff Engineer to take over the technical part of my job?
A Staff Engineer at a team without an EM: Iâm practically acting as the team manager and like it. Should I just switch lanes to become an EM?
A Senior Engineer frustrated with Ivory Tower Staff Engineers: what is the accountability of the Staff Engineers? They act like retired devs.
A new Staff Engineer: What are dotted reporting lines? I have my line manager, why should I care about other managers?
So I thought itâs time to settle all these questions once and for all.
đ€đ« Note: No AI is used to generate this content. This essay is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs.
[

]( https://blog.alexewerlof.com/p/introduction-to-the-role-of-staff)
When do you need a Staff Engineer? #
Letâs step back and build a model.
Engineers create and maintain the tech. But the tech doesnât exist in vacuum. Itâs a solution to a problem. The problem is defined by the product.
[

The product offers a service to the consumers, whether they are end users or internal consumers. It solves a problem for someone. It can be:
An app thatâs used to measure running distance and sharing it with other runners
A website for booking hotels
An infrastructure platform thatâs used by other teams
A time-report system
etc.
The engineers usually work in a team led by an EM.
[

The Engineering Manager is accountable for the engineers as well as the technical artifacts they produce:
[

When the team is large or the tech is too complex (or both), the EM may not have enough bandwidth to do justice for both their people and technical accountability:
[

To increase their bandwidth, EMâs are faced with a choice:
Delegate admin work: To optimize the HR processes and tooling or hire an admin assistant to lift some of the people management load from their shoulder
Delegate technical load: To hire a Staff Engineer to lift some of the technical load from their shoulder.
You may argue if having a dedicated admin assistant is justified at a team level, but I have seen one admin assistant shared by multiple teams. AI can cover some of the mechanical activities like scheduling events, answering admin questions, and gathering continuous feedback. Good HR tooling and processes can reduce the admin load as well.
Nonetheless, the admin assistant or AI is not supposed to take over the EMâs people accountability like building a good team, mentorship, performance review, hiring, etc.
Previously weâve argued that hiring a Staff Engineer to take over the technical aspects of Engineering Management is an anti-pattern.
Particularly, Staff is not supposed to act as a translation layer between the tech and engineers for the EM:
[

Engineering manager needs to be technical and we have covered some ways to keep the technical skills sharp here.
[

]( https://blog.alexewerlof.com/p/how-can-engineer-leaders-stay-technical)
Staff Engineer could be useful when:
The technical load is beyond the capacity of EM. For example:
Legacy tech that requires intense babysitting/migration
Overly complex solution that spans across teams or requires deep technical knowledge
Simply because the EM isnât technical (itâs an anti-pattern but they do exist)
A clear accountability can be established for a subset of technical load
Organizations that have Staff, should hold them accountable for the technology, not people:
[

Please donât read too much into this. đ People are different. Products are different. And both change over time.
Thereâs a small but important difference between responsibility and accountability that weâve covered in a separate article:
[

]( https://blog.alexewerlof.com/p/accountable-vs-responsible)
The Staff Engineer should be deeper in the technology and have higher technical literacy tied to an accountability. The lack of people responsibility opens up their schedule to be more invested in tech. But the Engineering Manager is not supposed to be completely off-hand either.
So we went from this:
[

To this:
[

Now I have some bad news. Having Staff Engineer at the team level is an overkill. As weâll discuss in a minute, the real value of the Staff Engineer comes from operating across teams. Besides, having two roles accountable for tech can create confusion and breaking one role into multiple titles:
[

]( https://blog.alexewerlof.com/p/breaking-role-to-titles)
However, there are cases when a Staff Engineer may operate in the scope of one team. For example:
Legacy tech stack with a steep learning curve when the EM is new
When onboarding a new Staff Engineer (starting from a smaller scope)
Too much tech debt piled up and hurting the tech health metrics
Complexity getting in the way of maintaining the tech
In all those examples, team-scoped Staff Engineer can be a temporary position.
Staff Engineer for a system spread across multiple teams #
In his seminal essay Will Larson, identified 4 archetypes for Staff Engineers:
Tech lead
Architect
Solver
Right hand
Whatâs shown in the diagram above is a Tech Lead operating within one team. Calling that role a Staff Engineer is a bit of a stretch.
[

]( https://blog.alexewerlof.com/p/introduction-to-the-role-of-staff)
Thatâs because most of the value of the Staff Engineer comes from operating across multiple teams:
[

Often, the tech that is owned by one team is just a piece of the puzzle. The larger system or domain may be spread across multiple teams or at least has tight dependencies across the org.
In this scenario it makes sense to have a dedicated role (Staff Engineer) for the entire system regardless of which team owns which piece of it.
Hereâs the catch: the âtechâ doesnât talk or listen:
[

The tech doesnât exist in vacuum!
[

For Staff engineers to deliver their true value, they have to go through both people (engineers) and product:
[

And thatâs why Staff Engineers have all those âdotted reporting linesâ (the unofficial but critical collaborations and commitments across the org):
[

Those with the kin eyes may ask why the arrow is pointing from the Staff to âlowerâ positions (in the career ladder). The answer is two-fold:
Good leadership is about collaboration not authority. See it as Staff going to a team-level EM or PM and asking for favors in a way that fits the engineers and product roadmap, not demanding to lift the state of tech in isolation
Staff Engineer is an IC (individual contributor) and by definition does not have any direct reports. If youâre lucky to have a sync channel with EM/PM, please donât waste it in regular report, but instead turn it to a 2-way dialogue about the state of tech (status quo) and where the tech needs to be to solve the emerging product problems (vision) as well as cohesive actions to take us there (organizational tech strategy).
All these reporting lines can be overwhelming. One tool to align product teams across the org is a strategy document:
[

]( https://blog.alexewerlof.com/p/strategy-basics)
There are other ways to reduce the span of tech to one team through deliberate organizational architecture. Weâve discussed one powerful alternative in Kebab vs Cake model using consumer journeys:
[

]( https://blog.alexewerlof.com/p/kebab-vs-cake)
Staff Engineers should have clear accountability over a system. That means they expose 3 elements of ownership:
Knowledge: They know the tech stack, the product problem and can speak fluently about it as well as code when needed
Mandate: They have a say in how the tech evolves and is maintained.
Responsibility: They are held accountable for the health of the tech (e.g. incidents, tech debt, documentation, tech defragmentation, etc.)
[

As we discussed before, Staff Engineer is not a pure technical role and heavily relies on soft-skills to influence the technical organization.
[

Funny enough, focusing too much on soft-skills is one of the most dangerous pitfalls ahead of Staff Engineers. It turns them to Ivory Tower Architects:
[

Conclusion #
Not all organizations need Staff Engineers, especially when:
EMs are technical enough to manage their teamâs tech
Tech stack is healthy enough that doesnât need a dedicated technical steward
The engineering organization is mature enough to find the best way forward for the system they collectively own without the need for a dedicated owner
For orgs that have Staff Engineers, they should clarify the technical ownership and hold the Staff Engineer accountable for it
Ivory Tower Architect is bad
Breaking a role to multiple titles is inefficient
Non-technical EM is inefficient
And just like any essay by some random person on the internet, please please please use your best judgement and donât get stuck in cargo culting.
[

]( https://blog.alexewerlof.com/p/cargo-culting)
I didnât write some universal laws of physics. You know what is best for your particular technology, product, operations, and people.
[

]( https://blog.alexewerlof.com/p/t-pop)
If you have counter-arguments, feedback, corrections, or questions, let me know in the comments down below. đ
If you find this post insightful, please share it in your circles to inspire others. đ
You can also share your thoughts and comments on HackerNews.
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.
You can support my work by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.
Subscribe to Alex Ewerlöf Notes #
Launched 2 years ago
Technical Leadership, Reliability Engineering, Growth
