How a person quietly becomes the system, and why the better they are the harder it is to see.
Someone new asks how the billing export actually works. Nobody around the table answers straight away. Then someone says it: oh, ask Dave — Dave knows. The question is closed, the meeting moves on, and everyone feels the small relief of a thing that has an owner. It happens a dozen times a week, in every company of a certain age, and it never once looks like a risk. It looks like competence. Somewhere in the building there is a person who knows how the thing works, and when you need to know, you ask them, and it gets handled.
Nothing in that moment is a mistake. Asking the person who knows is the fastest, most sensible thing anyone in the room could do. It is the right move every single time it is made. The meeting got its answer, the new starter learned who to go to, and the company spent a few seconds instead of a few hours. Measured against the moment, it was efficient, friendly and correct.
And that is exactly where the difficulty starts — not in laziness or neglect, but in the opposite. A long series of individually correct decisions can add up to a situation no one would ever have chosen on purpose. There is no carelessness to find, no shortcut anyone should be ashamed of, no point at which somebody ought to have known better. There is only a sentence, said with relief, again and again, until one day it stops being a convenience and becomes the thing the business is quietly built on.
Stay with that sentence — “ask Dave,” and its endless quiet variations — because it holds the whole pattern: how a person becomes the system, not through any failing but through being good and being available, and why the better they are, the harder the whole thing is to see. It is one of the quietest and most expensive patterns in a growing company, and almost nobody names it until the day it names itself.
Look closely at what “ask Dave” actually decides. Each time the answer is to ask the person who knows, a second decision is made silently alongside it: not to write the thing down, not to build the runbook, not to sit a second person beside Dave while he does it. None of those omissions is wrong in the moment. Writing it down is slower than asking. The runbook would take an afternoon nobody has. The second person is busy with their own work, and the question is usually urgent and usually small. Set against the immediate need, asking is plainly the efficient choice, and the alternatives all look like overhead.
But the efficient choice, made honestly and repeated for long enough, adds up. What begins as a convenience hardens, morning by morning, into a dependency. The person becomes a kind of cache for the organisation — the fast, convenient place everyone goes for an answer instead of the slow place it is really stored, always to hand, holding the one copy of something the business now relies on. A cache is wonderful precisely because you never have to go back to the slow original; you just ask the fast thing that already knows. That is its whole value, and also its whole danger: a single copy with no backup is one bad day — a resignation, an illness — away from being lost for good.
The crucial feature of this process is that nobody runs it. There is no meeting where the company resolves that one person will hold the billing export in their head. There is no document that assigns them the role, no moment of appointment, no decision to revisit. The arrangement assembled itself out of a hundred reasonable mornings, each of which was the right call in isolation and none of which was ever weighed as part of a pattern. The organisation optimised locally for speed at every step and accidentally built a global dependency it never chose.
This is why the pattern is so hard to see. The reason is specific: we are good at spotting bad decisions and poor at spotting accumulations of good ones. A bad decision has an author, a date and a visible cost; you can point at it, argue about it, undo it. An accumulation has none of those things.
No single morning was the morning it went wrong, because no morning went wrong at all. The dependency has no birthday. It was never decided, so there is nothing to reconsider, and it never broke, so there is nothing to investigate. It simply became true, in the way the layout of an old city becomes true — not designed, just settled into, until everyone treats the cow-path as the road.
And because every individual step was defensible, the result doesn’t register as a problem. It registers as the normal texture of a working company. A place where things get handled, where there are people you can rely on, where the awkward questions have answers. All of which is real. The dependency hides inside the very competence that built it.
At this point a certain kind of reader will be reaching for a label. This is just key person risk. Bus factor. We know about this; it’s on the risk register. And it is true that the phenomenon has names, and that sensible organisations track it. But the names are part of how the pattern survives. Here is why.
To call it “key person risk” is to file it as a known category of thing — a line in a register, a box that gets a colour, a quarterly review item alongside supplier concentration and cashflow. Filing it that way does something subtle and unhelpful: it converts a live, specific, human situation into an abstraction that has already been handled by being named. The register says “key person risk: mitigated — succession planning in progress,” and everyone moves on, reassured, while Dave goes on being the only person who can run the export. The label gives the feeling of having dealt with the thing without the substance of having dealt with it.
“Bus factor” does something similar, and slightly worse, because it is a number. To say the bus factor is one is to turn a person — with a name, a routine, a holiday they keep postponing — into a metric that can be filed and forgotten. A number invites you to compare it to a target and feel bad or fine accordingly; it does not invite you to go and look at what one particular person actually holds, or to imagine the specific Tuesday on which they are unreachable. The phrase launders the human shape out of the risk so that it can be managed in the abstract, which is to say not managed at all.
The deeper trouble with all of these framings is that they treat the risk as a discrete object you could choose to address — a known unknown sitting in a list, waiting for a mitigation. But the situation we are describing behaves nothing like an object — it is a relationship, and a continuously renewed one. Every time someone asks Dave instead of building the runbook, the dependency is reinforced and deepened, today, in the course of ordinary work. It is not a thing that happened once and now sits on a register; it is a thing that is happening, quietly, every day, in the same motions that make the company feel healthy. You cannot put it on a list and leave it there, because the list does not stop the next person asking Dave tomorrow.
So the generic framings are not exactly wrong. They are just too comfortable. They let an organisation acknowledge the risk in the abstract while continuing, in the concrete, to build it. The whole of the difficulty lives in that gap — between the box ticked on the register and the export that still only one person can run — and no amount of naming the category closes it.
Here is the part the labels miss, and it is the heart of the matter. From the outside, capability and dependency are indistinguishable.
A person who is exceptionally good at something, and a person the business cannot survive without, look exactly the same on every ordinary day. Both answer the question when it is asked. Both make the thing happen. Work flows past either of them at the same speed, with the same ease, leaving the same impression of a job well held. There is no test you can run on a normal Tuesday that tells the two apart, because on a normal Tuesday there is no difference between them. The difference is entirely a property of a day that hasn’t happened yet — the day the person isn’t there — and until that day arrives, there is genuinely nothing to see, because there is genuinely nothing going wrong.
This is what makes the pattern so unlike the risks organisations are trained to catch. Most risk announces itself as a gap between how things should be and how they are: a failing test, a missed number, a process that errors. Here there is no such gap on any ordinary measure. The work is good. The person is good. The results are good. The exposure is not a flaw in the present; it is a fragility in the future, and the present gives no reading of it at all.
And so the same quality faces in two directions at once. The reputation that makes someone the obvious person to ask — reliable, knows it cold, just go to them, it always gets done — is precisely the reputation that makes them load-bearing. Those are not two facts in tension that a good manager might balance. They are one fact seen from two angles.
The trust is the dependency.
You do not get the reassurance of “ask Dave” without also getting the exposure of “only Dave,” because the reassurance is built out of the exposure. The thing that makes you comfortable is the thing that should worry you, and it is the very same thing.
This produces the genuinely counter-intuitive turn, the one that the generic framing can never reach. The better the person is, the more invisible the risk becomes. A mediocre employee who was a single point of failure would at least generate friction — mistakes, delays, the occasional dropped thing — that would prompt someone to ask how this came to depend on one person. Excellence removes that prompt. The more smoothly everything runs, the less reason anyone ever has to look underneath it; the absence of trouble reads as the absence of risk, when in fact it is the risk doing its best work. Competence doesn’t reduce the dependency. It conceals it, and it conceals it in direct proportion to how good it is.
A system that works and a system you understand are not the same thing. The same is true of a person. A function that runs and a function the business actually owns can look identical for years, and the gap between them is invisible right up until it is the only thing that matters.
The clearest version of this I have seen wasn’t dramatic at all, which is the point. A company believed an overnight job was automated — a solved problem, and one that had been solved for a long time. And it was automated; the job genuinely ran on a schedule, without anyone touching it. But every morning, before anything else, a senior engineer quietly checked that it had completed correctly. He did this because once, long before, it had failed silently — produced no error, raised no alert, simply done the wrong thing quietly — and that particular failure mode had never been fixed. It had only been remembered, by him. So the automation existed, but the trust didn’t, and the gap between the two was filled by one person’s morning routine.
From the outside, that process was clean, modern and unattended: an automated job, ticking over, no human in the loop. In reality it rested on one person’s habit, one person’s memory of an old failure, one person being at his desk each morning to look. Nobody had decided to build that dependency. Nobody had even noticed building it. They had simply, sensibly, never taken it apart — and on every ordinary day, the difference between “automated” and “one man and his coffee” was exactly nothing. The difference only existed on the morning he wasn’t there, and that morning had not yet come.
The billing export and the overnight job are two instances of one pattern, but the pattern wears different clothes in different corners of a company. Part of why it stays hidden is that each version is held by a different person, noticed by a different team, and filed under a different heading, so no one ever sees that they are the same shape. It helps to recognise the common forms.
There is the morning check — the one we have just met. A process is technically automated, technically monitored, technically fine, and yet someone has wrapped themselves around it: a glance each morning, a known exception they wave through, a retry they know usually works. The dashboard says the job is healthy. The real behaviour includes the person and their routine, and the person is invisible on the dashboard precisely because they are reliable. The tell is the small gap between “this is automated” and “but don’t leave it unwatched,” and the gap is usually defended with the most reasonable sentence in the world: it’s just a quick look, it takes me two minutes.
There is the only reviewer. A particular part of the system — an old pricing module, a fiddly integration, the bit that does tax — has become something only one engineer is trusted to touch. Changes there route to them automatically. Their review is treated as the real gate, and everyone else’s as a formality. This is rarely irrational; it is usually hard-won local intelligence, a team that has learned through experience that here, more than elsewhere, the obvious change and the actual effect are not the same thing. But the intelligence lives entirely in one head and one pair of eyes, and the area has quietly become un-editable by anyone else. The capability is real. The resilience is absent.
There is the relationship. A key customer, a difficult vendor, a regulator — the working relationship with them lives in one person, in a way that no CRM entry captures. They know which contact actually answers, what was promised verbally two years ago, which subjects are delicate and why, how to read the other side’s silence. The account looks healthy on every report. What the reports don’t show is that the account is healthy because of an accumulated understanding held by one human being, none of which transfers with a handover document, all of which leaves on the day they do.
There is the compliance memory. A company is audit-ready, and genuinely so — the evidence exists, the certifications are real, the auditors come and go satisfied. But the evidence exists because one person assembles it, by hand, from a handful of systems that were never built to talk to each other. They know which export to pull, which spreadsheet reconciles against which log, which apparent gap is fine and how to explain it. The audit passes on their understanding, not on the company’s records, and the difference between those two things is invisible for exactly as long as that person is available to be asked. I have watched an arrangement like this hold for years and pass clean audits the whole way through; what I have also watched is the quieter moment, well away from any audit, of someone realising that had that person been unreachable during an audit window, the company could not have reproduced its own evidence from its own systems.
Nothing failed. The audits were passed, properly. It was a near miss that no one ever logged, because near misses of this kind don’t announce themselves — there is no incident, no finding, no red mark, only the belated understanding that the margin had been a single person’s availability all along.
There is the keeper of the why. Somebody remembers the reason. Why the system is built this odd way, why that obvious-looking simplification is a trap, why a previous attempt to fix the thing made it worse. This is the rarest and most valuable form, and the most completely invisible, because the cost of not having it is measured entirely in things that never happen — the bad decisions that didn’t get made, the rakes nobody stepped on, because one person was in the room to say “we tried that; here’s what happened.” When they leave, nothing breaks immediately. The company simply starts, slowly and expensively, stepping on rakes it used to know to avoid, without ever quite understanding why its judgement got worse.
In every one of these the structure is the same. A capability the business genuinely has rests on a single person, the dependency is invisible because the person is good, and the cost is deferred to a day that feels safely hypothetical. They differ only in which corner of the company holds the risk — engineering, or delivery, or the commercial side, or compliance, or the institutional memory — which is exactly why the whole of it is so rarely seen at once. The engineer worrying about the only reviewer and the founder worrying about the key relationship do not realise they are describing the same thing. There is no single person whose job it is to add them up.
Suppose, though, that someone does add them up. Suppose the pattern is seen clearly, named honestly, and understood for what it is. Even then it tends to persist, and the reasons it persists are almost structural — which is why diagnosis alone so rarely fixes it.
Start with the person at the centre of it. The individual best placed to dismantle the dependency is, almost always, the load-bearing person themselves — and they have the least incentive of anyone to do it. This needs saying carefully, because it is easy to make it sound like an accusation, and it isn’t one. Being the one who knows is comfortable. It is a quiet, daily form of security; it is pleasant to be needed, reassuring to be the answer to a recurring question, and quietly validating to be the person the room turns to. Spreading that knowledge to others means making yourself, by precise degrees, less essential — and there are very few people who, without a strong reason, will spend their own afternoons engineering their own replaceability. None of this requires bad faith. It only requires being human and being busy, and the result is that the person who could most easily fix the problem is the person least moved to.
Now look at the business. It has no stronger incentive, because from where leadership sits, nothing is wrong. The export gets done. The overnight job is green. Dave knows. There is no failing metric demanding attention, no customer complaint, no line in the accounts. Fixing the dependency means spending real time and real money now to prevent a cost that is invisible, deferred, and easy to believe will never actually land.
Set against everything else competing for attention — things that are visibly, urgently broken — a problem that is working perfectly well today will lose the contest for resources every single time. Organisations, like people, attend to what hurts, and this does not hurt yet.
So the dependency sits in the exact blind spot where the most expensive problems live: it is something nearly everyone can half-see and no one quite owns. Leadership half-sees it and assumes someone is handling it. The load-bearing person half-sees it and has no reason to raise it. The rest of the team half-sees it and files it under “how things are.” Everyone has enough of the picture to be uneasy if they stopped to think; nobody has both the full picture and the standing and the motive to act. It is a problem distributed so evenly across an organisation that it belongs to no part of it — the gap between model and reality, in its most human form. The gap between how the business believes its knowledge is held and how it is actually held stays open not because it is hard to see, but because seeing it is no one’s job and closing it is no one’s interest.
When the problem is finally acknowledged, the reflex response is always the same: write it down. Document it. Get it out of Dave’s head and into the wiki, and the dependency dissolves. It is the obvious answer, and it mostly doesn’t work, and understanding why is most of understanding the problem.
The first reason is that documentation describes the system as it was understood on the day it was written. The knowledge that makes someone load-bearing is rarely static; it is exactly the knowledge that keeps moving — the new exception, the changed threshold, the workaround for the thing that broke last month. A document is a photograph of a moving thing. The moment it is written it begins to drift away from the reality it describes, and because no one is checking it against that reality — the reality is still in Dave’s head, where it always was — the document quietly becomes wrong while looking authoritative. A confidently out-of-date runbook can be worse than none at all, because it sends the next person down a path the system no longer takes.
The second reason is that the documentation, even when written, is not maintained, and it is not maintained for precisely the reason the dependency formed in the first place. Keeping it current is overhead that competes with urgent work and loses, every time, because nothing is going wrong. The same local optimisation that made “ask Dave” the efficient answer makes “ask Dave” still the efficient answer even after the wiki page exists — the page is slower and possibly stale, Dave is fast and certainly right. So the page rots, everyone keeps asking Dave, and the organisation now has two things instead of one: an undiminished dependency, and a document that lets everyone feel it has been addressed. The feeling of mitigation is itself a cost, because it removes the unease that might otherwise have driven a real fix.
The third reason is the deepest. A great deal of what makes someone load-bearing isn’t writable at all in any useful form — it is judgement: the feel for which changes are risky, the pattern-recognition that says “this looks fine but isn’t,” the accumulated sense of how the system tends to behave under stress. You can write down facts. You cannot easily write down the thing that lets someone look at a proposed change and feel, correctly, that it is dangerous. That kind of knowledge transfers through exposure and time — through someone working alongside the holder until they have built the same instincts — not through a paragraph in a shared drive. Treat it as a documentation problem and you mistake judgement for information that can be handed over — then wonder why the handover never quite takes.
None of this means writing things down is pointless. It means documentation is a tool with a narrow proper use — capturing the genuinely static and genuinely factual — and a long history of being asked to do a job it cannot do. Reaching for it as the answer to a load-bearing person is usually a way of converting an uncomfortable structural problem into a comfortable task, and then completing the task instead of solving the problem.
For all that, the dependency might seem like a risk you could simply choose to carry. Plenty of companies do, knowingly or not, for years. The question is what happens when the deferred day finally arrives — and the answer is that the bill, when it comes, does not come gently.
A dependency like this gives no gradual warning. There is no slow amber light, no period of degradation in which someone might notice and intervene. It is invisible right up until it is an emergency, and then it presents all at once, at the worst possible time and in the worst possible form. The overnight job fails silently on the one morning the engineer is on a plane, and the first anyone hears of it is a customer asking why their numbers are wrong. The key relationship sours in the quarter the one person who understood it has left, and by the time anyone realises why, the renewal is already lost. The pattern of failure is consistent: the first sign that the knowledge lived in a single head is, almost always, the day it leaves the building.
You do not get to discover the dependency in calm conditions. You discover it as a crisis, because the only event that reveals it is the event you were exposed to all along.
There is a cost on the other side, too, and it deserves naming plainly, once, because it is real and it is rarely said aloud. The load-bearing person cannot easily take a proper holiday, because the thing still needs watching and only they can watch it; they are hard to promote, because no one can replace them where they are; and in time they become a bottleneck, every answer routing through them, and are then quietly resented for being a bottleneck they never asked to become. None of this was done to them by anyone. It accumulated for them out of the same reasonable mornings that built the risk for the business — the cost falls on both sides of one arrangement, and there is no villain anywhere in it. That is the whole of the human cost, and it is enough; it does not need a grievance attached to be taken seriously.
Both costs trace back to one root. The dependency is expensive in the way the gap is always expensive: nothing is paid while it builds, then everything is paid at once, at a moment you don’t choose — a correction that was available cheaply for years, and gets taken expensively in the end.
So if the problem is structural, and the obvious fix doesn’t work, what does? Start by giving up the idea that there is a villain here. Nobody did anything wrong; this is what good people and sensible decisions produce when no one is watching the shape of the whole. So the fix isn’t blame, and it isn’t a heroic documentation drive. It is something quieter.
The aim is to get the knowledge out of one person’s head and into how the work itself runs, so that the knowledge is produced and kept fresh by the ordinary working of the thing, rather than filed beside it in a document nobody maintains. The thing in question needn’t be software at all — it might be how an account is serviced, or how the audit file gets built, as much as a piece of code. Take the overnight job, because it is concrete and quick to picture. The fix there wasn’t a rewrite or a wiki page. It was smaller and far more durable than either: make the silent failure raise its own hand — so the system flags the problem, instead of the engineer catching it — then give the job a named owner and drop the morning check within a fortnight. After that, the thing that used to live in one man’s memory lives in the system’s behaviour instead. Nobody has to remember the old failure, because the system now says so itself.
The obvious objection comes straight back from anyone who has worked on a busy team: we already have more alerts than we can read, and we have learned to ignore most of them. One more won’t build resilience — it just adds noise, and noise is the thing teams survive by tuning out. That is true, and it points at the same problem in a new place. An alert everyone knows to ignore is the morning check in disguise. The know-how has simply moved from one engineer’s routine into one engineer’s instinct — the instinct for which warnings are real and which to wave through — and that instinct is every bit as load-bearing as the check ever was. A new starter facing forty firing alerts, with no idea which one matters, is exactly where we began: leaning on the single person who knows.
So the point was never to add an alert. It is to take the one piece of judgement the person is making — this firing is fine, that one is the real failure — and build it into the system, so that what fires is rare, specific, and worth acting on. Done well, someone who has never heard of the original failure would still know to respond. Fewer signals, and truer ones. The system goes quieter — but quiet because it only speaks when it means something, not quiet because everyone has stopped listening. A warning only the expert can read hasn’t moved the knowledge anywhere. It has just given the dependency a notification.
More generally, the move is to arrange things so that whatever is “handled” stops depending on one particular person being in the building. Sometimes that is automation that genuinely earns the trust it claims. Sometimes it is handing the next real change to a second person — the holder beside them, reviewing rather than typing — so the knowledge passes through the hands doing the work: one change, and two people have walked the path. Sometimes it is shaping the work so the knowledge spreads as a by-product of doing it: pairing, rotation, sharing out the awkward jobs nobody else touches. The mechanism varies; the principle does not. Good leadership is, in large part, the steady lowering of how much of the system has to live inside any single head.
None of this means making everyone interchangeable, or taking the satisfaction out of being good at something. Expertise is not the enemy; expertise that lives in only one person is. Nor does it mean tearing out every dependency at once — that would be its own kind of waste. It is a habit more than a project: noticing where reliance has quietly become dependency, and treating your most relied-on people as the sign of where to build resilience next, rather than as a comfort to lean on harder. The goal is a company that could lose any one person and carry on, intact and unpanicked — a long way from a company with no strong individuals, and a long way, too, from one that has simply not lost anyone yet.
Most of this begins not with a tool but with hearing the ordinary sentence for what it is. “Ask Dave” is not reassurance. It is a small map of where the business keeps the things it cannot yet do without — and the names on that map are worth knowing, and acting on, before the day you find out the hard way which of them you could least afford to lose.
And if listening isn’t enough, there is a cheaper diagnostic than any audit, and most companies already own it: send the load-bearing person on holiday — the proper, unreachable kind they have probably been quietly putting off. Not as a trap, but as a test. Two weeks with them genuinely away is the least expensive way there is to find out how much of the business still routes through a single head. The queue that builds while they are gone — the decisions parked under “ask when back,” the questions that quietly waited for their return — is not the sign of a busy fortnight; it is the dependency itself, finally made visible.
I know the shape of this from the inside, and I was slow to read it. For years I dreaded taking leave, because I knew what would be waiting when I got back, and it took me too long to understand that the dread was the diagnosis: the thing I kept meaning to make less fragile was me. Working through that returning queue, one handover at a time, is how the fixing actually gets done.
The hopeful part is that this is among the cheapest gaps a company ever has to close, and among the most expensive to leave alone. A dependency that took years to build can usually be unwound in weeks, because the knowledge is still there, intact, in someone who is still in their chair. Nothing has to be recovered or reconstructed. It only has to be shared before it has to be missed.
That window stays open for exactly as long as the load-bearing person does — which is to say it is open now, quietly, on every ordinary day that nothing goes wrong. The day it closes is the day you would have picked last, and you do not get to pick it. So the time to look is while everything still works and the question feels almost rude to ask: if this person were not here next week, what would we suddenly be unable to do — and who else could we teach before then?
So — ask Dave. He knows, he’s glad to tell you, and by Friday the question is closed and everyone has moved on. There’s nothing wrong with that. Dave is good at his job, and being able to lean over and ask him is one of the quiet pleasures of a company that works. It’s worth noticing just once, though, on some ordinary morning when nothing has gone wrong, that the whole thing balances on a single word nobody ever says out loud. Not ask Dave. Only Dave.