Study Notes by Niladri & AI

sec13-staff-projects

13 min read

Staff Projects

selt staff-projects promotion organizational-impact technical-leadership

Status: Notes complete

Overview

Many companies expect a Staff-engineer candidate to have demonstrated impact at the Staff level before the promotion is approved — and the clearest demonstration of that is through a “Staff project”: a piece of work whose scope, visibility, and organizational consequences are themselves evidence that the candidate already operates at the Staff level.

This section examines what makes a project qualify as a Staff project (as opposed to simply a large or technically impressive Senior project), how to find or create such work, and how to execute it in a way that advances rather than endangers the promotion. Larson also addresses the harder reality that Staff projects are risky, hard to find, and not always available in the environment you are currently in — and what to do about that.

Core Concepts

Staff project — A project that is company-critical, technically or organizationally challenging, cross-team in scope, and requires demonstrating the specific skills that define the Staff level: operating with broad autonomy, shaping the work of others, creating organizational leverage, and making consequential decisions under ambiguity.

Organizational impact — The degree to which a project’s outcomes are visible across the organization and speak to the engineering priorities of the company as a whole, not just one team. A Staff project must pass the organizational impact test: many people across the org can speak to what it accomplished and why it mattered.

Scoping to success — A Staff-level meta-skill: the ability to take a large, ill-defined initiative and define it in a way that is deliverable, meaningful, and defensible as demonstrating Staff-level impact. Scope management is itself evidence of Staff-level thinking.

Organizational leverage — Impact that multiplies through people, systems, and processes rather than through individual technical output. A Staff project creates organizational leverage: after it is done, other teams can move faster, make better decisions, or build on a stable foundation.

What Makes a Project a “Staff Project”

Not every large or technically difficult project qualifies. A Staff project satisfies several criteria simultaneously:

Company-critical scope. The project addresses something the company genuinely needs to solve at the level of the organization’s technical strategy, not just one team’s roadmap. If the project succeeded or failed invisibly, it was not operating at Staff scope.

Cross-team coordination requirement. The project requires working with people who do not report to you, across team boundaries, often involving competing priorities and influence without authority. Managing this coordination is part of what the project demonstrates.

Consequential technical decisions. The project involves decisions with long-lasting organizational consequences — architectural choices, platform directions, standards — not just the implementation of a plan that someone else has already scoped.

Broad organizational visibility. After the project, multiple people across the organization (other engineering teams, product leadership, senior engineers in adjacent areas) are aware of the work, its outcomes, and your role in it. Invisible heroics do not count.

Requires Staff-level skills to execute. The project tests the skills you are trying to demonstrate: operating at broad scope, making decisions under ambiguity, driving cross-functional alignment, and creating work that other engineers can build on.

Why Multiple Medium Projects Often Don’t Add Up

A common pattern among Senior engineers preparing for Staff promotion is accumulating a portfolio of medium-sized, high-quality projects, expecting them to add up to Staff-level impact. They typically do not, for a specific reason.

Staff promotion is not primarily a reward for quantity of solid work. It is recognition that you are already functioning at the Staff level: operating at the scope of influence, organizational visibility, and consequential decision-making that defines Staff. A series of well-executed Senior projects demonstrates that you are a very strong Senior engineer. It does not demonstrate that you can operate at the broader organizational scope that Staff requires.

The distinction is not difficulty — a medium project can be technically demanding. The distinction is organizational scope: does your work create leverage across the organization, or does it create excellent outcomes within a bounded team context?

The Organizational Impact Test

Larson offers a useful diagnostic: the organizational impact test. Ask: could multiple people across the organization — outside your team, in adjacent engineering areas, in product leadership — describe what this project accomplished and why it mattered?

If the answer is yes, the project is likely operating at Staff scope. If the answer is “mostly just my team and my manager,” it is likely operating at Senior scope regardless of technical complexity.

The organizational impact test has a corollary: if the project is important enough, make sure it becomes visible. Low-visibility heroics are a failure of communication as much as a failure of project selection. Part of Staff-level work is narrating your work to the organization in a way that allows its impact to be recognized.

Finding vs. Creating Staff Projects

