Chapter 1: What Would You Say You Do Here?
tsep staff-engineer role-definition scope archetypes four-disciplines
Status: Notes complete
Overview
Chapter 1 answers the deceptively hard question: what does a staff engineer actually do? Unlike an engineering manager (manages people) or a senior engineer (writes code with expertise), the staff engineer role is hard to define because it varies enormously across organizations and situations. The chapter arms readers with mental models to define, evaluate, and explain their own role.
The core argument is that a staff engineer’s job can be understood along three dimensions: scope (how wide is your influence?), shape (what mix of activities fills your time?), and primary focus (which of the four archetypes describes you?). Getting these three aligned with organizational expectations is the key to thriving in the role.
Core Concepts
Staff engineer: Not a manager, but a leader. Works at the intersection of technical depth and organizational breadth. Autonomous, sets technical direction, and communicates effectively up and across.
Scope: The organizational width of a staff engineer’s work. Measured by what breaks if you stop doing your job — your team only, your group of teams, your department, or the whole engineering organization.
Shape: The time allocation across activities — coding, writing docs, reviewing, meeting, mentoring, unblocking. There is no single “correct” shape; it varies by role, organization, and moment.
Primary focus: Which of Will Larson’s four archetypes (Tech Lead, Architect, Solver, Right Hand) most describes your current role.
Four disciplines (Yonatan Zunger): The four domains that staff-level technical work spans — core technical skills, product management, project management, and people management. Staff engineers are not managers, but they exercise non-management versions of all four.
Role description: A written document that aligns expectations between a staff engineer and their organization about scope, shape, and focus.
Why Staff Engineers Exist
Organizations need someone who:
- Has broad technical context (knows how systems interact across team boundaries)
- Can make decisions that no single team should own unilaterally
- Sets and maintains technical direction for a large group
- Is not a manager, so is not pulled into people-management activities
Five axioms of the staff engineer role:
| Axiom | Meaning |
|---|---|
| Not a manager, but still a leader | Authority comes from expertise and trust, not org chart |
| Technical role | Must maintain genuine technical depth — not just soft skills |
| Operates with autonomy | Does not wait for permission to act |
| Sets technical direction | Creates and communicates a path forward |
| Communicates well | Can explain things at multiple levels to multiple audiences |
Four Disciplines (Zunger)
Yonatan Zunger argues that all complex technical leadership involves four disciplines, even though staff engineers don’t formally manage people:
- Core technical skills: Deep knowledge of systems, ability to evaluate technical options, designing at scale
- Product management: Understanding what users need, prioritizing work, navigating trade-offs between what’s possible and what’s valuable
- Project management: Keeping work moving, managing dependencies, scoping, estimating, tracking
- People management: Helping individuals grow, handling interpersonal issues, ensuring psychological safety — even without formal authority
The key insight is that staff engineers must develop skills in all four even though they only formally “own” the first. The better they get at the other three, the more effective they become.
Four Archetypes (Will Larson)
Most staff engineers fit primarily into one of four archetypes, though they may shift between them over time:
| Archetype | Description | Context |
|---|---|---|
| Tech Lead | Leads a team or cluster of teams; anchors technical decisions; deeply embedded in day-to-day work | Most common; paired with a product/engineering manager |
| Architect | Owns technical direction for a broad domain; defines interfaces and constraints that others build within | Best in large orgs with complex multi-team systems |
| Solver | Moves from crisis to crisis; parachutes into difficult problems no one else can solve | Works well in orgs with many hard problems; can be isolating |
| Right Hand | Acts as a senior technical advisor to a leader (VP/CTO); extends their reach and bandwidth | Rare; requires total trust and comfort with ambiguity |
No archetype is better than another. The right archetype depends on:
- Your org’s needs
- Your personal strengths
- The type of work you want to do
Getting Scope, Shape, and Focus Right
Three misalignments to watch for:
Scope too narrow: You’re doing senior engineer work, not staff engineer work. Signs: no one asks your opinion on projects outside your team; your influence ends at your team boundary; you’re spending all your time on implementation.
Scope too broad: You’re spread too thin. Signs: you’ve stopped going deep on anything; you’re called into every meeting but add little; you feel like a generalist who doesn’t know enough about anything.
Shape mismatch: The work filling your calendar doesn’t match what the org needs or what you value. A “Tech Lead” expected to be in code all day will clash with an org that needs strategic vision from them.
The alignment question to ask regularly: “What does my organization need from me that only a staff engineer can provide?”
Writing a Role Description
The chapter recommends writing a short (1–2 page) document that answers:
- What does your organization need from a staff engineer in this role?
- What is your scope?
- What does your week actually look like (shape)?
- What are the 3–5 most important things you are personally accountable for?
- What are you explicitly not responsible for?
This document is most useful when shared and discussed with your manager. It surfaces misalignments before they become problems and gives you something concrete to point to when the role drifts.
Key Takeaways
- Staff engineering is defined by scope, shape, and primary focus — all three need to be aligned with organizational expectations.
- Four archetypes (Larson) describe how the role manifests: Tech Lead, Architect, Solver, Right Hand.
- The role requires four disciplines (Zunger): technical skills, product management, project management, and people management — even without formal management authority.
- Scope too narrow → you’re not doing staff work. Scope too broad → you’re ineffective.
- The most important diagnostic question: “What does my org need that only a staff engineer can provide?”
- Writing a role description forces alignment between your expectations and your manager’s.
- The role changes over time — periodically re-examine all three dimensions.
Related Resources
- ch00-introduction — The Three Pillars that define staff engineering
- ch04-finite-time — How to manage the time required to fill the role
- ch09-whats-next — Career evaluation and path-planning as a staff engineer