Your Bus Factor of One Is Retiring: How to Get Forty Years of Judgement Out of One Head

Recently I sat in a meeting with an experienced team lead who demonstrated remarkable command of every topic her team touches, in breadth and in depth alike: the business processes, the technical systems, and how the two fit together. What made the conversation unusual was not the depth. It was that she anticipated the implications of her own decisions far beyond the boundaries of her department. She knew which neighbouring team would feel it, which downstream process would quietly break, and which historical exception would bite.

I left that meeting convinced she can make very good decisions for her company very fast.

She retires in a few years. There is currently no successor in sight with comparable experience. The internal candidates are strong people with immense knowledge, but of their own domain and perhaps the ones next to it. Not yet the whole picture.

I am seeing several of these cases at the moment. A generation with a great deal of experience is leaving for retirement without an equivalent replacement having been built.

What is actually leaving

It helps to be precise about the asset, because vagueness here is what makes the AI conversation go wrong later.

The facts are not what is leaving. Most of the facts are in systems somewhere, documented badly but documented. What is leaving is the ability to trace a proposed action through the entire company in seconds and come back with the consequences. Call it cross-domain implication at speed. It is not stored anywhere, it was never written down, and it is the only part of her job that nobody else can do.

Option 1: Build a successor

The obvious move is to grow a replacement. It is worth looking at how the original was made.

She spent a career of forty-odd years in one industry, at her current employer and at similar firms. She learned the craft from the ground up and passed through every part of the business in different roles, so she came to know the operational routines and the technical solutions that support them. Crucially, she also saw the handover points between departments early and often. Because she stayed in the same company and remained well connected to her former colleagues, she could run cross-departmental initiatives while continuing to build deep expertise in whatever her current job happened to be.

That combination requires a lot of time and curiosity, a good memory, and the ability to spot patterns and switch between abstract view and concrete detail at will.

So even if you find a person with those traits, they need decades to acquire the same experience, and by the time they have it they will be approaching retirement themselves. A short-term replacement is only possible if the candidate has already spent a long time at the same or a very similar company and has run a comparable career. Someone in that position is usually at an age where the salary expectation is demanding.

For most companies, the probability of finding such a person at an acceptable cost is very low.

Option 2: Spread it across several shoulders

Which raises a better question: does one person need all of that knowledge in that form at all?

What if each team builds the full knowledge required inside its own department, and only a rough understanding of the neighbouring ones, with more detail at the direct interfaces? That is, after all, the normal case in most companies. Organizations cut teams so that a single head can grasp the department’s challenges without being overwhelmed, and then create cross-cutting roles such as process management, enterprise architecture, compliance and security to understand the connections that span departments. Each of those functions works one dimension of the company across all departments, and in exchange does not know the rest of what happens inside them.

If that is the normal case everywhere else, is it actually worse here? The succession is then not a person but a function: the new team lead plus process management, enterprise architecture, compliance and security, together replacing the old role.

The advantage is the obvious one: no bus factor of one. If the current team lead is hit by a bus, that leaves an enormous hole. Distributed across many heads, one person leaving is survivable.

The disadvantage is just as real and gets stated too rarely. What she did in seconds now takes three meetings. Coordination has a cost, and the cost is paid in latency at exactly the moment when someone is about to make a decision. Worse, no single person is accountable for the whole picture any more. The implication she spotted was spotted precisely because all the pieces lived in one head. Distributed, it is only spotted if the interfaces between those roles are deliberately designed: who is asked, at which point in which process, before which kind of decision. That is organizational design work, and it does not happen by redrawing an org chart.

Option 3: Support that with AI

This is where the slide gets a third bullet, and where I would like to be unpopular for a moment.

There are three things AI is genuinely good for today. Let me hold each one against this specific problem.

Efficiency. AI recognizes patterns that people would otherwise analyse by hand, and does it much faster and by machine rather than by human. The result is the same output with fewer people, or more output with the same number. This does not apply here. Nobody was doing this work slowly. It was being done by exactly one person, and it is about to not be done at all. You cannot make a capability more efficient when the capability itself is what disappears.

Doing things that were not possible before. Many things cannot be done without AI because too much data has to be read, understood and related to be tractable for a person. Pattern recognition across enormous volumes is not a problem for a machine, which is how medicines get developed for diseases that were previously untreatable. This does not apply either. It is not a data-volume problem. The decisive knowledge is not in a system waiting to be crunched. It is in a head.

Predicting the future. I want to know what effect my actions will have. If I do a), what follows? If I do b)? Which action is the right one to reach goal c)? This is exactly it. It is a one-to-one description of what she did in that meeting. And it is the category where AI delivers least today, because the input is missing.

So the one category that fits is also the one that cannot deliver, and for a reason that has nothing to do with model quality.

But surely it can read everything we have

The strongest counter-argument is that a model can be pointed at the wiki, the ticket history, the Confluence pages, the code, the meeting transcripts, and that forty years of context is buried in there somewhere.