Finding a Staff project means recognizing an important initiative already in motion (or about to be) and positioning yourself to lead it. This requires:

  • Understanding your company’s highest-priority technical problems
  • Having enough organizational context to see which problems require cross-team coordination and broad scope
  • Moving quickly when such opportunities arise — they are competitive

Creating a Staff project means identifying a problem no one has formally scoped, writing the proposal, getting buy-in, and driving the project from a blank page. Creating a Staff project is often harder than finding one because you are doing the organizational work of legitimizing the problem before you can do the technical work of solving it. However, it is also stronger evidence of Staff-level capability: you saw the problem, understood its organizational significance, built the case for solving it, and led the execution.

The pattern for creating a Staff project:

  1. Identify a gap or risk that crosses team boundaries and has significant organizational consequence.
  2. Write a clear framing of the problem and its impact — visible enough that leadership understands why it matters.
  3. Propose a scope that is ambitious enough to matter but deliverable enough to succeed.
  4. Get sponsorship from a senior leader who makes the project organizationally legitimate.
  5. Execute with the autonomy and cross-team coordination that demonstrates Staff-level operation.

Not All Staff Projects Are Technical

A common misconception is that Staff projects are defined by technical sophistication. Some of the strongest Staff projects are primarily organizational:

  • Establishing a cross-team technical standard (API contracts, data modeling conventions, security practices) that multiple teams then adopt
  • Creating a new coordination structure (a technical working group, an on-call rotation across teams, a cross-functional review process) that reduces friction and increases velocity
  • Defining a platform strategy that gives product teams a coherent framework for making infrastructure decisions without escalating each one
  • Driving an architectural migration whose primary challenge is cross-team alignment and change management, not the technical implementation itself

The Staff-level skill in organizational projects is the same as in technical ones: identifying a problem at organizational scope, proposing a solution with enough specificity to be actionable, driving adoption across teams that didn’t ask for your involvement, and delivering outcomes that are visible and measurable at the organizational level.

Pure technical work — a highly sophisticated algorithm, an elegant refactoring, a complex performance optimization — often does not reach the Staff bar if it occurs in isolation within a single team, regardless of its technical quality. The organizational component is not optional.

Scoping to Success: The Critical Meta-Skill

Large, important initiatives frequently arrive at the Staff engineer’s doorstep in a badly scoped state: the problem is real and important, but the initial scope is either too large to deliver or too vague to plan. A key Staff-level skill is taking that ill-defined initiative and scoping it into something deliverable.

Why scoping is a Staff-level skill:

  • It requires enough organizational context to understand what the company actually needs, not just what was initially asked for.
  • It requires enough technical depth to understand what is actually buildable in the relevant timeframe.
  • It requires enough influence to negotiate the scope with stakeholders who may have conflicting expectations.
  • It requires enough judgment to know when a project is in scope creep that will sink it and when apparent scope creep is actually discovering the real problem.

Good scoping of a Staff project produces: a clear deliverable with measurable success criteria, a realistic estimate of the cross-team coordination required, an explicit statement of what is out of scope and why, and a narrative that connects the bounded deliverable to the larger organizational need.

Staff Projects Are Risky

Staff projects are not just high-reward — they are genuinely high-risk. Several dynamics make them dangerous:

Failure is visible. A Staff project that is cancelled, significantly descoped after launch, or delivers without organizational adoption fails in front of the same broad audience that would have witnessed success. That visibility is not neutral; it can set back a promotion by one or two cycles.

You are working with people who do not report to you. Cross-team coordination without authority means you are managing dependencies through influence, persuasion, and relationship-building. When a dependency team misses a commitment, you cannot simply order them to meet it. Staff projects require conflict navigation and stakeholder management skills that are genuinely difficult.

The technical uncertainty is higher. Staff projects involve architectural and organizational decisions with long-lasting consequences. Getting a major architectural decision wrong in a Staff project is not recoverable in the same way that getting a Senior-level implementation detail wrong is.

Scope risk is real. What starts as a Staff project with a clear mandate can expand through organizational dynamics into something that is no longer deliverable on any reasonable timeline. Managing this risk — knowing when to push back on scope, when to reframe the project, when to surface the risk to a sponsor — is itself a Staff-level skill.

