The Senior IC Everyone Calls Irreplaceable Is a Risk Built One Decision at a Time

Years ago, one of my team members got married at the Mormon Temple in Salt Lake City. The team had planned for him to be out one week, for the honeymoon. He had been on the critical path for a new technology nobody else on the team fully understood.

A few hours after the wedding, he was hit by a train. He and his new wife survived, but he was out far longer than the planned week. In those first hours after the call came in, relief that he was alive sat right next to a second, uglier realization: almost nothing he had been carrying could be picked up by anyone else. The dependency had been there the entire time. It just took an accident to make it visible. I have been checking for that same pattern in every team I have joined since, including the one I joined three years ago this August, where I found a milder version of it already fully installed: a handful of people who simply knew their piece, with management connecting the dots between them, live, in real time, meeting by meeting.

Every technical leader who has inherited a team like that one has been handed the same three answers. Document it better. Retain the person who holds the knowledge. Cross-train the team so no one is a bottleneck. Almost none of them touch the actual problem, because all three leave one assumption standing: that the person carrying all of it is an asset, and the team is fortunate to have them.

None of that concentration arrives as a decision. It arrives as a long sequence of individually reasonable ones. Under deadline pressure, ambiguity routes to whoever is fastest and most reliable, and each single instance of that looks harmless: this person already knows, so ask them, ship it, move on. What never gets captured is the reasoning behind the call: what was considered, what was ruled out, and what condition would make it worth revisiting. That detail disappears the moment the ticket closes, and it disappears quietly, because throughput never drops. The dashboards stay green. The queue of things only one person can answer just keeps growing behind them.

The organization even rewards it. The person absorbing all of that gets called reliable, gets called the one you can count on, gets called irreplaceable, and every one of those words reinforces the exact routing pattern that created the dependency. Being the destination for every unresolved question reads as status, not risk. That is not a compliment. It is a leader admitting, in public, that they built their best person into a single point of failure and decided to call it loyalty.

The leaders who fix this do not look any different from the ones who do not. They simply stop treating the compliment as a compliment.

What was actually missing, both on that team years ago and at the one I joined three years ago, was a Persistence Layer: the structural mechanism that lets intent, constraints, and the reasoning behind decisions survive absence and time, without requiring one person to be in the room to explain it. I tell the full story of what we built after that accident in Chapter 8 of LeadershipOS™, The Continuity Module, where it becomes the origin of what I call the Train Plan. Build that layer continuously, at the moment a real decision gets made, and the cost of capturing it is close to nothing. Wait for a departure, or a train, to force the reconstruction, and you are paying archaeology prices for something that used to be free.

Pick the last recurring problem that came back after your team thought it was solved. Ask whether anyone besides the person who solved it the first time could explain why the obvious fix was already tried and ruled out, or whether the team would simply try it again if that person were hit by a train tomorrow. If the honest answer is that nobody else could tell you, the Persistence Layer does not exist yet. It is still one person’s memory, and you are one accident away from finding out what that actually costs.

I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS™: http://TheLeadershipOSBook.com

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you're reading this outside the daily email, subscribe free: https://technicalleader.coach/daily-email