The Load-Bearing Wall

Indispensable feels like job security. It's the failure mode dressed up as a virtue. Here's why the moat was never what you know.

By Jason Waldrip, with Claude Opus 4.8

It’s 11pm and the deploy is wedged. You already know why. The env var that didn’t get set, the migration that ran halfway, which service to bounce first and which one to leave alone because bouncing it makes things worse. You fix it in twenty minutes. You’re asleep by midnight. At standup you don’t even bring it up, because to you that wasn’t an incident, it was Tuesday. And somewhere under the tiredness there’s a small warm feeling that says they need me. Sit with that feeling for a second. It’s the most expensive thing you own.

Because here’s what that night actually was. The system went down, and the only thing standing between a broken product and a working one was a specific person’s memory. Not a runbook. Not a test. Not a guardrail. A person, awake, who happened to know. That’s not a war story. That’s a single point of failure that pays for its own coffee.

The thing nobody says about being the one who can fix it

Every hour you spend being indispensable is an hour the system spends learning it can lean on you instead of on itself. Your reliability becomes the team’s liability. The better you are at quietly catching things before they become incidents, the less anyone else ever has to learn the thing you know, and the more load quietly migrates onto the one wall holding the most weight.

It looks like seniority. It reads, on a contribution graph, like the most committed person on the team. Underneath, it’s a bus factor of one with a green contribution graph. The org has decided, without ever deciding, that one person being out sick is an acceptable way to stop shipping.

I have been the wall

I walked into Brandfolder to a product going down on a memory leak. For a while I was the person keeping it alive, because in a rescue someone has to be. I could have stayed that person. There’s a version of that job where I’m the hero who knows where all the bodies are buried, paged forever, quietly proud of it.

The actual job was the opposite. Hire and train a team of six so the product’s survival never rode on one skull again. The rescue people remember is the leak. The rescue that mattered was making myself removable from the critical path. By the time it scaled to a hundred-plus enterprise customers, the thing that kept it up wasn’t me knowing the system. It was a team that did, and tracks that held whether or not any one of us was awake.

I learned the principle a step earlier, at iTriage, and it’s the one I keep coming back to: the most durable thing a senior engineer ships is other engineers. I mentored through pairing, not lectures. Every patch I handed someone, I owned forever. Every principle I taught, they owned, and so did the next person they taught it to. One of those compounds. The other one pages you at 11pm for the rest of your life.

The most committed person on the team and the biggest single point of failure are very often the same person. Nobody wants to say it because it sounds like an attack. It’s a compliment with a warning stapled to it.

Solo heroics have a ceiling, and the ceiling is you

There are only so many hours in your week, so many incidents you can personally absorb, so many 11pms before something gives. Go fast alone and you hit a wall that no amount of dedication moves, because the wall is you.

At CommercialTribe we collapsed a release cycle from weeks to hours across an onsite team and a remote team in Argentina. That number is impossible if release knowledge lives in one person’s head in one timezone. It only happens when the capability lives in the tracks, where anyone can reach it. The win wasn’t a faster engineer. It was knowledge that stopped depending on a particular human being available, and started belonging to the system.

What the agent era did to this

For most of my career, being the load-bearing wall was a slow, personal tax. You paid it in sleep and in the vacations you didn’t fully take. Now the tax has a sharper edge, and it’s worth being honest about why.

Volume is free now. You can point a fleet of agents at a problem and they will generate all day without coffee or ego. But a fleet can only act on what’s been made legible. The architecture decision you made for a reason that lives only in your memory, the landmine you route around on instinct, the “we tried that in 2023 and here’s why it bit us” that never got written down: none of it exists to an agent. It can’t reason over what was never written. It will confidently undo the exact decision you’d have fought for in a meeting, because to the model that decision was never made.

I’ve said you multiply judgment by a fleet, never zero by a fleet, because anything times zero is still zero. The load-bearing wall is where the zero hides. Judgment locked inside one skull can’t be multiplied, by a teammate or by a machine, because there’s nothing there to copy.

That reframes the whole “judgment is the moat” idea, and it’s the part I want to land. Judgment is only a moat if it can leave your head intact. The expert whose expertise dies when they log off isn’t a moat. They’re a liability the org has agreed to call a strength.

Make yourself removable

This is not “document everything” busywork. It’s a deliberate move to get the value out of one person and into a place the team and the fleet can both run on. In rough priority order:

1. Write the why, not just the what. A runbook that lists steps is for the human at 11pm. A record of why the system is the way it is is for the human at 11pm and the agent at noon. Capture the decision and the reason you’d defend it, because that’s exactly the context a fleet fills in wrong when it’s missing.
2. Pair, don’t rescue. The fast fix is to do it yourself. The durable one is to teach the principle so the next person doesn’t need you for the next instance. A slow handoff beats a fast fix the second time the problem shows up, and there’s always a second time.
3. Put the knowledge in the tracks. The best place for “don’t do that, it breaks under load” isn’t your head. It’s a test that fails when someone tries. Types, CI, and review are guardrails, and a guardrail is knowledge that doesn’t need you awake to work. Every rule you encode is a 2am page you’ll never get.
4. Measure the bus factor honestly. If one person being out stops a release, freezes a system, or means a question goes unanswered for a week, that isn’t seniority. It’s debt with a name on it. Find the walls. Spread the load before the wall does it for you, at the worst possible time.

None of this makes you less valuable. It does the opposite. The engineer who can hand off everything they know is the one you actually want running the next thing, because their value travels. The one who can’t is stuck being the wall forever, which feels like security right up until it feels like a cage.

Build the thing that stands without you

The goal was never to be the wall holding the building up. It’s to build something that stays standing when you walk out of the room. Indispensable is not the win condition. It’s the failure mode wearing the costume of one.

So ask the uncomfortable question, the real one. If you went fully dark for two weeks, no Slack, no laptop, what breaks? Whatever has your name on it and only your name, that’s not your job security. That’s your backlog. It’s the work you haven’t finished, which is getting it out of your head and into something the team, and the fleet, can carry without you.

I spend most of my time now walking into orgs propped up on one or two load-bearing walls, where the whole thing runs on a couple of people who can never really log off. Turning what’s in their heads into tracks the team and the fleet can run on without them is most of the job. If that’s the wall you’ve become, or the one you’ve come to rely on, that’s the conversation I’m here for.