From Senior to Staff: What Actually Gets Evaluated

Introduction — Does Writing More Code Get You Promoted?
What Public Ladders Actually Measure
The Four Archetypes — Which One Are You Standing In?
How Impact Becomes Evidence
The Glue-Work Trap — What Reilly Actually Said
Writing Is Leverage
Visibility Without Politics
The Honest Note — Ladders Are Noisy
An AI-Era Footnote
Closing
References

Introduction — Does Writing More Code Get You Promoted?

The first prescription most stalled engineers reach for is "more, faster." Close more tickets. Open more PRs. Work the weekend. A year later, the level is unchanged.

The reason is simple. No public engineering ladder measures output volume. That is not a hunch — it is what you find when you actually open the documents. This post grounds the question of what genuinely gets evaluated in real ladder text, Will Larson's research on Staff-plus engineers, and Tanya Reilly's work on glue.

What Public Ladders Actually Measure

progression.fyi collects public career frameworks from dozens of companies — CircleCI, Dropbox, Monzo, Etsy, Spotify, Square, Rent the Runway, and many more. Put them side by side and the vocabulary differs, but the axes overlap to a striking degree.

Rent the Runway's ladder was among the first shared publicly, and it established the four pillars that later frameworks copied: "Technical Skill", "Get Stuff Done", "Impact", and "Communication & Leadership".

Dropbox's career framework is even more direct. The document opens by stating that "Dropbox measures the success of its engineers largely on business impact," and it defines level expectations along three axes — Scope, Collaborative Reach, and Levers for Impact. It then says plainly that these expectations are "the what that determines the difference between an IC3 and IC4." At the Staff level (IC5), scope reads: "I deliver multi-year, multi-team product or platform goals," tackling "open-ended problems that require difficult prioritization, defining both the what and how." Collaborative reach reads: "I am increasingly influencing the roadmaps of other Dropbox teams."

CircleCI runs six levels, E1 (Associate) through E6 (Principal), and what separates them is the reach of your impact — "from task to epic, team level, and onwards ... to across several teams and, ultimately, across the organization." The nature of the work changes too: it "shifts over time from execution to include facilitating, guiding, and mentoring others, whether or not they are in a management role." Their own example is clarifying. A junior engineer writes tests; the most senior engineer drives testing strategy across teams. Same subject, different leverage.

CircleCI E1 -> E6 : the reach of your impact grows
  task  ->  epic  ->  team  ->  several teams  ->  organization

Dropbox IC3 -> IC5 : three axes grow together
  Scope              my project      ->  multi-year, multi-team goals
  Collaborative      my team         ->  influencing other teams' roadmaps
  Levers for Impact  direct execution ->  strategy, judgment, role model

The axis that appears on no ladder:
  "amount of code written"

One honest caveat. "Get Stuff Done" is a real pillar at Rent the Runway, and execution genuinely is evaluated. But execution is the baseline at every level — the axis that disqualifies you if it is missing, not the one that promotes you. What actually changes between levels is scope and leverage. The common reason a senior engineer fails to reach Staff is not weak execution; it is that the execution always happens inside a scope somebody else defined.

The Four Archetypes — Which One Are You Standing In?

Will Larson interviewed Staff-plus engineers across many companies and distilled four archetypes.

Tech Lead — "guides the approach and execution of a particular team." Partners closely with a manager to steer one team's technical direction and delivery. It is the most common archetype, and by Larson's observation it occurred in every company he studied. It is the version of Staff most people reach first.
Architect — "responsible for the direction, quality, and approach within a critical area." Owns an enduring domain like API design or infrastructure on a multi-year horizon. Typically only emerges past roughly one hundred engineers.
Solver — "digs deep into arbitrarily complex problems and finds an appropriate path forward." Goes deep on a problem the organization has flagged, then moves to the next hotspot. Unlike the first two, the Solver does not hold ongoing ownership.
Right Hand — "extends an executive's attention, borrowing their scope and authority." Operates a complex organization using an executive's authority. The rarest of the four; it generally appears only around a thousand engineers.

What matters is that Larson offers these as descriptive, not prescriptive. As he puts it: "Being a Staff-engineer is not just a role, rather it's the intersection of the role, your behaviors, your impact, and the organization's recognition."

So the practical question is not "which archetype do I want to be?" but "which archetype does my company actually have room for?" Trying to become an Architect at a fifty-person company is running at a position that does not exist. Conversely, at an organization with a weak concept of teams, the Solver path is wide open.

How Impact Becomes Evidence

This is where the biggest misunderstanding lives. Creating impact and having impact be legible are two different jobs. Promotions are decided on the second one.

High-scope work is inherently faint in the record. If you resolve a six-month interface dispute between two teams, the artifact is thirty lines of code and one agreement. Almost none of it lands in the commit log. That is why Staff-level work has to be done in a shape that deliberately leaves evidence.

Design docs and RFCs. Half of Staff work is defining what to build — Dropbox's own phrase is "defining both the what and how." Once that definition exists as a document, the document is the evidence that you exercised judgment at that level.
Incident leadership. Taking incident command, writing the postmortem, and driving the follow-up items to closure. People remember who provided direction at the organization's most fragile moment.
Mentoring and review. Dropbox lists "I serve as a role model for other Dropbox engineers" as an explicit IC5 expectation. Making other people's code better is not a hobby; it is a line item on the ladder.
Cross-team unblocking. Keep a record of the moments you changed another team's roadmap. That is precisely what Dropbox means by collaborative reach.

