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 knew every topic of her team very well, in breadth and in depth: the business processes, the technical systems, and how both fit together. What impressed me even more was that she anticipated the implications of her own decisions far beyond the boundaries of her department. She knew which neighboring team would be affected, which downstream process would break, and which historical exception would cause trouble.

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

She retires in a few years, and currently there’s no successor in sight with comparable experience. The internal candidates are strong people with a lot of knowledge about their own domain and maybe the ones next to it, but they don’t have the whole picture yet.

I am seeing several of these cases at the moment. A generation with a lot of experience is about to retire, and no equivalent replacement has been built up.

So which options does a company have in this situation, and what can AI contribute?

What Is Leaving

Before we look at the options, we should be clear about what is leaving, as otherwise the discussion about AI goes in the wrong direction later on.

The facts are not the problem. Most of them are in some system, documented badly, but documented. What leaves with her is the ability to trace a planned action through the whole company within seconds and name the consequences. This ability isn’t stored anywhere and has never been written down, and it’s the one part of her job which nobody else can do.

Option 1: Build a Successor

The obvious thing to do is to build a successor. To see what this requires, let’s look at how she got where she is today.

She has spent a career of more than forty years in one industry, at her current employer and at similar companies. She learned the job from the ground up and worked in every part of the business in different roles, so that she got to know the operational routines as well as the technical solutions which support them. What I find most important: she saw the handover points between departments early and often. As she stayed in the same company and kept in touch with her former colleagues, she was able to run cross-departmental initiatives while she continued to build deep expertise in whatever her current job was.

This combination requires a lot of time and curiosity, a good memory, and the ability to spot patterns and to switch between the abstract view and concrete details whenever needed.

So even if you find a person with these traits, they need decades to gain the same experience, and by then they will be close to 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 had a comparable career. People like this are usually at an age where they expect a high salary.

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

Option 2: Spread It Across Several Shoulders

This leads to another question: does one person need to have all this knowledge at all?

What if each team builds up the full knowledge required within its own department, and only a rough understanding of the neighboring departments, with more detail at the direct interfaces? This is the normal case in most companies, after all. Organizations cut their teams in such a way that a single person can understand the challenges of the department without being overwhelmed. In addition they create cross-cutting roles like process management, enterprise architecture, compliance and security to understand the connections across departments. Each of these functions looks at one dimension of the company across all departments, and in return does not know the rest of what happens inside of them.

If this is normal everywhere else, is it really worse here? The successor is then no longer a single person, but a function: the new team lead plus process management, enterprise architecture, compliance and security, who replace the old role together.

The advantage is obvious: there’s no bus factor of one anymore. If the current team lead gets hit by a bus, she leaves a huge gap. If the knowledge is spread across many heads, the company can cope with one person leaving.

The disadvantage is mentioned far less often. What she did within seconds now takes three meetings. Coordination costs time, and you lose this time at the very moment when someone is about to take a decision. In addition no single person is accountable for the whole picture anymore. She was able to spot an implication because all the pieces were in one head. Once the knowledge is distributed, an implication is only spotted if the interfaces between the roles are designed on purpose: who is asked at which point in which process, and before which kind of decision. This is organizational design work, and redrawing the org chart won’t do it.

Option 3: Support This with AI

At this point most succession slides show AI as the third bullet, and I am afraid I have to disappoint some people here.

I see three things AI is good for today. Let me check each of them against our problem.

Efficiency

AI recognizes patterns which people would otherwise analyze by hand, and it does this much faster. As a result you get the same output with fewer people, or more output with the same number of people. This does not help in our case. Nobody did this work slowly. One person did it, and soon nobody will do it at all. You can’t make a capability more efficient if the capability itself disappears.

Doing Things Which Were Not Possible Before

Many things cannot be done without AI, as a person would have to read, understand and relate too much data. Recognizing patterns in huge amounts of data isn’t a problem for a machine, and this is how medicines get developed for diseases which couldn’t be treated before. This does not help either, as we don’t have a data volume problem. The relevant knowledge doesn’t sit in a system where it could be analyzed. It sits in a head.

Predicting the Future

I want to know what effect my actions will have. What follows if I do a)? What if I do b)? Which action is the right one to reach goal c)? This is what she did in that meeting, so this category matches our problem one-to-one. Unfortunately it’s also the category where AI delivers the least today, as the input is missing.

So the one category which fits is also the one which can’t deliver, and the reason has nothing to do with the quality of the models. The following table summarizes this:

Can AI Not Read Everything We Have?

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

Some of it is, and what you get is a better search than you had before, which is worth having. Yet, a better search is not judgment. What these sources don’t contain is the why: why the handover between two particular departments looks the way it does, which exception exists for which historical reason, and which change looked sensible, broke something badly years ago and has been avoided ever since. Nobody wrote this down, as everyone involved knew it already. And the person who still knows it is about to leave.

The Problem Is Elicitation

This changes what you should do.

