Managing Staff Engineers
Managing a Staff Engineer is not an extension of managing a Senior Engineer. Most management instincts — is the work getting done, is the engineer hitting sprint commitments, are they communicating well with their team — don’t disappear at Staff level, but they recede. The primary question changes: is this person creating organizational leverage, and are they doing it at the right scope?
This page gives you a framework for answering that question, identifying underperformance, and having the conversations that follow.
Before You Rate: The Operating Level Check
Before assessing how well a Staff Engineer is performing, ask whether they are operating at Staff level at all. These are two separate questions, and collapsing them is the most common management error at this level.
Work through the following questions. Answer each with a specific example, not a general impression. If you find yourself reaching for impressions or extrapolating from a single standout moment, that is a signal.
- Can you name this person’s area of technical ownership in one sentence?
- In the last six months, have engineers outside their immediate team been meaningfully influenced by their technical direction?
- Can you point to a specific engineer whose growth trajectory changed because of this person’s deliberate investment?
- When something shifted organizationally, did this person translate it to their team before the team found out through other channels?
- In the last review cycle, did they surface a technical risk before it became a visible problem?
- When they disagreed with a direction, did they do it before the decision was final, through the right forum?
- Can you point to work they initiated that wasn’t on the roadmap, because they saw the organizational need?
If you cannot answer yes with a specific example to at least five of these, the engineer is not operating at Staff level. The rating conversation that follows needs to acknowledge that directly. Identifying this early — not at an annual review — is one of the most important things a manager can do.
The Rating Framework
The framework has five dimensions. For each one, you are not rating what the person does personally. You are rating what the organization does around them as a result. This distinction matters at Staff level because leverage, not output, is the core of the job.
Each dimension uses three levels:
| Level | What it means |
|---|---|
| Emerging | The intent and occasional execution are visible, but the organizational impact isn’t consistent or measurable yet. Expected in the first year in the role or in dimensions outside the engineer’s primary archetype. Consistently Emerging in the dimensions that define the role’s leverage after year one is a different signal. |
| Operating | Reliably delivering what this dimension requires. The organization benefits consistently from this person’s contribution here. |
| Driving | Others in the organization are operating better in this dimension because of this person’s active, sustained contribution. The impact compounds beyond what they could produce directly. |
A Staff Engineer who is Operating across most dimensions and Driving in one or two is performing the role well. The goal of the rating is not a profile of Driving marks. It is an honest map of where the person is strong, where they are growing, and what the highest-leverage development focus should be in the next cycle.
Dimension 1: Technical Ownership
This dimension asks whether the engineer holds genuine technical authority over something meaningful and exercises it.
Technical ownership is not the same as technical expertise. A Staff Engineer who is the most knowledgeable person in a domain but is not actively shaping its direction is an expert, not an owner. Ownership means being accountable for where something is going architecturally, not just having opinions about it.
| Level | What you observe in the organization |
|---|---|
| Emerging | Technical decisions in their domain often happen without their meaningful input, or they participate reactively. Written direction artifacts (strategy documents, ADRs) are rare or shallow. Others are not sure who owns this area. |
| Operating | Owns a named technical domain. The top architectural risks in that domain are known to them without prompting. They initiate direction conversations, write strategy that is specific and opinionated, and ensure decisions get recorded. Others know who to go to. |
| Driving | Their technical ownership produces written direction that other engineers and teams use as a foundation. They have built enough clarity in their domain that others can make good decisions without involving them in every conversation. Leadership consults them before hardening technical direction in adjacent areas. |
Diagnostic questions to ask yourself:
- What are the top two or three architectural risks in this person’s domain right now? Ask yourself first, then ask them. Compare the answers.
- Who makes technical decisions in their area when they are out? Is there written direction to fall back on, or does the domain wait?
- When was the last strategy or direction document they wrote? What decision did it enable?
Dimension 2: Quality Leadership
This dimension asks whether technical quality in the areas this engineer touches is measurably better because of their presence.
The signal here is not whether they do good reviews. Senior Engineers do good reviews. The signal is whether the quality culture around them is changing: whether engineers on their team are catching more issues themselves, making better architectural decisions, and building better systems over time because this person has raised the bar.
| Level | What you observe in the organization |
|---|---|
| Emerging | Does thorough reviews and produces solid technical work, but the impact stays with the artifact rather than the author. Engineers don’t visibly improve from the interaction. Quality in the team is broadly consistent with what it would be without them. |
| Operating | Reviews leave engineers better than they were before. Feedback explains the “why,” not just the “what.” Design documents from this person serve as references others point to. They address quality patterns across multiple instances, not just individual violations. |
| Driving | The quality culture in their area is measurably better than it was before they arrived. Engineers seek their reviews because they learn from them. They have created tooling, templates, or practices that raise quality beyond their personal review bandwidth. The difference is visible to people who weren’t there before. |
Diagnostic questions to ask yourself:
- Can you point to a specific engineer who writes better code or produces better designs because of this person’s investment in their reviews?
- Has this person created anything — a template, a checklist, a practice — that scales quality without requiring their direct involvement?
- When quality issues surface in their area, who is catching them?
Dimension 3: Engineering Leverage
This dimension asks whether the engineers around this person are growing — in skill, in scope, in confidence — as a direct result of their deliberate investment.
Leverage is not mentorship by accident. A Staff Engineer who helps when asked is a good colleague. A Staff Engineer who watches for who is ready to grow, creates opportunities for them, and can point to specific engineers whose trajectory changed is creating leverage. There is also a complement that is easy to overlook: deliberately stepping back, choosing not to be the person who solves every hard problem, and letting others stretch.
| Level | What you observe in the organization |
|---|---|
| Emerging | Helpful when approached, generous with time, but the impact on others’ growth is largely incidental. Hard problems consistently land with them rather than being used as growth opportunities for others. Advocacy for engineers in forums where they are not present is limited or absent. |
| Operating | Actively identifies engineers who are ready for stretch work and creates opportunities. Distinguishes between mentorship (advice) and sponsorship (action) and does both. Can point to specific engineers they have invested in deliberately. Creates space by stepping back, not just stepping up. |
| Driving | Has a visible track record of engineers who grew significantly under their influence. Is recognized across teams as someone who develops people, not just code. Their sponsorship carries weight because it is backed by a history of sound judgment about people. Other managers notice when an engineer has worked closely with this person. |
Diagnostic questions to ask yourself:
- Who is this person actively investing in right now? What does that look like concretely?
- In the last 12 months, has any engineer grown into a larger role or scope partly because of this person’s deliberate support or sponsorship?
- Are there hard problems this person is solving themselves that a Senior Engineer could have grown from?
Dimension 4: Operational Independence
This dimension asks how much management overhead this person requires, and whether their independent judgment is trustworthy enough to warrant the autonomy their role demands.
A Staff Engineer who needs to be told what to work on, surfaces problems only when asked, or requires close direction to stay aligned is not operating at Staff level regardless of technical ability. The role requires holding context, making sound calls, and carrying organizational direction without constant management contact.
| Level | What you observe in the organization |
|---|---|
| Emerging | Requires more direction than the role warrants. Tends to be reactive: surfaces problems after they are visible, not before. May need prompting to connect their work to organizational priorities. Alignment with direction is present but fragile without regular check-ins. |
| Operating | Knows what to work on and why without being told. Proactively surfaces risks and context to their manager. Stays aligned with organizational direction and can represent it to their team faithfully. Requires low management overhead. Can be trusted to operate in their domain independently for weeks at a time. |
| Driving | Operates with significant autonomy because their judgment is consistent and visible. Can be handed a complex, ambiguous problem and trusted to navigate it — including knowing when to escalate, when to decide, and when to align. Other managers trust this person’s judgment in cross-functional contexts without requiring involvement from their manager. |
Diagnostic questions to ask yourself:
- In the last month, how many times did this person bring you a problem you hadn’t already seen?
- If you were unavailable for two weeks, what would you be uncertain about in their domain?
- When organizational direction shifted, how did they find out — from you, or did they already know?
Dimension 5: Organizational Navigation
This dimension asks whether the engineer moves information, context, and alignment effectively through the organization — upward, downward, and across teams — or whether they are a bottleneck or a gap.
This is not about communication style. It is about whether the organization is more coherent and better-informed because this person is in it. Their team should understand not just what is happening but why. Leadership should have an accurate picture of what is happening on the ground. Cross-team decisions should benefit from context that only this person could have brought.
| Level | What you observe in the organization |
|---|---|
| Emerging | Attends cross-functional forums and relays information, mostly as a messenger. Translation is literal rather than contextual: what was decided, not what it means. May not consistently carry their team’s signal upward. Cross-team relationships are limited. |
| Operating | Synthesizes in both directions. Their team understands the reasoning behind decisions, not just the decisions. Carries their team’s risks and concerns into forums where they are not present in a way that gets heard. Manages upward proactively. Their manager rarely discovers ground-level issues through other channels. |
| Driving | Is a critical node in the organization’s information network. Connects context across domains that others miss. Their synthesis actively shapes how leadership understands what is happening, not just reports it. Other Staff Engineers go to them for organizational context. They have built habits that make this flow sustainable rather than heroic. |
Diagnostic questions to ask yourself:
- When was the last time your team’s concerns influenced a cross-team or leadership decision? Was this person the conduit?
- Does leadership have an accurate picture of what is happening in this domain? If not, where does this person sit relative to that gap?
- What cross-team relationships has this person built that the organization relies on?
Reading the Profile
The five dimensions are not equally weighted for every engineer. A Staff Engineer’s primary archetype shapes which dimensions are most central to their current context. A specialist embedded in one team will have a different natural profile than someone operating across a whole platform.
When you have ratings across all five, look for these patterns:
Consistent Emerging on Technical Ownership and Operational Independence. These are the two dimensions closest to the core of the role. Emerging on both after more than a year is not a growth area — it is a signal the engineer is not operating at Staff level.
Driving on Engineering Leverage but Emerging on Technical Ownership. This profile can indicate someone whose natural trajectory is toward Engineering Management rather than Staff Engineering. Worth an explicit conversation about what they actually want their career to look like.
Strong ratings across all dimensions but within a narrow scope. High performance in a small radius does not demonstrate Staff-level impact. If an engineer rates Operating or Driving on every dimension but their influence does not extend meaningfully beyond their immediate team, the scope is the problem, not the execution.
Warning Signs
These patterns should prompt a direct conversation, not a wait-and-see approach.
They consistently initiate, rarely complete. Strategy documents, architectural discussions, and technical initiatives start with energy but do not drive to a recorded, actionable outcome. The org gets activity without durability.
Their team is always surprised. When organizational context shifts and the engineer’s team finds out through channels other than them, the Organizational Navigation dimension is failing regardless of how everything else looks.
They take all the hard problems. If growth opportunities consistently end up with this person rather than with the Senior Engineers around them, they are optimizing for personal output rather than leverage. This is the most insidious failure mode because it is invisible when the engineer is technically excellent.
They agree in public and dissent in private. Constructive disagreement — raising concerns before decisions are final, through the right forum — is what makes Staff Engineers valuable as organizational sensors. An engineer who only voices dissent informally or after the fact is a risk to alignment and to trust.
Their influence requires their presence. If quality, direction, and alignment in their domain degrades noticeably when they are out, they have not created leverage. They have created a dependency.
Having the Conversation
A Staff Engineer who is not performing at their level is usually not doing so because they never made the identity shift from Senior. They are still operating as a very good Senior Engineer, measuring their value by what they personally produce. The conversation needs to name that directly.
Name what you observe in the organization, not what they are doing wrong. “When you are out, your team does not have the architectural context to make decisions independently” lands differently than “you need to delegate more.” The first is observable and specific. The second is advice they have probably heard and filed away.
Separate the operating level check from the performance rating. If the question is whether they belong in the role at all, say so. Blurring the two lets both of you avoid the harder question.
Be specific about what change looks like. “You need more organizational impact” is not actionable. “In the next quarter, I want to see you write a direction document for the auth layer that the team can make decisions from without involving you” is.
Do not wait for the annual review. Feedback loops at Staff level are long. An engineer who is not operating at Staff level will not discover that from a twice-a-year review. These conversations should happen quarterly at minimum, and warning signs should be addressed in the cycle where they appear.