Harness Engineering / The Seniority Ladder / v0.1, forkable

Seniority is what you are the last check on.

Every proxy the industry used for seniority ran through output, and an agent now produces output. So the ladder has to run through something the agent cannot supply. This one uses a single axis, applied five times. At each rung, name the thing you are the last human check on before it is real. Five rungs, each with behaviors you can watch, a tell for how the rung gets faked, and one artifact that settles the question.

who it's for · the lead writing a promotion case, and the engineer who wants to know what the ladder measures
what it is not · a compensation band, a performance review, or a way to grade a diff
pairs with · the Comprehension Standard (which grades diffs, not people)
license · CC BY 4.0. Fork it, rename the rungs, change the artifacts. Keep the axis.
The behaviors
What the rung looks like from the outside. Watchable by someone who has seen the work, without a survey.
The tell
How the rung gets faked. Every rung has a convincing counterfeit, and it is usually more comfortable than the real thing.
The artifact
The one thing that settles it. No artifact, no rung, however certain everyone feels.
0 The pairing

One bar grades the change. This one grades the person.

They are different documents on purpose, and collapsing them ruins both.

The Comprehension Standard is explicit that its levels grade diffs and not people. A staff engineer merges an L1 dependency bump on Tuesday, and a first-year engineer an L3 pricing-rule change on Wednesday. Read as a career ladder, it becomes an insult and stops being usable as a merge bar.

But teams still need to answer the other question, because somebody has to decide who the team trusts with what. Left unwritten, that decision gets made by tenure, by volume, or by who speaks confidently in meetings. This document exists so the second question has its own vocabulary and stops borrowing the first one's.

two documents, two questions
The Comprehension StandardThis ladder
GradesA change, at merge timeA person, over a quarter
AsksIs this change understood?Who is trusted to be the last check?
ChangesEvery pull requestRarely, and in both directions
Lives inThe repo, enforced by the harnessA quarterly conversation, enforced by nobody
Confusing themReading "L3" as a seniority level. Makes the standard an insult and the ladder unfalsifiable.
The relationship, stated once

The standard says what a check consists of. The ladder says who the team trusts to be the last one. A team needs both, and neither substitutes for the other.

1 The axis

Five rungs, one question

Not five skills. One question asked about five things, each larger than the last.

what you are the last human check onthe whole ladder
R1  EXPLAINS     last check on · nothing yet
                 every change of theirs gets a second reader

R2  MERGES       last check on · their own ordinary change
                 "ordinary" is whatever the charter says it is

R3  REVIEWS      last check on · somebody else's change
                 the rung where approving becomes a decision

R4  CONSTRAINS   last check on · the rules that check everyone
                 stops changing code, starts changing the system

R5  SCOPES       last check on · whether the work should exist
                 the only rung whose main output is deletion

A single axis is a constraint worth defending. Most ladders are a list of adjectives, and a room can argue adjectives into whatever conclusion it already wanted. "Last check on what" is answerable by watching what happens when this person is on holiday.

The rungs are cumulative in trust but not in activity. An R4 still merges their own changes and still reviews other people's. What changed is that something new now stops with them.

One rung at a time

Nobody skips. A person who has never held a correct finding under pushback will not author the team's constraints well. Authoring a rule means holding a position, permanently and in writing, against everyone who finds it inconvenient.

2 R1 · explains

R1 · Explains

Last check on nothing. Everything they produce has a second reader, and the work of this rung is becoming worth reading.

typical weeks, not months exit four claims, unprompted, twice

Looks like

  • Asked "what happens if this runs twice", they answer from the code rather than from the agent's summary of the code.
  • Their spoken explanation and their pull request description are not the same text, because a person read the diff in between.
  • They ask for a second reader on something that scared them, before anyone tells them to.
  • They can point at the line they were least sure about. Everyone has one. Being able to name it is the skill.
The tell

Complete fluency about what the change does, total silence about how it could be wrong. The description is excellent, the mechanism is understood, and the question "what would make this fail" produces a pause and then a guess. That is a person describing code, not a person who has examined it.

The artifact

Two consecutive changes where all four claims land without prompting: what changed, why it is correct, what it could break, how you would know. Not written down anywhere special. Said out loud, to a person, twice running.