She cannot tell you what she knows, as she is not aware that she knows it. Her knowledge isn’t a collection of facts she could list. It’s triggered by a concrete situation: she sees a proposal, and something about it doesn’t feel right. This is why “please write it down before you go” fails so reliably, and why a review meeting works.

So a documentation project won’t help you much. You need to elicit the knowledge, and for this you need a stimulus.

An Old Practice Becomes Cheaper

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

This worked, but it was slow and expensive. Therefore it was only done for a few roles, and only once in a career. The practices below follow the same idea. What changes with AI is the cost of each step: creating the drafts, transcribing the sessions and turning them into decision records. This makes the old apprenticeship model realistic for more roles, in less time, and more often. And companies need it more often, as people change their employer every few years today instead of once in a lifetime.

Four Practices

Use a Wrong Draft as a Probe

Show her an artifact which is plausible, but wrong in some places. The error triggers the correction. She will fix a diagram within ten minutes which she would never have written in six months.

This is where AI helps a lot, although it’s not very glamorous: from what is already in your systems, a model creates a half-correct process map, dependency list or interface description at very low cost. Creating such assumptions with an LLM is so easy that I would start with this practice. As a draft costs almost nothing, you can do this fifty times instead of three times, and this makes the difference between a series of workshops and getting the knowledge out.

Collect the Questions and Their Answers

When she reviews a draft, she runs through a checklist in her head. Who else reads this field? Has anyone talked to logistics about the cut-off? This checklist is much smaller than her knowledge, usually twenty to forty questions. And unlike the knowledge itself, it can be handed over, to a successor as well as to a model. I write down both: the questions, and the answers she gives in the concrete case.

Route Decisions Instead of Scheduling Knowledge Transfer

For the next two years, every decision above a certain threshold goes through a pair: her and a named second person. I would not do this in workshops, as only real cases trigger the knowledge. Let AI transcribe these sessions and structure them into decision records. The minutes aren’t the valuable part here. After eighteen months you have a collection of cases together with the reasoning behind them, and this is the input which was missing in the third category above.

Document the Rule Together with Its Exceptions

A rule is often written down somewhere already, while its exceptions and the reasons why they exist aren’t. I document both in one place, as an exception is an extended rule anyway.

What AI Can Do Afterwards

With a collection of decisions and their reasoning, a model can look up whether something similar has come up before, and it can flag when a new proposal touches a field or a process which an earlier decision marked as delicate. This is the machine version of her saying “hold on, this affects logistics”. It is useful, and you can get there.

What the model won’t do is judge who needs to be called, and whether now is the right moment to raise the topic. Keep this in mind, especially when you present the idea to a board.

How Much Time Do You Need?

Realistically you need eighteen months, while she is still with the company. If you only have six months, don’t try the full program. Take the list of questions and the twenty most important decisions, and let the rest go.

A consulting contract after retirement, for a year or two, is cheap and underrated. But it only works if she has a defined role as a reviewer. If you use her as an emergency hotline, the transition never happens.

Or: Need Fewer Handovers

You can look at all of this from another angle, too. If every handover is expensive, you can try to have fewer of them. A company which keeps its people for decades gets the old apprenticeship model almost for free, as there’s time to work side by side, and the successor has usually been in the company for years already. From this perspective retention is more than an HR topic. It is a knowledge strategy, and with it the slow, old approach can be as good as the AI-supported one.

Yet, it has limits. Fewer handovers aren’t zero handovers. Someone who stays for forty years is 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 get a bus factor of one in the first place. And it only works if people want to stay, which is less and less the case.

So I would not choose between the two. Keep people longer where you can, as this buys you time and trust. And make handovers cheap anyway, as the last one will come.

Reduce How Much Judgment Is Needed

There’s a third angle, which is a different approach altogether. Part of her tacit knowledge only exists because your architecture has undocumented coupling. She has to keep everything in her head, as the dependencies are documented nowhere else. Every dependency you turn into an explicit interface contract is knowledge nobody has to carry in their head afterwards.

Yet, this is a reorganization and architecture project, and usually it’s independent of the retirement of a single person. So I wouldn’t plan it as part of a handover. It takes time, but it makes the problem smaller instead of distributing it differently.

Conclusion

There’s an old distinction between a forecast and a prophecy: a forecast needs data, while a prophecy doesn’t.

Companies want a forecast. Yet, if someone offers you a system which tells you the consequences of a decision in a company whose dependencies have never been written down, I would call this a prophecy, no matter how good the user interface looks.

So what can you use AI for in this situation? I would not use it to replace the judgment which is leaving. I would use it to make getting this judgment out of one head cheap enough, so that it gets done: by creating the drafts which provoke the corrections, and by turning eighteen months of real decisions into a record which is still there when the person who took them has left.

So the organization comes first and the tool second. Writing the knowledge down has always been the work, and AI hasn’t changed this. But it has made this work a lot cheaper, and it gives you something to use the result for.