Module 1: What the Job Actually Is

Where the Word “Staff” Comes From, and Why It Matters

Most engineers hear “staff engineer” and picture a senior engineer with a bigger title. That guess is wrong in a way that shapes the whole job, so start with the word itself.

The Military Origin

Alex Ewerlöf traces the title back to the military staff. A staff officer supports a commander with planning and analysis. The staff officer has no command authority. They do not give orders to the troops. They shape what the commander decides by doing the thinking the commander has no time for.

That is the job. A staff engineer plans, analyzes, and advises across an organization, and does it without a mandate over anyone. Ewerlöf’s phrase for it is leadership without mandate.

Reilly’s Version of the Same Idea

Tanya Reilly does not use the military analogy. She gets to the same place from the other direction. Chapter 1 of The Staff Engineer’s Path has a section titled “You’re Not a Manager, but You Are a Leader.” Her point is that companies used to reward their best engineers with management jobs, and treating management as the default path “doesn’t serve the industry well, or the engineer.” The staff track exists so that an engineer can lead through technical direction, mentorship, and big projects while keeping a technical role.

Put the two together and the definition writes itself. A staff engineer leads without managing because that is what the word has always meant.

Source: The Staff Engineer’s Path, Tanya Reilly, O’Reilly 2022.

Where the Impact Lands

Ewerlöf draws a three-layer model that makes the “without mandate” part concrete. Engineers impact the tech. Product managers impact the product. Engineering managers impact the engineers. A staff engineer impacts the tech across both people and product, and has direct authority over neither.

Your success gets measured at the organization level, not the team level. That is the shift that trips people up in their first year, and Module 4 comes back to it.

Every lesson that follows is about how you earn that trust, how you spend it, and how you get the title in the first place.

Senior vs Staff vs Principal: The Scope Line

Every company draws the line between senior and staff somewhere different. Only one of our sources is a company drawing its own line in public, so start there.

GitLab’s Line

GitLab’s handbook says a Staff engineer is “the foremost engineer within their group,” and a Principal engineer is the same thing “within their stage.” A group is a set of teams. A stage is a set of groups.

So the line is scope, not skill. A senior engineer owns problems inside a team. A staff engineer owns problems that span the teams in a group. A principal engineer owns problems that span groups.

The False Positives

Working across teams is necessary for staff. It is not sufficient. Alex Ewerlöf lists roles that cross team boundaries every day and are not automatically staff: application security, site reliability, platform engineering, integration engineering, tools engineering. Those roles serve many teams. A staff engineer sets direction for many teams. The difference is whether you are answering “how” for other people or answering “why.”

Reilly’s Three Questions

Tanya Reilly gives you a way to locate your own role without a handbook. Chapter 1 asks three questions. What is your scope, meaning the set of teams or systems you are responsible for. What shape is your role, meaning how much of your time goes to code, to projects, to advising. What is your primary focus, meaning the one problem you would drop everything else for.

She closes the chapter with a section on aligning on scope, shape, and focus with your manager, because the three answers you assume and the three answers your manager assumes are usually different.

Source: The Staff Engineer’s Path, ch. 1.

The Four Archetypes, With the People Who Fit Them

Will Larson interviewed staff engineers across the industry for staffeng.com and found that the job comes in four shapes. Most guides restate his list. This lesson keeps his names attached, because the names are the evidence.

Source: Staff archetypes, Will Larson.

What Each One Costs

Larson’s rule of thumb for the Tech Lead: “the team’s impact grows as the Tech Lead’s coding blocks shrink.” His line on Architects is that they “maintain intimate understanding of business needs, users’ goals, and relevant technical constraints.” Not a whiteboard job.

The Solver has a cost he names directly: solvers “stop working on problems once they’re contained, which can create the feeling of transience.” And the Right Hand’s problems “are never purely technical.” Michelle Bu, as Payments Products Tech Lead at Stripe, worked directly with the Chief Product Officer.

The Warning

Alex Ewerlöf flags what happens when companies read this list too literally. They turn archetypes into job titles, post a “Solver” opening, and end up with classification fights instead of staff engineers.

He also names the failure mode for the Architect shape: the toxic preconception that architects design in isolation. Larson agrees, and Ewerlöf quotes him on it. Architects earn their authority by “demonstrating consistently good judgment,” which requires staying close to the code.

Source: Introduction to the role of Staff, Alex Ewerlöf.

How to Choose

Tanya Reilly’s “what shape is your role” question from lesson 1.2 is the tool here. The archetype your company needs depends on its size and its debt. The archetype you want depends on what work gives you energy. Larson’s interviews show most staff engineers blend two shapes. Pick the primary one on purpose, because the promotion case in Module 3 is easier to write when the shape is clear.

One thing to skip: several articles that rank on “how to become a staff engineer” repeat these four archetypes without adding anything. Read Larson.

What Staff Engineers Do All Week

The archetypes tell you the shape. They do not tell you what Tuesday looks like. For that, put Larson’s categories next to GitLab’s task list.

Larson’s Five Categories

From his interviews, Will Larson groups staff work into five buckets. Setting technical direction, which means advocating for a technology strategy that serves the organization over your own preferences. Mentorship and sponsorship, which means growing engineers and then advocating for them. Providing engineering perspective, which means being in the room when a decision needs technical context. Exploration, which means taking on ambiguous problems that normal planning cannot address. And being glue, the coordination work that keeps teams shipping. Larson credits Tanya Reilly for that last term.

GitLab’s Task List, Sorted Into Larson’s Buckets

GitLab’s handbook gives newly promoted staff engineers a list of tactical initiatives. Here it is, sorted into Larson’s buckets.

Sources: Will Larson and GitLab Handbook.

What the Mapping Shows

Every one of GitLab’s 18 items fits one of Larson’s five buckets. That is the evidence that the buckets are real and not one author’s taxonomy. It also shows the weighting. Glue and technical direction take the most items.

Coding does not appear on the list at all, which is a tension lesson 2.5 deals with head on.