Writing the code was the thing many senior engineers were valued for, and it is no longer scarce. What survives is judgement: choosing under real uncertainty, owning it in writing, and being followed by people who do not report to you. That shift is moving faster than most promotion rubrics have been rewritten, which is exactly where the opportunity sits.
This is the written version of the lesson's material, put together afterwards from the lesson's own published objectives and the takeaway repo. It is not a transcript and it does not claim to reproduce what was said on the night. Where a number appears, it comes from running the repo, and the source ledger sits in this page's HTML.
Open the document you keep for review season. Count the sentences that describe a choice you could have made differently. In most people's, and this includes strong people's, that count is zero.
Shipped the checkout refactor. Led the migration. Improved p95. Mentored two engineers. Every line true, every line a description of work that occurred.
Someone who was not there, deciding in twenty minutes, against six other candidates. They cannot see the work. They can only see the page, and the page has no choices on it.
This is not a claim that code stopped mattering. It is a claim about scarcity. When the typing gets cheaper, the price of the typing falls, and whatever is left holding the value is what you get paid and promoted for. What is left is choosing under uncertainty, and being accountable for that choice in writing.
The repo ships the rubric as a script. It does not judge whether your decision was any good, because nothing can tell that from a text file. It checks that the page carries what a reader who was not in the room needs.
It still raises a warning on a document it passes. A checker that only ever prints red is not a tool, it is a mood, and one that never prints anything is a rubber stamp.
$ node --experimental-strip-types \
scripts/check.ts examples/worked-example.md
examples/worked-example.md
warn placeholders 4 unfilled <placeholder> slots left.
PASS 1 warning, 0 problemsSix delivered projects with no rejected options describe someone who executes. One decision with two rejected options, priced, describes someone who was trusted to choose. The second is the definition of the level, and it fits on one page.
Outcomes are contaminated. Good quarters happen to people who chose badly, and bad quarters happen to people who chose well, and everyone in the room knows it. So the thing a reader is actually reaching for is the distance between what happened and what would have happened otherwise.
The other branch. Without it there is no gap to measure, so the reader has nothing to attribute to you and falls back to volume, which is the criterion that just stopped counting.
It is the only section that survives a project going badly. "I chose X over Y, here is what Y would have cost, and here is what I got wrong" is a promotable entry about a failure.
The weak example in the repo is not a strawman. Helped, supported, contributed to, was involved in: these are what modesty sounds like in writing, and modesty in a packet reads as absence.
why each one costs you → examples/what-the-checker-caught.md$ node --experimental-strip-types \
scripts/check.ts examples/weak-example.md
examples/weak-example.md
FAIL rejected-option No "Rejected:" option.
FAIL a-number No number with a unit anywhere.
FAIL named-influence Who I moved is too thin. Name the
teams, and name the thing they read.
FAIL weak-verbs 7 proximity verbs (helped, worked
on, was involved in, supported,
assisted, contributed to).
warn counterfactual One clause. Say what would have
broken, for whom, and when.
warn length 149 words. Under 200 usually means
the uncertainty is missing.
4 problems, 2 warningsIt cannot tell whether a decision was good. A well-formed entry about a bad decision passes; a badly formed entry about an excellent decision fails. That second case is the whole reason the template exists, and it is also the reason the tool is not a judge.
| The thing you produced | Does it work when you are not in the room? | Why |
|---|---|---|
| Decision record naming the irreversible operation | Yes | Somebody else quotes one line of it in a review you were never invited to |
| A benchmark with the method written down | Yes | It settles the argument again, next quarter, without you |
| A migration guide someone followed without asking you | Yes | Silence is the evidence. Nobody had to ask |
| A long comment on a pull request | Rarely | It dies with the branch and is unfindable within a month |
| Agreement in a planning meeting | No | A meeting cannot be read by somebody who was not in it |
| A strategy deck with no decision in it | No | It is read once, admired, and never cited |
By the time the packet is due you know how everything turned out, so the uncertainty is gone and you cannot reconstruct what you did not know eleven months ago. That missing uncertainty is exactly the part that proves it was a judgement call.
Not your biggest project. The one where a reasonable person would have chosen differently, and you had to pick anyway. If you cannot name what you rejected, pick another one, because that one was a task.
Node 22.6 or newer and nothing else. Three templates, two worked examples, the executable rubric, and a runbook that goes from a blank file to a finished entry in forty-five minutes. Your own entries land in a gitignored folder, so a real packet never leaves your machine by accident.
Not the project. The fork. One sentence: what you chose, and what you chose against. If the second half is hard to write, that is the finding, and it is a more useful finding than any slide here.
Clone the repo, run the checker on the two examples, then fill the template on one real decision. Forty-five minutes, tonight, on something you already did.
Then reply and tell me about the one you tried to write up and could not, because the rejected option would not come. Those are the interesting ones, and they are usually the difference between a career that stalled and one that was never written down.
If this is the shape of the problem you are hitting, From Senior to Staff is a live cohort of it. Small and capped.