Team Systems
Key Person Dependency: The Rest Is on Loan
What a business can do is what it can do without its key person. The rest is on loan, and the loan gets called at the first handoff.

September 25, 2026 · 8 min read

Take your hands off and watch what stops.
Last issue ended on a promise. I said this one would be about what it costs when the place that holds the answers never gets built, and that the cost would be a price and not a feeling.
A price has somebody who pays it and a day it comes due. So before any argument, the payer and the day. The one I know best was paid by a successor, on the day a man retired. I was the successor.
There is no dollar figure in this issue, because I do not have one I can source. What I have is who paid, when, and what it was paid in.
The price, without a dollar sign
This is the second of three issues on one argument: an operation comes to depend on a single person without anyone deciding it should. Last issue was how it happens and the way out. This one is the stake.
What the business can do is what it can do without that person. The rest is on loan from him. A loan gets called, and this one gets called at the first handoff: a promotion, a succession, an illness, a sale. The sale is the one people picture, and it is only one of the four.
Nobody bought anything in the story below.
The man who was retiring
I took over an operation from a leader who was retiring.
The operation was performing. His retirement date had been known well ahead, so none of it was sudden. The overlap between us was still short.
Nobody handed me a binder. There were no written rules for how the place made its calls. I had assumed there would be. An operation running that well, I assumed the logic behind it was written down somewhere.
It was not written down anywhere. It was in him.
He had been the tiebreaker. When a call could go more than one way, it went to him and he settled it. Then he retired, and the same questions came to me.
Each of those questions was really one question underneath. What is this operation optimizing for. Every tiebreak he had made was a small answer to it, and the answers had never been collected in one place, because for as long as he was there they did not need to be. He was the place. When he left, the record of what the operation had been optimizing for left with him.
That is the price, and that is who paid it. What I was handed was the part of the operation that could run without him. The part that could not run without him retired when he did, and putting it back fell to whoever sat in the chair next.
It was paid in time. What the strategy was. What the projects were. What the initiatives were. And under each one, the reason we were doing it, written down. That took somewhere between six and twelve months. The job did not wait while I did it. It still needed its forty hours a week, so the weeks ran to sixty and seventy.
There is a simple way to put a figure on that: those hours, times whatever the chair is paid. I am leaving the figure out. The hours are the point, and they came out of the successor. Until that work was done there was no time for anything further out than the firefighting in front of me.
None of this is a complaint about him. An operation that performs with its logic in one head has no reason to write the logic down while that head is in the building. Everything works. The day it stops working is the day he is no longer there to be asked, and by then the only person who could have written it has gone.
The belief I walked in with was the wrong one. I took performance as evidence that the logic was on paper. Performance was only evidence that the logic existed.
Organized to capture
My book has a question built for this, though the book asks it about something else.
Chapter 5 runs a test called VRIO on a company's resources. Is the resource valuable, is it rare, is it costly to imitate. The fourth question is the one that matters here: is your organization structured to capture the value. The book says this is where many companies fail despite having strong resources. You can have something valuable, rare and hard to imitate and still get no sustained advantage from it if the organization is not set up to exploit it.
It lists four ways an organization fails that question: siloed structures, misaligned incentives, lack of systems, and cultural resistance. Lack of systems is defined as no process, infrastructure, or platform for scaling or deploying the resource across the organization. The example is Google's data-driven HR, which pays off only because Google is organized to capture it. Put the same analytical capability inside a culture that trusts gut instinct, the book says, and "the resource would be wasted."
The book applies that test to a company's resources. It never applies it to the leader. What follows is my extension.
Run the four questions on the man who was retiring. What he knew was valuable. It was rare, because nobody else had it. It was hard to copy, because it had been built one tiebreak at a time. Three questions passed. The fourth failed completely. The operation was organized to use what he knew, every day, by asking him. It was not organized to capture any of it.
Using and capturing look identical while the person is present. An operation can use a capability daily and hold on to none of it. Use requires him in the building. Capture means it is still there after he has left.
The same chapter describes a failure mode it calls Operational Quicksand, and one of the symptoms it lists is that you feel indispensable because only you can solve certain problems. That feeling reads as a measure of value. It is closer to a measure of how much of the operation is on loan.
Three ways the bill arrives late
There are three common responses to all this. Each one moves the date. None of them changes the amount.
Write the procedures. This is the first instinct and it is half right. Steps transfer well. The judgment about exceptions stays behind, and exceptions are what went to him in the first place. Chapter 3, writing about teams that work asynchronously, says most documentation only captures conclusions, so someone reading later can see what was decided but not why. It then lists what good documentation includes: what was decided, why it made sense, what alternatives were considered and rejected, what assumptions or constraints shaped it, and who was involved and should be consulted after. That list was written for async teams and I am borrowing it. A procedure manual usually carries the first item and stops. The tiebreaks live in the other four.
Hire a strong number two. Or promote one. The questions now go to the number two, who learns the logic the way it has always been learned, by being asked. The dependency has moved one chair over. The price is the same and there is a different name on it.
Step back and see what happens. Go quiet for a stretch, skip the meetings, test it. With nothing built, the operation does the rational thing and waits. People hold the hard calls until you are back. The test measures their patience and leaves what they could decide without you untested, because nothing was put in their hands to decide with.
That third one needs a note, because it sounds like the first line of this issue. Taking your hands off is a good diagnostic. It shows you what stops. It does nothing to make it start again.
143 and 29
Challenger, Gray & Christmas track CEO departures. In their 2024 CEO Turnover Report, 143 company founders stepped down as CEO during 2024, against 29 in 2023.
My book cites that in Chapter 1 and reads it as purpose erosion at scale. I am using it differently here: as a count of handoffs.
It counts the event and nothing after it. It says nothing about what happened to those businesses once the founder stepped down, how many had captured what the founder knew, or what it cost the ones that had not. And Challenger's sample is not built around the owner-led operation this newsletter is written for. Do not read a damage figure into it. There is none in it.
What it does show is that the handoff is an ordinary event. It happened to 143 founders in one year and each of them had a date. A retirement has a date. The one in my story did, known well ahead, and the overlap was still short. The date being known did not get the logic written down. Only building the place for it would have.
One move this week
Last issue's move was a tally of what comes to you. This one goes a step further, for one week.
Each time a call comes to you because it could go more than one way, write two lines before you move on. What you decided. The sentence of why. Leave the procedure out. You are after the tiebreak.
At the end of the week, read the whys together, top to bottom. They will tell you what your operation is optimizing for, in your own words, and it may be the first time that has existed anywhere except in you.
That page is the first piece of the operation that would still be there after your own date.
Who pays it
The price of an operation is set by the part that transfers. The difference gets paid at the first handoff. The person who held the knowledge has left by then, so it is paid by whoever comes next, and then by everyone who was depending on the answers.
What I built in that operation belongs mostly to last issue, so one paragraph. I wrote down what we were optimizing for. I tied every metric to sales growth or profitability growth. I put it in a stoplight and communicated it in simple terms on a regular rhythm. It was the binder nobody had handed me, built after the fact by the person who needed it.
The man who retired did nothing wrong. I still paid. Both of those can be true of any operation that runs well with its logic in one head, and that is the uncomfortable part of the stake. Nobody has to fail for it to come due. All it takes is a date.
Next issue closes the argument: why the person at the center of all this is the one least able to see it.
Oscar
Want to see which parts of your operation would still run after your own date? The Resilience Engine Systems Audit maps it: myresilienceengine.com/systems-audit
DIAGNOSE TEAM SYSTEMS
Score the systems your team actually runs on
Ten questions, five minutes. The Systems Audit checks all three layers: personal infrastructure, team systems, strategic architecture. It shows you which one is carrying the operation and which one is running on effort alone.
All 19 frameworks, 175+ research citations from 2024-2025, and the JSON templates live in the book: 112,000 words, digital and print.