Overview: The Staff Engineer Role
selt staff-engineering archetypes career ic-track
Status: Notes complete
Overview
The Overview section of “Staff Engineer” covers three related questions that practitioners ask before anything else: What are the different shapes this role takes? What do people in the role actually spend their time on? And does the title itself matter, or is it just vanity? Larson addresses these across three sub-sections: the four archetypes, the five activities, and the case for the title. Together they provide the vocabulary and mental models that the rest of the book builds on.
The Dual-Track Career Ladder
Most tech companies offer two paths above Senior Engineer. The first is the engineering management track (EM → Senior EM → Director → VP → CTO). The second is the individual contributor technical track (Senior → Staff → Principal → Distinguished → Fellow). Larson uses the term Staff-plus throughout the book as an umbrella for everything at and above the Staff Engineer title.
The existence of this dual track is a relatively recent development. For most of software’s history, the only path to advancement was management. The IC track was created to retain engineers who were highly effective technically but did not want to manage people, and to fill a genuine organizational need: someone with broad technical context who can make cross-team decisions without pulling a manager away from people leadership.
Why the distinction matters: The skills, behaviors, and success criteria diverge significantly at this level. Managers succeed by growing their teams; Staff-plus engineers succeed by improving the technical work of the whole organization. The failure modes are also different — a manager who struggles with delegation fails differently than a Staff engineer who struggles with scope or visibility.
Typical title progression (varies by company):
- Staff Engineer — first title above Senior; often paired with influencing a single team or small group
- Principal Engineer — typically scoped to a department or major product area
- Distinguished Engineer — organization-wide technical authority; rare
- Fellow — the most senior individual contributor title; company-wide or industry-level scope
Four Archetypes
One of the book’s most widely-cited contributions is Larson’s taxonomy of four distinct shapes the Staff engineer role takes. Understanding which archetype fits your situation matters for three reasons: it helps you explain your role to others, it helps you identify what skills to develop, and it helps you evaluate whether a given company or team is a good fit.
| Archetype | Core Activity | Natural Home | Typical Scope | Relative Frequency |
|---|---|---|---|---|
| Tech Lead | Guides a team’s technical approach and execution | Any org with cross-functional teams | 1 team to ~3 teams | Most common (~1 per 8 engineers) |
| Architect | Sets direction and quality for a critical technical domain | Large orgs with complex multi-team systems | A domain that spans teams | Common in large orgs |
| Solver | Digs into the hardest/most ambiguous problems | Orgs with many unsolved critical problems | Wherever the biggest problem is | Moderate; requires specific org culture |
| Right Hand | Extends an executive’s attention and authority | Large or fast-growing orgs needing leadership bandwidth | Org-wide, through an exec | Rare |
Tech Lead
The Tech Lead is the most common Staff-plus archetype. They work closely with one or more teams (typically 1–3), partnering with an engineering manager (EM) or product manager (PM) to guide the team’s technical decisions while the EM handles people issues. The relationship is a partnership: the Tech Lead owns technical direction; the EM owns team health and career development.
What the calendar looks like: Significant time in team meetings, code review, technical design discussions, and 1:1s with team members. Some time writing design docs and RFCs. Less time in large cross-org meetings than other archetypes.
Key behaviors:
- Runs technical design reviews and makes or ratifies key technical decisions
- Translates product requirements into technical plans and communicates back to product what is and isn’t feasible
- Identifies and mitigates technical risks before they become incidents
- Teaches through doing — pairs, reviews, and models good engineering practices
Pitfall: Tech Leads can get pulled too far into implementation and lose the staff-level perspective. The diagnostic question is: “Are there important technical decisions happening that no one is making because I’m too deep in the code?”
Story subjects who exemplify this: Many of Larson’s interviewees began their Staff journey as Tech Leads — it is the natural first Staff role for most engineers.
Distinction from Tech Lead as job title: Some companies have “Tech Lead” as a separate (often non-Staff) title. Larson is using “Tech Lead” as an archetype label, not a title. An engineer with the title “Staff Engineer” who guides a team’s execution is operating as a Tech Lead archetype.
Architect
The Architect owns technical direction and quality within a critical technical domain. Unlike the Tech Lead, who is embedded in a team, the Architect’s focus is on a domain that spans multiple teams — the API layer, the data platform, the authentication system, the mobile infrastructure.
What the calendar looks like: Heavy on stakeholder meetings (collecting requirements and concerns from teams that depend on the domain), writing strategy documents, reviewing designs across teams for consistency with the domain’s standards, and occasionally deep technical work to stay current.
Key behaviors:
- Defines the interfaces, data contracts, and constraints that teams building within the domain must follow
- Writes the architectural vision documents that explain the direction for the next 2–3 years
- Identifies when the domain is accruing technical debt fast enough to threaten future velocity
- Communicates technical constraints up to leadership in terms of business risk
Required conditions: The Architect archetype works well only when there is a genuine technical domain complex enough to justify dedicated ownership, and when the organization has enough structure to honor the Architect’s authority. In small organizations or flat hierarchies, the Architect role often collapses into Tech Lead.
Risk: Architects who lose touch with implementation can make decisions that are theoretically elegant but practically expensive. The best Architects keep at least one hand in the code.
Solver
The Solver is brought in to resolve the problems that nobody else can or will. They may spend months in a single complex area (a legacy system that needs untangling, a performance problem with subtle root causes, an architectural mismatch that has compounded for years) or they may bounce between multiple critical problems across the org.
What the calendar looks like: Long stretches of deep independent work, punctuated by status updates to sponsors and stakeholders. Less recurring meeting overhead than other archetypes — the Solver’s value is their ability to think through hard problems without distraction.
Key behaviors:
- Picks up problems that have been resisted, deprioritized, or attempted and failed before
- Applies both technical depth and systems thinking to understand root causes, not just symptoms
- Documents findings thoroughly so the solution doesn’t require their ongoing presence
- Knows when to escalate a structural or organizational problem that cannot be solved technically
Required conditions: The Solver archetype needs an organization that has genuinely hard problems and the maturity to identify them and route them appropriately. Without this, Solvers become “the person who gets assigned random hard things” — which can be intellectually interesting but organizationally marginalizing.
Risk: Solvers can become isolated. Because they work on unique problems independently, they may not build the organizational relationships that create career momentum or sponsorship opportunities.
Right Hand
The Right Hand is the rarest archetype. They act as a senior technical advisor and surrogate for an executive — typically a VP of Engineering or CTO — extending that leader’s capacity to set direction, make decisions, and identify problems at scale.
What the calendar looks like: Mirrors their executive’s interests — attending the meetings the exec can’t attend, diving into technical areas that have bubbled up as risks, synthesizing information from across the org, and writing communications on behalf of or alongside the exec.
Key behaviors:
- Acts with the exec’s authority on technical matters, requiring exceptional judgment about when to decide vs. escalate
- Synthesizes large amounts of technical and organizational information into clear recommendations
- Builds relationships across the org that give the exec better signal than they’d have alone
- Handles sensitive technical situations (incident post-mortems, architectural disagreements between teams) with diplomacy
Required conditions: The Right Hand only works when there is deep mutual trust between the engineer and the executive. It also requires a leadership team that respects the Right Hand’s authority. Without both, the role has no mandate.
Risk: The Right Hand’s success is tightly coupled to their executive sponsor’s. If the exec leaves or their priorities shift, the Right Hand role can evaporate. The archetype also offers little direct execution — which can be unsatisfying for engineers who want to build things.
What Staff Engineers Actually Do
Beyond the archetypes — which describe shape — there are five activities that Larson identifies as the core substance of Staff-plus work across all archetypes. These are not a job description; they are descriptive of what actually fills the time.
1. Setting Technical Direction
Staff engineers are responsible for their technical domain’s long-term health. The metaphor Larson uses is the Lorax: just as the Lorax speaks for the trees, the Staff engineer speaks for the long-term health of the codebase and architecture, even when short-term pressure to ship pushes in the opposite direction.
In practice this means:
- Writing and maintaining technical vision documents (“what good looks like in 3 years”)
- Pushing back on decisions that optimize for speed at the cost of long-term maintainability
- Identifying architectural drift before it compounds
- Making the case for investment in foundations (observability, test coverage, documentation) that don’t show up in product roadmaps
Key distinction: Setting direction is different from making every decision. A Staff engineer who tries to own every technical decision becomes a bottleneck. The goal is to set the frame — the standards, the vision, the principles — so that teams make good decisions independently.
2. Mentorship and Sponsorship
Staff engineers have a responsibility to grow the engineers around them, but “mentorship” is only half of it. Larson draws a sharp distinction:
Mentorship is sharing knowledge, advice, and experience. It is a largely private relationship. The mentor helps the mentee develop skills and navigate challenges. This is valuable and necessary.
Sponsorship is actively using your credibility and influence to advocate for someone. A sponsor says “you should have this person in your next design review” or “I think she’s ready for promotion and here’s why” in rooms the mentee is not in. Sponsorship requires spending political capital.
The gap between mentorship and sponsorship is significant: most senior engineers are willing to mentor but are reluctant to sponsor. Larson argues that sponsorship is more valuable and that Staff engineers should consciously practice it, particularly for engineers from underrepresented groups who are less likely to have sponsors organically.
Practical note: You cannot sponsor people you don’t know well enough to vouch for. Building the relationships required to sponsor effectively is itself part of the job.
3. Providing Engineering Perspective
There are rooms in every organization where important decisions get made — budget allocations, roadmap prioritization, architectural direction, hiring plans. These decisions benefit from technical input, but if no one in the room has technical judgment, purely business and product considerations dominate.
Staff engineers earn their way into these rooms by demonstrating that their technical perspective improves decisions — not just flags problems. The value proposition is: “If I’m in this meeting, the outcome will be better for the organization.” This is different from wanting to be informed or wanting influence for its own sake.
How it works in practice: Staff engineers attend leadership syncs, product strategy sessions, and planning cycles. They don’t attend to veto or to push a technical agenda; they attend to translate between technical realities and business priorities in both directions.
4. Exploration
Some of the most valuable Staff-plus work is explicitly unbounded and risky. Larson calls this exploration: taking on problems that are too ill-defined, too risky, or too early-stage to hand to a team with a roadmap.
The hill-climbing metaphor applies here: sometimes an organization needs to know whether a new approach (a new database technology, a new architectural pattern, a new platform) is worth a serious investment. That question can only be answered by someone willing to go explore the terrain — prototype, spike, evaluate — without the pressure of a ship date.
Exploration work is often invisible from the outside and rarely produces a shippable artifact on the first attempt. It requires both technical depth (to evaluate options rigorously) and tolerance for ambiguity (to work without a clear success definition).
5. Being Glue
Tanya Reilly coined the term glue work for the category of engineering activities that are essential to the team’s success but not reflected in commits, PRs, or shipped features. This includes: writing runbooks, onboarding new engineers, coordinating cross-team dependencies, updating outdated documentation, preparing meeting agendas, and following up on action items.
Larson includes glue as part of the Staff engineer’s role with an important nuance: glue work is valuable, but it must be paired with technical leadership work. A Staff engineer who does only glue — no technical direction, no sponsorship, no exploration — is not operating at the level. And junior engineers who do only glue (often because the team implicitly relies on them for coordination) can become stalled in their careers because their technical contributions are invisible.
The Staff engineer’s role: Do enough glue to keep the organization functioning, be explicit about what you’re doing and why, and use your position to ensure that glue work is distributed fairly and not concentrated on individuals from underrepresented groups.
Does the Title Even Matter?
Larson directly addresses the question many engineers ask: “Can’t I just do Staff-level work and get the impact without worrying about the title?” His answer is yes — and also, the title matters in several concrete ways.
1. Compensation
The most direct: most companies have salary bands tied to levels. Engineers at L4 (Senior) are paid within one band; engineers at L5 (Staff) are paid within a higher band. The bands often do not overlap significantly. Larson cites interviews where engineers discovered they were being paid tens of thousands of dollars less than peers doing the same work simply because they hadn’t been promoted. The title gates the compensation.
2. Access to Interesting Work
Certain projects, certain decisions, and certain working groups are effectively title-gated. A Staff engineer is assumed to have the judgment to work on architectural decisions that affect many teams. A Senior engineer — even a very strong one — may not be included in those discussions because the implicit expectation is that Staff-plus titles signal sufficient judgment and authority to participate. This is not always fair, but it is real.
3. Access to the Room
Related but distinct: some rooms (leadership reviews, architecture committees, planning sessions with executives) require sufficient organizational credibility to enter and remain relevant. A Staff title signals to non-engineers in those rooms (product leaders, executives, business stakeholders) that the engineer’s technical input carries organizational weight. Without it, the same input may be discounted or ignored.
Counterarguments Larson Acknowledges
“Impact matters more than the title.” True in the long run, but the title creates the conditions that make high-impact work accessible. The argument that you should focus purely on impact and ignore the title is most often made by people who already have the title, or by people in organizations where the title doesn’t matter (rare).
“I don’t want to play political games.” The promotion and visibility mechanics required to get a Staff title do involve organizational navigation, not purely technical merit. Larson’s response: those mechanics exist regardless of whether you engage with them. Not engaging doesn’t remove the politics; it just removes you from influencing outcomes.
“My company doesn’t have Staff engineers.” Some companies, especially smaller ones, don’t distinguish above Senior. Larson addresses this in Part III — these companies are valid choices, but it is worth understanding the trade-offs before assuming the title doesn’t exist anywhere or doesn’t matter.
Key Takeaways
- Staff-plus is an umbrella term for Staff, Principal, Distinguished, and Fellow — all titles above Senior on the IC track. The dual-track ladder (management vs. IC) is the structural context for these roles.
- Four archetypes describe how the role manifests: Tech Lead (most common, team-embedded), Architect (domain-scoped), Solver (problem-scoped), Right Hand (exec-adjacent). Each requires different skills and suits different organizational contexts.
- The Tech Lead archetype is not the same as the “Tech Lead” job title — Larson uses it to describe a way of operating, not a specific title.
- Five activities describe the actual work: setting technical direction, mentorship/sponsorship, providing engineering perspective, exploration, and being glue. These cut across all four archetypes.
- Sponsorship is more valuable and rarer than mentorship — it requires using your credibility actively, not just sharing knowledge.
- Setting direction means setting the frame, not making every decision — the goal is for teams to make good decisions independently, not to become a bottleneck.
- Being glue is necessary but not sufficient — Staff engineers must pair coordination work with visible technical leadership or they risk being trapped at the glue level.
- The title matters for three concrete reasons: compensation bands, access to interesting work, and credibility in decision-making rooms.
- Exploration is legitimate Staff work — ill-defined, risky, early-stage evaluation is valuable even when it produces no shippable artifact.
- The “right” archetype is context-dependent — the best Staff engineers recognize which archetype fits the current organizational need and can shift as the org changes.
Related Resources
- sec02-work-on-what-matters — How to prioritize as a Staff engineer; snacking, preening, and chasing ghosts
- sec03-writing-engineering-strategy — How setting technical direction works in practice
- sec08-create-space-for-others — Sponsorship and mentorship mechanics in depth
- sec11-promotion-packets — Getting the Staff title where you are
- ch01-what-would-you-say — Tanya Reilly’s treatment of the same four archetypes in TSEP, with additional emphasis on scope and shape
Last Updated: 2026-05-30