Some of it is, and the result is a genuinely better search than you had before. That is worth having. But a better search is not judgement. What is missing from those sources is the why: why the handover between two particular departments looks the way it does, which exception exists for which historical reason, which apparently sensible change broke something badly years ago and has quietly been avoided ever since. Nobody wrote that down, because everyone involved already knew it. The one who still knows it is the person about to leave.

The real problem is elicitation, not storage

Here is the part that changes what you should actually do.

She cannot tell you what she knows, because she is not aware that she knows it. The knowledge does not present itself as a body of facts. It is triggered by a concrete situation: she sees a proposal and something in it does not sit right. That is why “please write it down before you go” fails so reliably, and why a review meeting works.

You are not running a documentation project. You are running an elicitation problem. And elicitation needs stimulus.

An old practice, made cheaper

None of this is new. Long before anyone talked about AI, companies handed knowledge to the next generation in a simple way. The person about to retire worked shoulder to shoulder with their successor for a year or two. The successor saw real cases, heard the reasoning behind each decision, and learned what to preserve and what to change once they took over.

It worked, and it was slow and expensive. So it happened for few roles, and only once in a career. The practices below follow the same idea. What AI changes is the cost of each step: producing the drafts, transcribing the sessions, turning them into decision records. That makes the old apprenticeship model realistic for more roles, in less time, and more often. And more often is what companies need when people change employers every few years instead of once in a lifetime.

Five things that actually work

Use a wrong draft as a probe. Put an artefact in front of her that is plausible but wrong in places. The error triggers the correction. She will fix a diagram in ten minutes that she would never have written in six months. This is where AI earns its keep, and it is not glamorous: from what already sits in your systems, a model will cheaply produce a half-correct process map, dependency list or interface description. The cost of producing the draft falls close to zero, which means you can do this fifty times instead of three. That is the difference between a workshop programme and actual extraction.

Collect the questions, not the answers. When she reviews a draft, a checklist runs in her head. Who else reads this field? Has anyone spoken to logistics about the cut-off? That checklist is far smaller than her knowledge, usually twenty to forty questions. And unlike the knowledge itself, it transfers, both to a successor and to a model. It is the cheapest artefact with the highest return, and almost nobody harvests it.

Route decisions instead of scheduling knowledge transfer. For the next two years, every decision above a threshold goes through a pair: her and a named second person. Not a workshop, because only real cases trigger the knowledge. Have AI transcribe and structure those sessions into decision records. The value is not the minutes. The value is that after eighteen months you have a corpus of case plus reasoning. For the first time, that is the input that was missing in the third category above.

Document the exceptions, not the rule. The rule is written down somewhere already. The value sits in the deviations and in why they exist.

Reduce how much judgement is needed at all. This is the unpopular one. Part of her tacit knowledge exists only because your architecture has undocumented coupling. She has to hold the whole thing in her head because the dependencies are nowhere else. Every dependency you convert into an explicit interface contract is knowledge nobody has to carry in their head afterwards. It is slow, and it is the only measure that genuinely shrinks the problem rather than redistributing it.

What AI can do once the work is done

With a corpus of decisions and their reasoning, a model can look up whether something similar has come up before, and flag when a new proposal touches a field or a process that an earlier decision marked as delicate. That is the machine approximation of her “hold on, that hits logistics”. It is useful, and it is reachable.

What it will not do is judge who needs to be called, and whether now is the right moment to raise it. Keep that expectation where it belongs, particularly in front of a board.

How much time this needs

Realistically, eighteen months with her still in the building. If you have six, do not attempt the full programme. Take the question list and the twenty most important decisions, and let the rest go.

A consulting arrangement after retirement, for a year or two, is cheap and underrated. But it only works with a defined role as a reviewer. Used as an emergency hotline, it prevents the transition instead of supporting it.

Or: need fewer handovers

There is another way to look at all of this. If every handover is expensive, you can try to have fewer of them. A company that keeps people for decades gets the old apprenticeship model almost for free. There is time to work side by side, and the successor has usually been in the building for years already. Seen that way, retention is not only an HR topic. It is a knowledge strategy, and with it the slow, old approach can be as good as the AI-supported one.

It has limits, though. Fewer handovers are not zero handovers. Someone who stays for forty years is exactly the case this article started with, and the last handover is the hardest one. Long tenure also concentrates knowledge in fewer heads, which is how you end up with a bus factor of one in the first place. And it only works if people want to stay, which is less and less the norm.

So I would not choose between the two. Keep people longer where you can, because it buys time and trust. Make handovers cheap anyway, because the last one will come.

Conclusion: prophecy or forecast

There is an old distinction worth keeping. A forecast needs data. A prophecy does not.

Companies want a forecast and are frequently sold the other thing. When someone offers you a system that will tell you the consequences of a decision inside a company whose dependencies have never been written down, what is on offer is prophecy with a good interface.

So: what can I usefully put AI to work on here? Not on replacing the judgement that is leaving. On making the extraction of it cheap enough to actually happen. That means generating the drafts that provoke the corrections, and turning eighteen months of real decisions into a record that outlives the person who made them.

Organization first, tool second. The uncomfortable part is that the first step was always the work, and the arrival of AI has not changed that. It has only made the second step worth preparing for.