Someone sitting at R1 nine months in is almost never a talent problem. It is nearly always a team that never asked anybody to explain anything, so the fix is on the team's side. The first ninety days exists mostly to keep this rung short.

3 R2 · merges

R2 · Merges

Last check on their own ordinary change. Nobody reads it after them, which means what they refuse defines the rung, not what they produce.

scope ordinary changes only excluded money, auth, migrations

"Ordinary" is not a vibe, but the exemption list already written in the charter: the changes the team has decided do not need the raised bar. Money, authorization, data integrity, and anything nobody can cheaply roll back stay off this rung, however good the person is. That exclusion is a property of the change, not of the person.

Looks like

  • They reject agent output unprompted, and the pull request shows what they rejected and why.
  • They scope their own work small enough to stay checkable, before anyone asks them to split it.
  • They write the falsifier before the fix, because they want to watch it go red.
  • They escalate their own change to the higher bar occasionally, having noticed it stopped being ordinary partway through.
The tell

Throughput climbs and escaped defects climb with it. They are merging what passes rather than what is right, and green is doing the deciding. The quieter version of the same tell: six months of history with no record of ever turning down anything the agent proposed. Nobody is that well served by a model.

The artifact

Sixty days of self-merged ordinary changes with no defect a second reader would have caught. And at least one change they raised to the higher bar themselves. The second half matters more: it shows a person applying the exemption list rather than skipping it.

4 R3 · reviews

R3 · Reviews

Last check on somebody else's change. The first rung where approving is a decision with a cost attached to their name.

trains via reverse-review requires one bad approval, owned

Looks like

  • They write clean reviews. "I checked these four things, here is why they are fine" is a deliverable, and a review with no findings is not a wasted review.
  • They name the class rather than the instance, so the feedback survives contact with the next diff.
  • They approve a change carrying a known residual risk and say which risk, rather than pretending the risk away or blocking until it is impossible.
  • They hold a correct finding under pushback, with a red test or a line of the spec, not with volume.
The tell, in two symmetric forms

Findings that are only ever stylistic: a way of participating in review without ever being accountable for the semantics. And its mirror, the review that never ends, where every approval waits behind one more question. Both are strategies for never being the person who said yes to the thing that broke.

The artifact

One catch in production-bound code that a reasonable person would have missed. And, harder to obtain and more diagnostic, one approval that later broke. They handled it by naming what they would check next time, not by relitigating whose change it was.

The weekly rep for this rung is reverse-review, which exists to produce these two artifacts on a schedule instead of by accident.

5 R4 · constrains

R4 · Constrains

Last check on the rules that check everyone else. The first rung whose output is not code.

output rules, at the right altitude discriminator deletes rules too

Looks like

  • They convert a recurring defect into a constraint at the cheapest altitude that holds. That means a sentence in the charter, a check, or a gate that refuses. Reaching for a gate where a sentence would do is a real error, not caution.
  • They delete rules that stopped firing, and can say when each one last mattered.
  • They can state what a rule costs in friction, not only what it prevents. Nobody has evaluated a rule whose cost is unknown.
  • When a rule of theirs gets in someone's way, they take the report seriously instead of defending the artifact.
The tell

The charter only ever grows. Every incident adds a paragraph and nobody ever removes one, until the charter is too long to finish. At that point it has stopped applying to anything. The person producing that outcome usually feels the most responsible in the room, which makes this tell hard to raise.

The artifact

One rule merged with the incident named in the pull request. One rule deleted with the reason named. The deletion is the discriminator: enthusiasm produces rules, and removing one requires knowing what the system still catches.

6 R5 · scopes

R5 · Scopes

Last check on whether the work should exist. Measured mostly in things that never got built.

output deletion, early cost unpopularity, absorbed

This rung got more valuable, not less, when generation got cheap. When building something took a quarter, the cost of a bad idea was visible and someone usually stopped it. When a plausible implementation appears in an afternoon, nothing external stops it. So the only remaining brake is a person willing to say the work should not exist while everyone is already excited.