At the summit of all this sits what StaffEng calls the "Staff project" — one that is "complex and important enough that the person who completes it has proven themselves as a Staff engineer." It has three traits: it arrives badly defined ("poorly scoped but complex and important"), its stakeholders are numerous and divided, and it is visible enough that leadership discusses it at all-company meetings. Everyone sees it succeed, and everyone sees it fail.

The Glue-Work Trap — What Reilly Actually Said

Tanya Reilly's "Being Glue" is the most-cited and most-misread piece in this whole conversation.

Glue work is onboarding, mentoring, unblocking others, brokering cross-team agreement, writing documentation, reviewing designs — the work nobody assigned but whose absence collapses the project. And here is where the misreading starts: Reilly never says do not do glue work. She says glue work is the difference between a project that succeeds and one that fails.

Her actual argument has two parts.

First, a problem of distribution and visibility. This non-promotable work lands disproportionately on certain people — women especially. And then, at review time, those same people are told they lack technical accomplishment. Reilly is blunt about that feedback: "not technical enough" is gatekeeping, and it is not actionable, because there is no way to know what you are being asked to do.

Second, a problem of substitution. Her most famous line is exactly this: "If you only do glue, you will only get better at glue." The load-bearing word is only. Glue work that complements technical depth is simply what Staff engineering looks like. Glue work that replaces technical depth is a career cul-de-sac.

Her remedies are unsentimental too. Get explicit with your manager about promotion criteria. Ask for a title that matches the work you are doing. Produce artifacts that serve as evidence. And if none of that works — put the glue down and go build something technical and measurable. "Stop being the unofficial lead." If you are not the official lead, stop doing the official lead's job for free.

It is also a message aimed at managers and peers. Reilly asks people to recognize glue work publicly — and to name it correctly: "publicly give them credit! And not for helping, but for leading."

Writing Is Leverage

Reilly's book, The Staff Engineer's Path, organizes the job into three pillars — big-picture thinking, project execution, and leveling up others — and insists all three must rest on a foundation of technical skill.

The one tool that runs through all three pillars is writing, and the reason is leverage. Persuasion in a meeting reaches only the people in the room and evaporates within the hour. A good design doc persuades while you sleep, persuades the person who joins six months from now, and persuades the room you are not in. The moment your scope crosses team boundaries — which is the definition of Staff — you cannot be in every room. Only the document can.

The same principle governs code. The case for writing code that its readers can actually follow, and why that is what creates leverage, is in When an AI Maintains Your Code, Write for Humans Anyway.

Visibility Without Politics

Many engineers treat "being visible" as a synonym for politics. So they say nothing, and get passed over by people who never knew what they did.

The distinction is simple. Politics is making impact that does not exist look like it does. Visibility is making impact that does exist legible. The second is honest labor — and frankly it is a courtesy to the people evaluating you, who do not have time to reconstruct your last six months on your behalf.

That is what StaffEng's promotion guides keep circling back to: find your sponsor, get in the room where decisions happen and stay there, write the promotion packet, take on the Staff project. A sponsor is not someone to flatter. A sponsor is someone who can accurately describe your work in rooms you are not in — and to do that, they have to accurately know it. Telling them is not politics. It is the job.

Practically, this is enough: write decisions down, actually send the documents you write to the people they affect, and credit outcomes to the team while being clear about the judgment calls you made. Then draft your own promotion packet every six months. If you find there is nothing to put in it, that is precisely the fact you needed to learn today.

The Honest Note — Ladders Are Noisy

Do not walk away from this thinking a ladder is a precision instrument.

Ladders differ by company. The frameworks collected on progression.fyi disagree on the number of levels, the names of the axes, and what they emphasize. As Larson observed, the Architect appears around one hundred engineers and the Right Hand around a thousand. Which means the same person can be a Senior at company A and a Staff at company B. That is a fact about org structure, not a verdict on you.

Luck matters too. StaffEng openly concedes one condition for landing a Staff project: "your company having a pressing need to solve a Staff-level problem, which can require some patience." If your company has no Staff-level problems, you cannot manufacture Staff-level evidence. On top of that, your management chain has to be willing to bet on you.

So do not make the level your identity. What you control is the habit of widening scope and the habit of leaving evidence. What you do not control is timing. But the person who has the first two is ready when the timing arrives.

An AI-Era Footnote

Code output is getting cheap. An implementation that used to take a week now takes a day, and that gap will keep widening.

The tempting conclusion is that engineers are therefore worth less. Look at the ladders again and the story inverts. No ladder was measuring output in the first place. What ladders measured was the ability to turn an ambiguous problem into a defined scope ("defining both the what and how"), judgment that spans teams, and the decision about what not to build. Those are not the axes today's models hand you. If anything, as implementation gets cheaper, the cost of excellently implementing the wrong thing becomes far more visible.

There is a side effect, though. AI creates a new glue trap. Docs, summaries, prototypes — all can be generated in minutes, which means looking busy has never been easier. The principle that activity is not scope holds, and it now demands a colder question: whose decision did this artifact actually change?

Why the ability to convert ambiguity into scope inside an unfamiliar environment keeps getting more expensive is covered from another angle in Preparing to Become a Forward Deployed Engineer.

Closing

To sum up: promotion is about scope and leverage, not output. Execution is the entry ticket; what raises your level is the reach of your impact. The archetypes are a map, not a prescription — look at which position actually exists at your company. Impact does not end when you create it; it has to be read, so leave evidence. Glue work is essential, but it becomes a trap the moment it replaces technical depth. And ladders are noisy, so do not make the level your identity.

If one honest piece of advice survives all of this, it is this. Next quarter, do not ask "what else should I build?" Ask "what important problem does nobody currently own?" The habit of answering that question, and writing the answer down, is the only thing that transfers across every company and every ladder.