Build for Absence: Why the Best Systems Don't Need You

By 4 min read

Earlier this year I published My Personal Operating Code, seven principles I try to lead by. Of the seven, one gets more questions than the rest:

Build for Absence.

It sounds a little grim, so let me explain what I mean. I’m not talking about leaving. I’m talking about designing everything I touch (teams, processes, projects, and systems) on the assumption that one day I won’t be there to explain it.

I’ve come to believe that is the real test of whether something is finished.

The Hero Problem

Every organization has a hero. The one person who knows how the billing system actually works. The engineer who can get the old server back up at 2 a.m. The project manager who keeps the whole schedule in their head.

We celebrate these people, and we should. But I’ve learned to see a hero as a warning light, not a success story. If the operation depends on one person being present, available, and in a good mood, then it isn’t a system. It’s a dependency.

As I wrote in my operating code: if you’re the hero, the architecture is fragile.

The military understood this long before tech did. People rotate. They deploy, change assignments, retire, and move on, and the mission is expected to continue without missing a beat. That only works because the job is written down, the handoff is deliberate, and nobody’s absence is allowed to become a single point of failure. Continuity isn’t left to chance. It’s designed in.

What Building for Absence Looks Like

1. If It Isn’t Written Down, It Isn’t Done

I said in my operating code that documentation is moral infrastructure, and I meant it. Documentation is how you respect the person who comes after you. It’s how you tell them the truth about the system: what it does, why it was built that way, and where the bodies are buried.

That doesn’t mean a 200-page binder nobody reads. Good documentation is short, current, and written for someone who is tired and under pressure. My rule of thumb: if a capable stranger couldn’t run it from what you’ve written, you’re not done yet.

2. Design the Handoff Before You Need It

Most handoffs happen in a hurry. Someone gives notice, gets sick, or gets pulled onto something urgent, and suddenly two weeks of tribal knowledge have to move into someone else’s head.

Building for absence flips that. The handoff is part of the work from day one, not an afterthought at the end. Ask early: who would take this over, and what would they need? Then build that in as you go.

3. Make Ownership Visible

Ambiguity at the top becomes chaos at the edge. When nobody knows who owns a system, a password, a vendor relationship, or a decision, the gap only shows up when something breaks, and by then it’s expensive.

Every critical asset should have a named owner, a documented backup, and access that doesn’t live in one person’s browser.

4. Practice Being Gone

The only way to know whether something survives your absence is to test it. Take the vacation. Let someone else run the meeting. Step back from the decision and see what happens.

What breaks tells you exactly where your design is unfinished. It’s war-gaming for your own job.

It Applies to Everything

None of this is limited to one kind of work. The same test holds for almost anything you build or lead:

  • A team. Does it keep performing when its leader is on leave, or does every decision wait for one person?
  • A process. Could someone new follow it from what’s written down, or does it live in someone’s head?
  • A project. If the project manager left tomorrow, would anyone know the real status, risks, and commitments?
  • A system. Can someone besides its builder explain it, fix it, or turn it off safely?
  • A relationship. Does a key customer, vendor, or partner know more than one person on your side?
  • Your own life. Would your family know where the important documents, accounts, and passwords are if you weren’t there to ask?

New technology doesn’t change the rule; it just creates new places for the hero problem to hide. A clever script or an AI tool that only its builder understands is just a hero that never sleeps. It works perfectly right up until it doesn’t.

Whatever it is, the questions are the same: Can someone else explain it? Is it written down? Does it have a named owner? Can it keep going without you?

The Uncomfortable Part

Building for absence asks something of us that doesn’t come naturally: it means making yourself less necessary on purpose.

That’s hard. Being needed feels good. Being the one who knows feels like job security. But I’ve found the opposite to be true. The leaders I respect most are the ones whose teams kept performing after they moved on. Their influence outlasted their presence.

As I put it in my operating code: legacy is measured after departure. If everything breaks after you leave, the scale was never balanced.

The Bottom Line

The question I try to ask about everything I build is simple:

Will this still work when I’m not here?

If the answer is no, the work isn’t finished. Write it down. Name the owner. Design the handoff. Test it by stepping away. Then do it again for the next thing you build.

The best compliment a system can earn isn’t that it needed you. It’s that it didn’t.