Staff Engineer Ladder
This ladder crystallizes how we evaluate Staff Engineer performance. It is designed to be used alongside the role definition, responsibilities, and behavioral descriptions in the rest of this section — not as a replacement for them.
The rubric is organized around the six core responsibility areas. For each, we describe three proficiency levels: Developing, Performing, and Excelling. These levels are not career stages — they describe how fully a Staff Engineer has grown into a particular dimension of the role at a given point in time. It is normal and expected to be at different levels across different dimensions.
Further Reading
The behavioral indicators in this ladder are informed by the frameworks in Larson’s Staff Engineer and Reilly’s The Staff Engineer’s Path. The performance management structure — career ladders as behavioral descriptions, multi-dimensional assessment, calibration-based review cycles — draws on Larson’s An Elegant Puzzle, Chapter 6.
How to Use This Ladder
This rubric is intended for two audiences: Staff Engineers doing self-assessment, and managers conducting performance conversations. A few ground rules for both:
- No one excels at everything. A Staff Engineer who is Performing across most dimensions and Excelling in one or two is doing the role very well. The goal is not a row of “Excelling” marks — it is honest calibration that drives growth.
- Developing is not failing. It means a dimension needs deliberate attention. Every Staff Engineer will have areas where they are still growing into the role, especially in the first year or two.
- Context matters. A Staff Engineer embedded deep in a single team will naturally have a different profile than one operating across an entire platform. Evaluate against the scope of the role and the archetype that best fits the engineer’s current context, not a universal template.
- Look for patterns, not moments. A single great design review does not make someone Excelling at quality. Consistent behavior over a review cycle is what counts.
1. Technical Direction
| Level | Behavioral Indicators |
|---|---|
| Developing | Reacts to technical direction gaps when they become obvious problems. Can articulate risks in their immediate area when asked, but doesn’t proactively surface them. Participates in strategy discussions but rarely initiates them. |
| Performing | Actively monitors the technical direction of their domain. Knows the top architectural risks at any given time without being prompted. Initiates strategy discussions, writes direction documents that are specific, opinionated, and show their work, and ensures decisions get made and recorded. Engages the right people before a direction hardens. |
| Excelling | Shapes technical direction beyond their immediate domain. Identifies strategic risks and opportunities that others haven’t seen yet. Builds frameworks and processes that help other engineers set direction in their own areas. Produces technical vision that synthesizes multiple strategies into a coherent long-term view. Their judgment on technical direction is actively sought by leadership. |
2. Engineering Principles
| Level | Behavioral Indicators |
|---|---|
| Developing | Knows the engineering principles and follows them in their own work. Occasionally notices principle violations in reviews but doesn’t consistently engage. May default to enforcement (“this violates principle X”) rather than dialogue. |
| Performing | Consistently engages when they see decisions drifting from principles — in PRs, design docs, and architectural choices. Does so through conversation, not policing. Understands when a principle should bend and brings those cases to the right forum. Actively participates in evolving the principles through RFC processes. |
| Excelling | Acts as a cultural steward of the principles. Their engagement with principle violations is a model others learn from. Identifies when principles themselves need to evolve and drives that evolution. Engineers across teams point to their reviews as examples of how to apply principles well. |
3. Quality Bar
| Level | Behavioral Indicators |
|---|---|
| Developing | Does thorough code and design reviews, but feedback tends toward correctness rather than growth. Reviews are accurate but may not transfer judgment to the author. May focus on surface-level quality without addressing systemic patterns. |
| Performing | Reviews consistently leave the author better than they were before. Feedback is specific, constructive, and explains the “why” behind requested changes. Their design docs serve as references for what “good” looks like. Identifies and addresses quality patterns, not just individual issues. |
| Excelling | Has measurably raised the quality culture in their area. Engineers actively seek their reviews because they learn from them. Creates tooling, templates, or practices that scale quality beyond their personal review bandwidth. The quality bar in teams they touch is visibly higher than it was before they arrived. |
4. Multiplying Others
| Level | Behavioral Indicators |
|---|---|
| Developing | Provides mentorship when asked and is helpful in pairing sessions. Supports engineers who come to them, but doesn’t proactively seek out opportunities to grow others. Impact on others’ growth is mostly incidental rather than intentional. May take on hard problems themselves when they could have been growth opportunities for others. |
| Performing | Actively identifies engineers who are ready for growth and creates opportunities for them. Distinguishes between mentorship and sponsorship, and does both. Advocates for others in forums where they are not present. Consciously creates space — choosing when to step back so others can lead. Can point to specific engineers whose trajectory changed because of their deliberate investment. |
| Excelling | Has a track record of engineers who have grown significantly under their influence — promotions, expanded scope, increased confidence. Builds systems and practices that multiply others even when they’re not personally involved. Is recognized across teams as someone who develops people, not just code. Their sponsorship carries weight because it’s backed by a history of good judgment about people. |
5. Connecting Information
| Level | Behavioral Indicators |
|---|---|
| Developing | Attends cross-functional meetings and relays information to their team, but mostly as a messenger. Translation tends to be literal (what was decided) rather than contextual (what it means for us). May not consistently carry their team’s signal upward. Relationship with their manager is mostly reactive — responds to direction but doesn’t proactively share context or surface risks upward. |
| Performing | Actively synthesizes information in both directions. Their team understands not just decisions but the reasoning and implications behind them. Carries their team’s risks and concerns into staff-level forums in a way that gets heard. Manages upward effectively — proactively shares ground-level context with their manager, shows their reasoning on important decisions, and closes the loop after receiving guidance. Engineers on their team are rarely surprised by organizational shifts because they’ve been kept in the loop. |
| Excelling | Is a critical node in the organization’s information network. Connects dots across domains that others miss. Their synthesis of organizational context influences how leadership understands what’s happening on the ground — they actively shape their manager’s and leadership’s understanding of reality, not just report to it. Other Staff Engineers rely on them for context. Has built habits or rituals that make information flow sustainable, not dependent on heroic effort. |
6. Alignment and Trust
| Level | Behavioral Indicators |
|---|---|
| Developing | Generally follows organizational direction but may not fully understand the reasoning behind it. Disagreements are sometimes expressed informally or after decisions are made, rather than constructively in the right forums. May present organizational decisions to their team with hedges or distancing language that subtly undermines alignment. |
| Performing | Understands the organizational direction well enough to represent it faithfully. Disagrees constructively and in the right forums, before decisions are final. After a decision is made, commits fully and communicates it to their team with context and conviction. Their manager trusts them to operate independently because their reasoning and values are predictable and aligned. |
| Excelling | Has deep trust from leadership — can operate with significant autonomy because their judgment is consistently aligned with organizational values and direction. When they push back, it’s valued because it comes from a place of deep understanding, not personal preference. Their alignment is a model for other Staff Engineers. They build trust not just with their own manager but across the leadership chain. |
Summary View
For quick calibration conversations, use this condensed view:
| Dimension | Developing | Performing | Excelling |
|---|---|---|---|
| Technical Direction | Reacts to gaps; articulates risks when asked | Proactively monitors risks; writes strategy that is specific and opinionated | Shapes direction beyond own domain; produces technical vision; judgment sought by leadership |
| Engineering Principles | Follows principles; inconsistent engagement with violations | Consistent principled engagement through dialogue; evolves principles | Cultural steward; their engagement is a model for others |
| Quality Bar | Thorough but correctness-focused reviews | Reviews that grow engineers; docs that set the standard | Has measurably raised quality culture; creates scalable quality practices |
| Multiplying Others | Helpful when asked; incidental impact on growth | Proactive sponsorship and mentorship; creates space for others; deliberate investment | Track record of significant people growth; builds systems that multiply beyond their reach |
| Connecting Information | Relays information; literal translation; reactive with manager | Synthesizes both directions; manages upward proactively; team is never surprised | Critical information node; shapes leadership’s understanding; connects cross-domain dots others miss |
| Alignment and Trust | Follows direction; disagreements may surface informally | Disagrees constructively; commits fully after decisions; trusted to operate independently | Deep leadership trust; significant autonomy; alignment is a model for others |
Using the Ladder in Review Cycles
During performance reviews, we recommend the following approach:
- Self-assessment first. The Staff Engineer rates themselves across all six dimensions with specific examples for each rating. This is not a formality — it is the foundation of the conversation.
- Manager assessment. The manager independently assesses the same dimensions, also with examples. Where ratings differ, that’s where the most valuable conversation happens.
- Calibration conversation. Walk through each dimension together. The goal is not to negotiate a score but to build a shared understanding of where the engineer is strong, where they’re growing, and what deliberate actions would help them develop.
- Growth focus. Identify one or two dimensions for intentional development in the next cycle. “Get better at everything” is not a plan. Pick the dimensions where growth would have the most leverage for this person in their current context.
Further Reading
For background on why career ladders work the way they do — and the trade-offs in designing them — see Larson’s An Elegant Puzzle, Section 6.5 on performance management systems. His core insight: career ladders are a tool that applies better against populations than people, and Staff-plus ladders in particular often paper over several distinct roles behind a single title. That’s why we pair this ladder with the Archetypes section — the archetype tells you which shape of the role you’re calibrating against.