Reading the Ladder Honestly
Your company's ladder says staff engineers demonstrate broad technical leadership. That sentence is doing no work at all, and building a plan on it is how people spend two years optimising for the wrong thing.
The Problem
Here is a decision sitting in front of your organization right now, or one very like it.
You run six EKS clusters on 1.28. Standard support ends in forty-seven days, after which each cluster bills at the extended support rate rather than the standard one, and the control plane line on the bill goes from a rounding error to something a finance partner asks about.
6 EKS clusters, 1.28, standard support ends in 47 days
standard support $0.10/cluster/hour 6 x 0.10 x 730 = $438/month
extended support $0.60/cluster/hour 6 x 0.60 x 730 = $2,628/month
cost of deferring one quarter = $6,570
engineer-weeks to upgrade 6 clusters, 220 services = roughly 9
deprecated APIs to chase across 14 team repos = 3Somebody has to decide the sequence: which cluster goes first, whether staging is a real signal or theater given that staging carries none of the CRDs the payments cluster does, whether to pay the extended support rate for a quarter and do it properly after the retail freeze, and who chases the three deprecated APIs across fourteen repositories. The mechanics of all of that live in the Production Kubernetes Operations course, which spends a whole module on upgrade strategies and add-on lifecycle.
Which of those decisions is a staff engineer's at your company is the single most useful fact you can learn about your ladder, and it is not written anywhere. At one company the staff engineer is the person who personally sequences and runs the six upgrades. At another, running the upgrades personally is what a senior engineer does and the staff engineer is judged on whether six teams executed it without needing them. At a third, the technical work is not what is being evaluated at all, and the staff-scope act is walking into a planning meeting and getting three engineers pulled off feature work for six weeks on the strength of $6,570 a quarter and a support cliff.
The same work. Three different levels. The ladder document at all three companies says something close to "demonstrates broad technical leadership and influence beyond their immediate team," which is compatible with every one of those readings and therefore tells you nothing.
Ladder documents are vague on purpose and the purpose is not malice. They are written to apply to a mobile client team, a data platform team, and an SRE org simultaneously; they have to survive a reorg; and they are a legal artifact in a compensation process. Every sentence that would be specific enough to be useful to you is a sentence that would be wrong for half the engineers it governs.
Your ladder document is a constraint on the promotion decision, not a description of it. The real definition lives in three places you can actually observe: the decisions currently owned by the people who already hold the title, the two or three things that were true of the last people promoted into it, and the point in the org where a live decision like the upgrade sequencing stops for approval. Read those and you get a definition specific enough to act on. Read the document and you get a sentence that is true everywhere and useful nowhere.
How It Works
There are three sources of evidence and they take about a week to gather, most of it in conversations you are already having.
The first is the people who hold the title. Not what they say they do, and not their job description. Take each staff engineer in your part of the org and identify the last three decisions with their name attached, then score those decisions on the four multipliers from the previous lesson. If their decisions score around 3 on teams constrained and 4 on cost of reversal, that is the observed threshold. This is more informative than any conversation, because it is revealed rather than reported, and it takes an afternoon of reading design docs and change tickets.
The second is the last two or three promotions. If your company shares packets, read them. If not, ask the person who was promoted what they think actually mattered. People are candid about this one-to-one in a way they never are in a group, and the answer is usually two or three specific things rather than a theme. "The multi-region failover design" is an answer. "Consistently high impact" is the document again.
The third is the approval graph of a real decision. Take the upgrade sequencing and watch where it stops. Does it stop with the team lead, with a staff engineer, with an architecture review, with the director? Whoever the decision genuinely stops at, rather than whoever is copied on the thread, is where that scope of decision lives in your org. The approval graph is the ladder, and unlike the document it is updated continuously and cannot be written aspirationally.
The written ladder against the observed one, on the same upgrade decision
What the document says
True everywhere, useful nowhere
What the evidence says
Specific, observable, gathered in about a week
What varies between companies is not the words but which of the four multipliers the organization actually pays for, and infrastructure orgs cluster into three recognizable shapes.
In a forty-engineer company with six clusters and no platform team, depth is scope, because the fleet is small enough that one person holding the whole upgrade in their head is genuinely the constraint. Staff there means owning the upgrade end to end and being trusted on the sequencing. In a four-hundred-engineer company with a platform org of thirty, the same work is what a strong senior engineer does, and staff means the six teams executed the upgrade against a process and a set of guardrails you designed, without you in the room. Personally running the upgrades in that org is a mildly negative signal, because it means the process did not exist. In a product-led company where infrastructure is a cost center, the technical sequencing is nobody's promotion case, and the staff-scope act is the meeting where the support cliff and the $6,570 become a funded decision rather than an engineering complaint. Module 5 is four lessons on that last case specifically.
An engineer at a company of that second shape spent two years becoming the most capable Kubernetes operator in the building. They personally ran fourteen cluster upgrades across three minor versions, never took an outage, and wrote a genuinely good runbook. At the promotion conversation the feedback was that the committee could not identify a decision they had made, only work they had done exceptionally well, and that the runbook was excellent but had never been handed to anyone. The correction took nine months and was almost entirely a change of target rather than a change of effort: the next two upgrades were executed by two other teams against a process and a set of pre-flight checks they wrote, and they were not in the room for either. The work was less interesting. It was also the first thing they had done that scored above zero on teams constrained.
Two things this lesson deliberately does not cover. Will Larson's Staff Engineer and Tanya Reilly's The Staff Engineer's Path own the general version of this material: the archetypes, sponsorship, promotion packets, staff projects, and organizational navigation across all of software engineering. They are better sources for that than anything here, they are cheap, and this course does not attempt to restate their frameworks as though they were its own. What this lesson adds is narrow: the method of reading your specific organization from a specific infrastructure decision, because the upgrade sequencing is a concrete thing you can watch route through the org this quarter.
Applying It
Ask about a decision, not about the ladder
"What do I need to do to reach staff" reliably produces the document read back to you, because it is a question about a category and your manager answers categories with categories. A question about a named decision produces a real answer.
Ask this instead: "If the 1.29 sequencing across all six clusters were mine end to end, including whether we pay extended support for a quarter, is that in scope for me now, is it a stretch, or is it above me?" Every possible answer to that question is useful. "That is yours already" tells you the bar is higher than you thought. "That would be a stretch and I would want to see it" is an offer. "That sits with the architecture group" tells you where the scope is and gives you the next question, which is what would have to change for it to move.
Score the people who already hold the title
Take the three most recent decisions attributable to each staff engineer near you and put the four multipliers on them. You are looking for the floor rather than the average, because the floor is the bar. If the lowest-scoring decision any of them owns is a 3 on teams constrained, that is the threshold, and it is a much more honest number than anything in a calibration guide.
The uncomfortable result is common enough to warn about: sometimes the scores come back low, and the honest reading is that the title in your organization tracks tenure or proximity to a revenue system rather than scope. That is a real finding and it is worth having early. It costs you a week now instead of two years.
Watch one decision route
Pick the upgrade, or the next equivalent, and write down every point at which it stopped for someone's agreement, over about six weeks. Not who was informed, who could have blocked it. That map is the most accurate ladder document your company has and nobody maintains it.
Reading your ladder accurately does not mean the level is available. Organizations run out of band budget, freeze headcount, define staff as a scarce architecture role with a fixed count, or simply have no slot in a team of eleven. A correct reading that ends in "the scope exists here and the title does not" is a useful answer, and the response to it is a decision about where you work rather than a plan to try harder. No course changes that, and one that implies otherwise is selling you something.
Tradeoffs and Decision Framework
| Evidence source | What it tells you | Cost to gather | How it misleads |
|---|---|---|---|
| The ladder document | The constraints on the promotion conversation | Ten minutes | Compatible with every possible bar, so it never rules anything out |
| Decisions held by current staff | The observed threshold, revealed rather than stated | An afternoon of design docs and change tickets | A single unusual person distorts it; use the floor, not the average |
| Last two or three promotions | The two or three things that actually counted | Two conversations | Survivorship, and people rationalize their own promotions |
| Where a live decision stops | Which scope sits at which level, continuously updated | Six weeks of watching one decision | Slow, and a single escalation can be about the person rather than the level |
| Your manager on a named decision | Whether a specific scope is available to you now | One question | Only as good as the specificity of the decision you name |
| Job postings for staff at your company | What the org will claim publicly | Ten minutes | Written by recruiting, frequently a level off |
Three questions settle it. Which of the four multipliers does your organization actually pay for, given what the current staff engineers own rather than what the document says? Is the upgrade-sequencing decision, or its equivalent in your domain, currently held above you, at your level, or by nobody? And if you get a clear reading, is the title actually available here, or have you just learned that the scope exists and the slot does not?
Default: read the org from the decisions, ask your manager about one named decision rather than about the level, and give yourself a week rather than a quarter. The single most expensive mistake available in this area is a two-year plan built on a sentence that was written to be unfalsifiable.
Common Mistakes
Treating the ladder document as a specification. It is written to govern several hundred engineers across every discipline and to survive reorganizations, which requires it to be compatible with almost any bar. It constrains the promotion conversation; it does not describe it.
Asking what you need to do to reach staff. The question names a category and gets a category back. Naming a decision, with a cluster count and a dollar figure attached, gets an answer you can act on this quarter.
Assuming the definition transfers between companies. Running six upgrades end to end is the staff-scope act in a forty-engineer shop and mild evidence against you in a four-hundred-engineer platform org, because in the second one it means the process you were supposed to build does not exist.
Averaging the current staff engineers rather than taking the floor. One unusually deep specialist raises the average and tells you nothing about the bar. The lowest-scoring decision anyone at that level genuinely owns is the threshold.
Reading calendars and org charts instead of approvals. Being in the room is not the same as being able to say no. Follow one real decision until it stops somewhere, and note that place.
Believing the promoted person's first answer. Everyone rationalizes their own promotion into a narrative. Push for the two or three specific artifacts, and note that people are candid one-to-one and never in a group.
Ignoring a clear reading because it is unwelcome. "The scope exists here and the title does not" and "this org promotes on proximity to revenue" are both findings. Neither is fixed by more effort, and finding either one out in week one is worth a great deal more than finding it out in year two.
Trying to get the general career material from this course. Larson and Reilly cover archetypes, sponsorship and promotion mechanics properly and at length. This course covers infrastructure judgment, and lesson 6.4 is the only other place it goes near the career machinery.
You want to know what staff means at your company. Your platform org has thirty engineers, six EKS clusters, and four people already holding the staff title. Which of these gives you the most accurate reading, fastest?