My most recent example...

A software engineer had given notice, while finishing solo marathon coding on a complicated big new thing that I think no one else had yet seen.

So I (as the new principal engineer, knowing we need a huge brain dump before the info disappears forever) scheduled some of the engineer's remaining time as top-priority, kept on them as their final-week marathon schedule kept shifting, and then recorded interviewing them with a screenshare.

Some of the things I asked could've been scripted questions, like starting with what is the purpose, where is the code, how to I get it all, how do I run it.

Then, scripted questions could ask about walking through the UI, or walking through the major parts.

But pretty quickly, I had to be asking questions that weren't just going through the usual motions, but reflected concerns specific to what was being said, as well as things that I thought were the top priority to understand.

I don't think an "AI" solution that is mostly LLM would have the insights that I did. It would be mostly scripted questions, maybe trying to get a sense of how much needs to be said about each thing in a template, and maybe mimicking things real software engineers have said in the past... but not handling well anything unusual.

Also, human rapport might get better information, or may even get the person to do it at all. Although I was new there, I was a fellow human, with whom the somewhat disgruntled employee had no grievance, and I was asking them to help me out, and investing in it myself. Not HR pointing them at an uncanny-valley robo-debriefer program that the company paid for, as a termination checklist item, and a ritual to perform their way through.

Also, if you have a rapport and some trust, and stop recording, and ask them something off-the-record, they just might tell you things candidly that are important to know, but that they're not going to tell to an app video recording that goes who knows where. And if you can get the candid OTR, those might lead to additional important information that you can officially capture.

A direct result of technical staff leaving is the loss of siloed knowledge, instead of trying to address it at the final juncture, my opinion is that this type of knowledge should be proactively documented and shared with the rest of the team as the domain expert learns/works on it. That way, they're around to mentor other members, reduces the bus factor and when said person leaves, the rest of the team naturally continues their work rather than spending time on ramp up tasks.

A better solution to this problem would be to improve detecting this problem so you can address it in its early stages instead of when it gets bad. One way of doing this is mandatory time off. I don’t recall who said it first, but time off is chaos monkey for people. It’s common in some industries for employees to be forced to take time off to intentionally cause their normal tasks to be performed without them. For instance, banks use it to detect fraud, because the same person doing the same task all the time can make it easy for them to cover crimes up.

If your team is stuck in a rut and the same person is always responsible for doing important tasks every time, this is a risk. If they took some time off, this would help you figure out what knowledge is centralised with them. Don’t put their tasks off and wait until they get back. Figure out how to do it without them. If you struggle, that’s a clear sign you’ll be in for pain when they eventually leave for good and shows you what knowledge they need to disperse.

Btw for larger European companies I think you will have a hard time due to trade secrets and privacy

I find it hard to know where to start, what to include and how to structure. Having a tool to prompt me along the way would be really helpful and I feel speed up the process of ideation and creation of documentation.

Lol, getting interviewed by an AI as your job gets taken by AI.

Apparently I need to move faster. Quitting the day job soon.

A skill cannot be handed over. You can painfully train someone to acquire some of it over time, but certainly you cannot “hand it over”

For example, I am currently transitioning my P&L into a new dept. at a large organisation and the amount of work to onboard into my new manager / team is significant and my weakness in the process is the structure / organisation of my own documentation that allows me to surface the right information to the right people without repeating myself.

Similarly, I've joined new teams (small and large) as a new manager - here you want to quickly get up to speed on lots of projects and how things do/don't join together.

Personally, I would like to describe my situation to the tool about my role and (almost like a user story or 'new manager, existing company' or 'experienced manager, new company) have the tool react to the situation.