The Skill You Can't Put on a Resume — and Why It Decides Who Gets Promoted First

Day 1: Seniority Is a Bet, Not a Badge

You've watched it happen: someone with less experience than you gets promoted first, and you're left wondering what you did wrong. Nothing, probably. You're just measuring the wrong thing. This lesson names what actually gets measured — so instead of waiting years for a title to arrive, you can start moving the real number today.

Same pager, same title, different trust

Two engineers. Same nominal title, same on-call rotation. A severity-1 alert fires for the junior one — and within two minutes, someone quietly joins the incident channel, 'just in case.' The same alert fires for the senior one a week later. Nobody joins. Same pager. Same box on the org chart. Only one of them was actually left alone with it. Whatever separates those two people, it isn't printed on either badge.

The question that bugged me afterward

I went looking for the skill gap that justified it. Mostly, I didn't find one. Both could read a stack trace. Both knew the system cold. What had actually changed wasn't anything you could put on a resume — it was something that happened in the room the last time things broke, and who was watching when it did.

Naming the real variable: blast radius

Blast radius is how much damage you're allowed to cause on your own — and it's set entirely by whether someone already believes you can find and fix that damage without help. It used to mean: can you deploy to prod alone, can you run the migration alone. Now it also means: can you be the human backstop when an agent fleet goes sideways at 2am, can you merge an AI-generated PR with no second reviewer, can you own the rollback when a model swap quietly degrades output for every user on that endpoint. The junior gets a sandboxed blast radius — a flag, a canary, a babysitter in the channel. The senior gets the whole radius, alone, because someone already believes the recovery happens without a spectator.

Why the skill-tree framing fails

It's tempting to picture seniority as a skill tree — system design, mentoring, communication, filling up like an RPG character sheet. That story dies the first time you watch the technically weaker engineer get promoted before the stronger one. What actually happened: someone had already watched the weaker engineer fail small and recover clean. Maybe they broke a staging deploy, caught it themselves, wrote the postmortem, fixed the root cause. The stronger engineer had simply never been watched fail at all. On an AI-first team this plays out constantly — the person who calmly debugged why the agent's auto-generated migration silently dropped a column, in front of everyone, earns more trust than the person who writes flawless code nobody has ever seen them recover from.

The mechanism: trust is a bet, and it's placed on recoveries

Someone senior to you places a bet that you can absorb a bigger blast radius, and that bet is priced off your track record of recoveries — not your track record of not-failing. A spotless record with zero visible failures is actually weak evidence: nobody has ever seen what you do when something breaks. That's why 'I've never caused an incident' doesn't get you trusted with on-call for the LLM gateway, but 'I caused a small one, caught it in nine minutes, here's the fix' does. The bet reads: I believe you'll notice, I believe you'll fix it, I believe you'll tell me — long before it reads I believe you won't fail.

How to start building that bet, starting today

• ▹Volunteer for the failure-recoverable task, not the failure-proof one — the migration with a tested rollback, the prompt change behind a flag, the deploy with a fast kill switch. Recoverable failure is the only kind that builds trust.
• ▹Let people watch you recover, not just watch you succeed. Narrate the incident channel — what you're checking, why — instead of going quiet and reappearing later with a clean answer.
• ▹Make your recoveries visible. Write the postmortem. Post the root cause. Say out loud what you'd do differently. A recovery nobody witnessed teaches your manager nothing about the next bet they'd place on you.
• ▹Reviewing an AI agent's output — a PR, a migration, a config change? Catch its mistake and fix it in the open instead of quietly patching it. That's a recovery too, and people notice it more now, not less, because everyone's still nervous about how much to trust agents.

Close: Day 1 of 30

Tomorrow's lesson only lands once this one has: seniority isn't accumulated through years or scope. It's granted, one bet at a time, by people who watched you recover. This week, find one task with a real but recoverable failure mode. Take it. And when something goes even slightly wrong, fix it out loud instead of quietly. That's the first deposit.

Extend your knowledge

• ▹Read a handful of your team's past incident postmortems. Note who got paged versus who quietly joined 'just in case' — that pattern is the blast-radius map of your team, made visible.
• ▹Look up Will Larson's writing on engineering ladders and 'scope' as a promotion signal, then weigh it against this lesson's claim that trust, not scope, is the gating variable. Decide where you agree and where you don't.
• ▹Read Google's SRE book chapter on postmortems — the 'blameless postmortem' culture is the clearest existing playbook for making recoveries visible on purpose.
• ▹This week, find one failure-recoverable task on your team's backlog — something with a flag, a canary, or an easy rollback — and ask to own it.