One of the strangest realizations of my career was that being the person everyone depends on isn't the goal.
For a long time I thought it was.
I wanted to be the engineer people called when things broke. The one who understood the weird systems, who could explain why a service behaved the way it did, who knew where the bodies were buried. That feels valuable, and for a while, it is. Organizations need people who can solve hard problems.
The trap is that solving every hard problem yourself doesn't scale, and the ceiling is lower than it looks.
If the system only works because you're there, you are the bug
Here's the uncomfortable thing the indispensable engineer doesn't want to hear.
If the system only works because you're there, then you've become part of the system's failure mode.
Being the single point of knowledge feels like job security. It's actually a liability you've signed the whole team up for. Every "just ask them, they know" is a dependency with no redundancy, no failover, and a pager that's really your phone whether or not it's an official rotation. You didn't build a resilient system. You built one that degrades the moment you step away, which is the exact property we'd call a defect anywhere else. This is the same shape as reliability being an organizational problem: the failure isn't in the code, it's in who the code secretly depends on.
I didn't learn this from a book. I learned it wanting a vacation.
I didn't arrive at this through career advice. I arrived at it because I wanted to take a vacation.
Not a vacation where I carried my laptop. Not one where I checked Slack twice a day. A real one, the kind where your phone stays in the hotel room and nothing catches fire because you happen to be unavailable.
I couldn't take that vacation. And the reason I couldn't was that I'd spent years optimizing for exactly the wrong thing. I'd made myself necessary, and necessary doesn't get to leave. The reward for being the person everyone depends on is that everyone depends on you, forever, which is a strange prize to spend a career chasing.
The definition of success quietly changed
Early in my career, success felt like this:
"When I do my job well, nobody notices I'm there."
Systems stay online. Deployments work. Incidents don't happen. Everything looks boring. That's good engineering, and it's a real skill.
But eventually the definition changed on me:
"Even when I'm not there, people still benefit from what I left behind."
That's a different kind of leverage, and it comes from a different kind of work. The code I wrote started to matter less than the things around the code:
- documentation that answers the question without me
- ownership that's explicit instead of assumed
- architecture that makes the right path the easy path
- runbooks that turn 3am panic into a checklist
- decision records that explain why, not just what
- boundaries clear enough that the next person knows where their problem ends
The higher I went, the less the job was about personally solving every problem and the more it was about making sure problems stayed solvable without me. That distinction is the whole thing.
Two ways to measure an engineer's value
Most engineers measure their value by the number of hard things they can personally do. It's an intuitive metric and it's the one that got them this far, so they keep optimizing it long after it stopped being the bottleneck.
The organizations that actually scale measure value differently. They reward the engineer who removes themselves as a bottleneck. The one who makes the next person successful. The one who leaves behind understanding instead of dependency.
This is the same realization, viewed from the org chart, that experience is compression describes from the inside. The senior engineer's value was never the volume of code. It was the judgment, and judgment only becomes leverage when you distribute it, when "I've seen this break before" turns into a written decision the team carries forward without you in the room.
Why this matters more as code gets cheaper, not less
This is also why I find the AI conversation interesting, and why I think a lot of people are reading it backwards.
Many assume the future belongs to whoever can produce the most code. I increasingly think the opposite. When buildability collapses toward zero and the bottleneck moves off typing, code stops being the scarce thing.
Code is cheap. Understanding is expensive.
A model can write the implementation. It cannot distribute understanding across a team. It cannot create ownership. It cannot make sure the next engineer knows why a decision was made. Those stay human problems, and they get more important as the implementation gets cheaper, not less. The engineer whose value was "I can write it fast" is competing with a machine that writes it faster. The engineer whose value was "I leave behind systems that keep working without me" isn't competing with anything, because that's the part the machine can't do.
Building yourself out of the loop on purpose
If the goal is to not be needed, then a lot of the highest-leverage work looks, in the moment, like working yourself out of a job:
- Write it down instead of explaining it again. The third time you answer the same question, the answer belongs in a doc, not in your head.
- Pair instead of taking it over. Solving it for them gets it done today. Solving it with them means you don't get the next ticket like it.
- Name an owner who isn't you. Unclear ownership defaults to whoever cares most, and being the person who cares most is not a sustainable architecture.
- Leave the why behind. A decision record is you, in the room, for every future decision you won't be present for.
None of that shows up as a heroic save. It's the opposite of a heroic save. It's the quiet work that makes heroic saves unnecessary, which is exactly why it's undervalued and exactly why it compounds.
The point
The most valuable engineers I've worked with weren't the ones who could solve every problem. They were the ones who built teams, systems, and organizations that kept solving problems after they left.
Leverage isn't doing more work yourself. Leverage is making sure the work continues when you're not there. The reward for good engineering was never becoming the person everyone calls. It was becoming the person nobody needs to.
The one-line version
If the system only works because you're there, you're its failure mode, not its hero. The goal was never to be needed. It was to leave behind enough understanding that the work keeps going without you, and your phone gets to stay in the hotel room.