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.

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.

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 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. Nevertheless, the admin assistant is not supposed to take over the EM’s people accountability.

Neither is the Staff Engineer supposed to take over EM’s technical accountability.

Previously we’ve argued that hiring a Staff Engineer to take over the technical aspects is an anti-pattern. The 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.

How can engineer leaders stay technical?

So what about this?

The proper answer is somewhere in between: Staff Engineer could be useful when:

• The technical load is beyond the capacity of EM

• A clear accountability can be established for a subset of technical load

Please don’t read too much into this. 🙂 People are different. Products are different. And people change over time.

The Staff Engineer is 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 two roles accountable for tech isn’t a great idea.

There are cases when a Staff Engineer may focus on one team. For example:

• Legacy tech stack with a steep learning curve when the EM is new

• 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 level Staff Engineer can be a temporary positions even though we are breaking one role (EM) to multiple titles (EM + Staff):

Breaking a role to multiple titles

Staff Engineer for a system spread across multiple teams

In his seminal essay Will Larson, identified 4 archetypes for Staff Engineers:

1. Tech lead

2. Architect

3. Solver

4. 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.

Introduction to the role of Staff Engineer

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 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.

There are other ways to reduce the span of tech to one team though deliberate organizational architecture. We’ve discussed one powerful alternative in Kebab vs Cake model using consumer journeys:

Kebab vs Cake organization

Staff Engineers should have clear accountability over a system. That means they expose 3 elements of ownership:

1. Knowledge: They know the tech stack, the product problem and can speak fluently about it as well as code when needed

2. Mandate: They have a say in how the tech evolves and is maintained.

3. 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.

Cargo culting

I didn’t write some universal laws of physics. You know what is best for your particular technology, product, operations, and people.

T-POP

If you have counter-arguments, feedback, corrections, or questions, let me know in the comments down below. 🙏

---

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.