He's the one who, when a PR is clean and green and everyone's ready to merge, says the thing nobody wants to hear. He's in fewer demos. He ships the least. In the hallway version of the org chart — the one that lives in people's heads, not in the HR system — he sits near the bottom. Not disliked. Just not where the status is. The status is on the people shipping the mountain.
He's also the single reason we didn't lose a paying customer's money in March. One comment on a pull request. No code. Just "wait — what does this do if the webhook retries?" And the thing about to ship, clean and green and approved by two other people, would have quietly eaten payments on a bad night.
So the most valuable skill on my team is wearing the lowest status on my team, and the two facts are about the same person. That's not an accident, and it's not a people problem I can fix with a nicer word in a review. It's structural. We spent twenty years building a status ladder where the rung he's standing on is the bottom one — back when that was the right place for it — and then the ground moved and we left the ladder exactly where it was.
Be honest about where status actually comes from in this job. Not the title. The title is downstream. Real status — the kind that gets you listened to in a design review, pulled onto the interesting project, named when people say who's great — flows to the person who makes things. The one with the big merge. The one who shipped the feature everyone's using. The one whose name is on the thing.
That was correct. For most of the history of this job, making the thing was the hard part. Writing the code was slow, scarce, and bottlenecked on the engineer. If you shipped a lot of good code it genuinely meant something: you had the skill, you understood the system, you did the work nobody else could do as fast. So status tracked output, output tracked skill, and skill tracked value. The ladder was honest. The builder deserved the top rung because building was the scarce, hard thing.
And the "no" sat at the bottom for a reason that was also honest, back then. When code is expensive, most of a good engineer's judgment shows up inside the code they write — bundled into the thousand small decisions you can't produce the thing without making. The pure, standalone "no" — the skill of looking at finished work and seeing the flaw — was a small slice of the value, so it got a small slice of the status. Fine. Honest.
Code is cheap now. Not free, not always correct, but cheap — a competent diff for a well-scoped task is minutes of generation, not days of typing. The bottleneck moved. It is no longer "can we produce the code." It's "can we tell which of the confident, clean, plausible diffs in front of us is quietly wrong."
Which means the skill that just became the scarce one — the whole ballgame — is the "no." The ability to look at clean, confident, approved-by-two-people work and say that breaks under a retry, don't ship it.
And here's the trap. Abundance ripped the staple out: judgment used to come bundled into the act of building, and now you can have all the output you want without anyone exercising judgment over it. So the "no" is standing alone for the first time — no longer a small slice buried inside the valuable act of building, but the valuable thing itself.
But its status is still set where it was set twenty years ago, when it was a rounding error. We promoted the skill to most-important and left its title at least-important. We gave our most valuable skill our lowest rank.
The scarce skill now is the "no." Its status is still priced for a world where it was the cheap one.
The builder still gets the status, because the ladder still says the builder makes the scarce thing. But the builder is now leaning on the machine to produce the thing that stopped being scarce, at a scale no human can match. The person doing the actually-scarce thing — reading the mountain, catching the one that loses money — looks, from the top of the ladder, like he's barely working.
Let me make it concrete, because I lived the before-version of this once and it's why I watch for the after.
Years ago, on a different team, I shipped a write path that acknowledged a request before it had actually persisted the row. The code was clean. Idiomatic, typed, tested, reviewed, green. By every measure a dashboard could take, it was a productive, high-quality piece of work, and it made my output numbers — and my standing — look great that sprint.
Then one ordinary day a retry hit at exactly the wrong moment. The "got it" went out, the save never landed, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist. I can still feel the phone call.
Now back to March. Same bug, different seat. The diff in front of us acked the payment webhook before it wrote the row — clean, green, already approved. Two engineers who had shipped a lot that sprint — who had the status — looked right at it and moved on, because it reads fine; you only catch it if something in you is actively asking "what happens on the retry." My low-status skeptic asked. One sentence on the PR. We reordered two lines. Nothing shipped under his name that day — his output for that interaction was negative, he subtracted a line.
That one sentence was worth more than everything the rest of us shipped that sprint combined. And it earned him exactly nothing — not on the dashboard, and not on the ladder in people's heads.
This is the part that makes it worse than the output problem, and the reason it won't fix itself.