Looks like

  • They kill proposed work in writing, with the reason, early enough that nobody built it yet.
  • They routinely turn a six-week plan into a two-day change, and show the reasoning rather than asserting the smaller number.
  • They absorb the unpopularity of a correct no without needing to hear later that they were right.
  • People bring them proposals before building rather than after. Nobody can manufacture that, which makes it the clearest signal on the whole ladder.
The tell, again in two forms

The reflexive no, which is cheap, feels rigorous, and is indistinguishable from judgment for about a year. And the reflexive yes rebranded as enablement, which is the same abdication wearing a friendlier word. Both are ways of not deciding, and both scale badly.

The artifact

A written record of scope calls, including at least one they got wrong and reversed in public. A ledger with no reversals in it is a ledger nobody was checking.

7 Dead proxies

What stopped signalling

The ladder needs a new axis because the old signals were downstream of typing speed, and typing is now free.

proxies, before and after
ProxyWhat it used to approximateWhat it measures now
Changes merged per weekCapacity, roughlyPrompting speed
Time to first working versionFamiliarity with the codebaseModel latency
Breadth of API recallYears of exposureNothing at all
Lines of codeVery little, even thenLess
Rejection rate, with reasonsWhether judgment is being applied
Escape rate on self-merged workWhether R2 is real
Do others' changes improve after this person touches themWhether R3 is real
Does work get smaller when they scope itWhether R5 is real

Notice that every surviving signal is about subtraction: what got rejected, what did not escape, what got smaller. Subtraction is not an aesthetic preference, but a consequence of which half of the work got automated. Production did, so the human contribution shows up in the gap between what got produced and what shipped.

8 30 minutes

Running a calibration

Quarterly, thirty minutes, two people who have actually seen the work. Not a committee.

  1. Name it Each reviewer writes down a rung independently, before discussing. Simultaneous reveal. Anchoring is the main failure mode of every calibration ever run.
  2. Produce it Whoever claims the higher rung produces the artifact for it. Not a story about the person, the artifact: the pull request, the deleted rule, the reversed scope call.
  3. Disagree If no artifact appears, the lower rung wins. This is uncomfortable, and without it the ladder drifts upward every quarter.
  4. Write the gap One sentence: which artifact is missing, and what work would produce it. The person leaves knowing what the next rung costs.
Two hard rules

Never calibrate a person against another person, only against the artifact list. And never run this in the same meeting as compensation. The moment a rung is worth money, people start manufacturing the artifacts and the whole instrument goes blind.

9 Both ways

Rungs are held, not earned

A rung describes what someone is doing now, so it is not a possession, and it moves down as well as up.

The common regressions are specific and recognisable. An R4 who has not deleted a rule in a year has drifted back to R3 with extra paperwork. An R2 who stopped rejecting agent output during a hard quarter is not R2 any more, whatever the tenure says. And an R5 who has said yes to everything since the reorg is doing a different job now. It may be a fine job, but the ladder should say so.

Say it plainly, early, and reversibly. A rung is not a title, does not appear in anyone's email signature, and does not move compensation on its own. That is what makes it safe to move a rung down. Being safe to move down is the entire reason it means anything when it moves up.

The failure this prevents

Ladders that only ratchet upward produce teams with six senior engineers and no last check. Agent-written code punishes that shape fastest.

10 Non-goals

What this is not, and how to fork it

Four things this is not for, and one thing to keep if you rewrite it.

  1. Not comp Compensation is a market question, where this is a trust question. They correlate loosely and coupling them destroys the instrument, as covered in §8.
  2. Not a diff grade Use the Comprehension Standard for that. It grades changes, deliberately, and says so.
  3. Not a hiring rubric Every artifact here takes months of observed work to produce. An interview cannot see any of them, and pretending otherwise produces a bad interview.
  4. Not a headcount plan A team needs people at every rung. A team of five R5s cannot ship, and would be an expensive way to discover that.

Fork it freely. Rename the rungs to match your vocabulary. Cut R5 if your team has no scoping authority, and add a rung if this one misses a layer. Keep the axis: one question, asked about larger and larger things, answerable by looking at what stops with this person. The moment people describe a rung with adjectives instead, it has become unfalsifiable and it will drift.

Where to start

Take one person and answer the single question honestly: what is the last thing that stops with them? Most teams find at least one person whose real rung and assumed rung are two apart. And the surprise runs upward roughly as often as downward.