What to Do If You Can’t Find a Staff Project

Not every team or company has Staff-scale problems available to a given engineer at a given time. This is a real constraint, and Larson is direct about it: if your environment does not have Staff-scale work, you will not be able to demonstrate Staff-level impact in that environment.

Options:

Change teams internally. Move to a team working on your company’s most strategically important problems. The team you are on matters enormously: a team working on the core platform, an existential technical migration, or a foundational new product capability is more likely to have Staff-scale work available than a team maintaining a mature, stable product.

Change companies. If the entire company does not have Staff-scale engineering problems — because it is too small, the engineering organization is not at the stage of development where Staff-level work exists, or the culture does not recognize Staff-level contributions — a role change may be necessary. Larson acknowledges this clearly: staying loyal to a company that cannot offer you the work you need to grow is not a virtue, it is a strategic error.

Proactively create the project. Identify the most important unsolved cross-team technical problem in your organization, write the framing, and build the case for solving it. This is harder but is itself strong evidence of Staff-level capability.

Reframe what already exists. Sometimes the Staff-scale project exists but has not been recognized as such. A careful reframing of a project’s organizational impact — combined with more deliberate communication of that impact — can convert a well-executed medium project into a recognizable Staff-level contribution. This is not spin; it is making the organizational significance of your work legible.

Staff Projects as a Company Norm vs. Not

Larson notes that the “Staff project” is an explicit requirement at some companies and not others. At companies that explicitly require a Staff project for promotion, the absence of one is a disqualifier — having done excellent Senior work is insufficient. At companies where it is not an explicit criterion, the underlying expectation still exists implicitly: you need to have demonstrated Staff-level scope and impact, whether or not it was called a “Staff project.”

Understanding your company’s norms is important: ask your manager, ask recently-promoted Staff engineers, and read the promotion criteria documents carefully. The most common error is assuming the criterion does not apply and then failing the promotion because you did not accumulate the right kind of evidence.

The 10x Engineer Myth and Organizational Leverage

A related misconception is that Staff engineering is about individual productivity — the “10x engineer” who writes more code, solves harder problems, and ships faster than anyone else. Staff projects are fundamentally incompatible with this framing.

Staff projects are not about being a technically superior individual contributor. They are about organizational leverage: your work creates conditions that allow an entire organization to move faster, build better, and make higher-quality decisions. The question is not “how much faster can you personally go?” but “how much more effective do other engineers become because of your work?”

This means that the best Staff projects often look, from the inside, like a lot of coordination, communication, writing, and alignment work. The technical content is real and important, but the organizational amplification is what distinguishes Staff-level work from excellent Senior work.

Key Takeaways

  1. A Staff project is defined by organizational scope, not just technical difficulty: it must be company-critical, cross-team, visible broadly, and require demonstrating the specific skills that define Staff-level operation.
  2. Multiple medium projects do not add up to a Staff project — they demonstrate strong Senior capability, not the organizational scope that Staff promotion requires.
  3. The organizational impact test: if people across the organization outside your team cannot describe what the project accomplished and why it mattered, it likely operated at Senior scope.
  4. Not all Staff projects are technical — organizational projects (establishing standards, creating coordination structures, driving adoption) can be equally strong evidence of Staff-level capability.
  5. Scoping to success is a Staff-level meta-skill: the ability to take an ill-defined large initiative and scope it into something deliverable is itself evidence of the judgment required at Staff level.
  6. Staff projects are genuinely risky: visible failure can set back a promotion by one to two cycles; cross-team coordination without authority is hard; scope risk is real.
  7. If you cannot find a Staff project in your current environment, the right answer may be changing teams, changing companies, or proactively creating the project rather than waiting for it to appear.
  8. Staff work is about organizational leverage, not 10x individual productivity — the measure is how much more effective other engineers become because of your work.
  9. Make the impact visible: low-visibility heroics do not count. Narrating your project’s organizational significance to a broad audience is part of the project, not a separate activity.
  10. Understand your company’s norms: whether or not a Staff project is an explicit criterion, the underlying expectation of Staff-scope impact is universal.

Last Updated: 2026-05-30

Graph View

Backlinks