Some companies like to be cheap and not hire sufficient number of engineers. Companies are fine understanding redundancy for their hardware and their services etc... They totally failed to grasp it for their employees. That's all fine and good if you're putting in a resignation and giving two weeks or a month notice but often times things are not planned. Family emergencies happen where you have extended times people can be out, grave injuries or death happens or people can just be gone the next day.
So however you plan for those eventualities is the same way you plan for and manage the knowledge transfer on resignation.
How to make this happen? Any software?
employee's perspective: good engineers want to specialise, to gain deeper knowledge, hence resist it (Tradeoff: Expertise vs Breadth)
management's perspective: rotation doesn't work as most companies operate in resource + time crunch, ain't viable to have everyone start from 0 and work on different services (Tradeoff: Speed vs Sustainability)
The reason a good engineer would want rotation between rolls is not because they're seeking to become a given expert in every single aspect but it's because they want to have an understanding of the total picture for the solution. What often happens is when management allows engineers to resist rotation is that they become very highly specialized in their one focused area of the product. Then any problem that comes to them they only see the solutions in terms of their one specialty. As the saying goes when the only tool you have is a hammer every problem looks like a nail. This is a big problem for companies and it's a problem at many companies I've worked at. Because they've allowed highly specialized people to move up into the ranks of senior engineer into team lead roles into even architecture roles due to them being very effective and having a deep knowledge in their one specialty area. As you move up the ladder that deep knowledge works against you because someone brings a problem to you and you can only understand it in the terms of your specialty. When really the correct solution might be across team solution or a solution for another team entirely.
When you force people to rotate rolls into different areas for a limited time it allows them to get a breath of knowledge at an average level so they can determine better solutions. A good engineer understands that and wants breadth of knowledge along with being specialized. This is what allows you to become extremely successful in your career but there's also not many people who are capable of doing that kind of thing.
Consider, for instance, an embedded software engineer, a PhD in computer vision, and a PhD in optics working together on a laser weapon.
In real world, in your example there would be more than one of each - a lot more.
The only hypothetical scenario I can imagine where this could happen is 3 founders in a freshly formed startup.
This is not necessarily the case in military-adjacent R&D laboratories.
Any one-off knowledge transfer will most likely fail. People can't learn actionable knowledge with doing the actions. - That's why we need continuous sharing and doing.
People only look for the artifacts of a knowledge transfer when they need it. When resolving unfamiliar issues, people's first question is: "Has this happened before? How did we resolve it the last time?" It's a simple question but most often its very hard to answer.
The knowledge needed to answer questions like the one above, is mostly manually compiled together and often from memory.
Finally, actionable knowledge is hosted in the same tools as product specs, meeting notes, press releases etc. As a result, creating, finding and following such knowledge is quite hard.
Disclosure: I'm building Savvy(getsavvy.so) to fix a lot of these issues for developers.
You can't do a brain dump of an employee and have it be effective. The key to doing knowledge transfers is to make them unnecessary by making it a built-in ongoing process that people don't even notice.
Can LLMs help do it?
1. Identify dependency areas (using Jira, Github/Lab, Slack etc)
2. Use LLMs to create documentation on #1
3. Get #2 verified by the given employee
[II] For a manager:
1. Dependency score to monitor/track the uncovered dependency of each employee
2. Control to artificially accelerate [I](#2 + #3)
The only way for constant knowledge transfer to exist is to have documentation and collaboration be a core tenet of your organizational culture. It is a social problem, not a tech problem.
-> Most don't even live 1 whole rotation cycle.
-> But they do create substantial dependencies on themselves.