Handover.ai – Knowledge transfer made easy | Hacker News Reader

Handover.ai – Knowledge transfer made easy

handover.ai

56 pointsphlcastro48 comments

I think this is a great idea for a product, but in my experience, the pain associated with handover is something that is earned over a long period of time. Knowledge starts to centralise in one person and they don’t do enough to disperse it. Maybe they are too busy, maybe they don’t value documentation, maybe it’s an oversight, there are lots of reasons. But that problem starts to build up and you only discover the full extent of it when they leave and it hits you all at once.

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.

Forced vacations are super common in the finance / wall st industry for this reason.

It's really only a large risk if you don't compensate competitively.

Sports teams constantly "lose talent" because they refuse to pay for it. Suddenly they start losing games..

All this "knowledge lost" is often just talent and experience.

You can lead a horse to water, you can lead a junior to documentation.

I know the manager brigade will take this personally but talent and experience have always carried any workplace I've been a part of.

Compensating competitively might stop somebody from leaving for another job, but it won’t stop them from keeling over dead from a heart attack or getting hit by a car.

You need to plan in advance for people leaving, not just assume they will be there forever.

Or moving, or just wanting a different job. Money helps, but it doesn't solve everything.

I once quit a job and gave them 6 weeks notice because I wanted to try and make the handover as painless as possible. My manager said “stop working today. Come in, check your emails, but don’t do any work. Forward and delegate everything that lands in front of you. Let people who reach out to you know you’re leaving and introduce them to whoever is taking over that particular responsibility. We’re going to have to work out how to do things without you. We may as well start today, safe in the knowledge we’ve still got you in the building for the next 6 weeks if we can’t work anything out”.

You can debate the cost effectiveness of the approach, but there was no doubt that by the end of those 6 weeks they were going to be just fine without me.

That's a really interesting approach. Do you think that was too extreme? Like you could've at least done some documentation work in that time perhaps, or that it went well enough that you'd approach it that way again in the future?

There are two parts on this approach. The 1st one is the positive "hey, chillax, transfer knowledge, don't be stressed, etc." The 2nd is security: "this guy cannot be trusted to 'touch' anything, we don't want him to plant a timebomb, we don't want him to mess things up, etc."

It's not 'polite' to bring up the 2nd, but it _is_ there. Imagine me/you/him/her doing something wrong and bringing down Prod for X hours. Then imagine your manager telling the director "oh, and btw he submitted his resignation 2 weeks ago, and in confidence he told me he goes to our ABC competitor". That-Looks-BAD, even if it was the most honest of mistakes and even someone else's fault. Once you 'stop playing', don't touch that jenga tower!!

Sure, but writing documentation doesn't touch the Jenga tower. :)

I struggle to justify it from a cost and utilisation perspective. Given how well it went, I've run the hypotheticals in my head a few times about what the optimal case might have been. If you discount the cost of my time to zero and you assume the company could mandate whatever period is optimum for them I think the duration ends up being around 2 months. Mostly because we had a monthly billing/invoicing cycle we were part of. So one month as the forcing function to catch and document all the process, and then a 2nd cycle just to make sure you can apply everything you learnt.

My time wasn't at a zero cost though. But... at a high level, given the size of the company I worked for + the potential impact of getting something wrong, ~6 weeks of my time is pretty close to zero from their perspective. It also probably helps that we had pretty low employe churn.

But from my perspective it did feel like a bit much. Within a couple of weeks I was pretty bored. I was itching to help and do things like you suggested such as documentation, but the team saw doing the work of writing the missing documentation being part of the work of learning what the gaps were so I had to stay away. Ultimately I spent most of my time planning the next phase of my life and hacking on side projects, or hanging out in the common areas with my wife and newborn son when they'd come in.

Happened to me back in 2009 and I couldn't believe it. I got paid for 1 month to sit around, drink coffee, answer questions. Then I moved and got a 30% raise.

This 1 month also helped me refresh all my knowledge, go through my notes, etc. "In teaching I learn, and in learning I teach". Having around 100 people asking me questions from all over the 'region' helped me put things back together, see connecting dots that I missed before, and I left there with a new (better) set of notes about myself and how to do things.

I’m the kind of person who is conscientious enough to make a handover document when I go on PTO, and the same traits that make me do that are the reason why I’d never use this. It lacks a personal touch; in fact it’s almost insulting (“I couldn’t be bothered to prepare a handover document so I asked this AI to do a shoddy job of it”). And the whole point of a handover document is to capture top-of-mind priorities that exist nowhere outside of your own head. An LLM won’t fix that (at least in the near-term before we’ve all got brain implants…)

Same on longer PTO doc, because there is always something weird going on that people should be aware of and no one should be able to say 'No one told me.' From that perspective, it is a useful CYA, but in my experience it genuinely helps everyone plan a little better.

That is the reason I think the Handover project has merit. What I personally hate however is the format ( video ), because I can see corporations adopting this out of sheer laziness. In other words, I don't wish this project be adopted by corporate America based on personal preferences, but I can kinda see them jumping on it.

Some larger companies do this in disaster drills or other emergency preparations as well. You give the team the task to stand up a database cluster from scratch and pull a dataset into it - and none of the seniors may be contacted. This is pretty effective at rooting out such knowledge silos. And it can build confidence in the other team members once they manage to do it. The main drawback is that it's just non-revenue generating preventative work.

As an IT/Admin/SRE team, we've also found that training isn't just good for the industry, but it also helps to keep such knowledge islands in check. I currently need to make sure that my junior is able to take over most crucial daily tasks, and in the future, all of my important technical tasks - and he's doing wonderful. Though that's now a staffing thing, which costs money.

In the end, it's a question how sustainable a company wants to be long-term I think.

I run a company with almost 100% of the staff located in Europe. Because of this, everyone has 38 days of PTO with some people taking even more unpaid time off. This means everyone is always out of office. We also have a very significant amount of process documentation, and like you alluded to, means significant resiliency. When someone is gone, the work carries on as normal.

I get the use case, but realistically this type of tool is going to be used by HR right before they fire an employee, or as a step in the process to firing an employee.

... And? Firms are profit maximizers. It's usually good when they fire people.

It would be more useful if it trained on input from the fired person’s whole tenure, e.g. reading their slack messages or something… if the quality of the product depends on cooperation of the person being replaced then it’s gonna be an uphill battle.

Yeah the paradox here is that employees on their way out are less likely to be forthcoming in sharing their knowledge, while current employees aren’t super incentivized to be thorough, as it functionally makes them easier to get rid of.

So the employer either needs to be surveillant and somewhat hostile, taking data from Slack messages etc. Or they need to have a culture which prioritizes documentation as a part of daily routine.

Not really. Employees migrate companies willingly as well. On this idea, its very specific to handover which is a miss I feel. It should be about documenting right from the start, not when someone is leaving the company.

I see this as addressing a symptom rather than the cause.

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.

And all of your secret sauce ends up on somebody else's server.

This has merits, and I don't want to criticize that. But, as a matter of practice, I'd like to suggest, if you have the resources to task another experienced person to do a recorded interview, that might yield better results.

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.

<< not HR pointing them at an uncanny-valley robo-debriefer program that the company paid for, as a termination checklist item

And yet, I think a lot of people in this thread suggest this would likely be the exact fate of this service should it be adopted. And it would be a shame, because lost institutional knowledge is a real issue.

The issue is there is no incentive for the person leaving to make these handover docs and videos. They will just say the bare minimum and complete the task.

The incentive of leaving a good last impression on your employer, so you get a good recommendation, is a pretty good one, imo. It might actually be much more valuable than anything else you do in those last days/weeks, in fact.

It is true that your reputation follows you, but how are going to judge whether the knowledge gathered from that video is sufficiently thorough without actually watching it or at least going through generated notes. This will be generated and left for another llm to summarize and forgotten on a drive somewhere. No one will see any of it unless there is an actual issue.. at which point, it likely won't matter for the purpose of recommendation.

A handover happens not only when someone leaves the company but also when one moves internally. In that case the incentive to prepare the next person is definitely stronger.

I also really like the idea for this product and can see lots of applications of the format/medium beyond leaving employees/handovers.

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.

I'd love to be able to use this tool to write documentation that may not be specific to a "handover".

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.

I kinda love this idea. I wonder if there would be any additional value to having the AI access the departing employees documents and/or code. Or maybe coming up with a first draft of certain materials for the departing employee to correct, as needed. You could also generalize so that some tool like this becomes the source of institutional knowledge. Confluence but with videos and with AI generated or initiated content. What if you could have a dialogue with the AI version of the departed employee? Or an AI avatar capable of explaining institutional knowledge? But like not clippy, ok?

I'm working on a tool with a very similar business purpose but it isn't sold as this because I've concluded you can't sell this.

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

if you quit your day job your team will be lost without you

They can come with me if they want. Otherwise whatever.

Here is a contrarian view. How about keeping a valuable team member instead of getting rid of them at the first chance? I can bet that the past 2-3 decades or so the American organizations forgot collectively the most they have ever forgotten since the Industrial Revolution.

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”

You're right, companies should value long-term employees. But what if that person wants to be promoted, or move elsewhere?

Skills can be handed over; it depends on the complexity. Also, two people can be equally skilled, but not have the same knowledge to operate effectively in a specific company position. Eg. your new IT guy needs to know the code to the fireproof safe where the tapes are stored.

I worry about documentation in particular for hallucination. In this context the source of truth (the employee) is leaving the company, and leaving behind a document that will itself be seen as the new source of truth. Risk of hallucination or even transcription failures are usually low because you can always just go back to the source of truth, but thats not the case here.

Large corporations won’t bite. The higher ups don’t care or they would not do mass layoffs to kowtow to hedge funds or the stock market. Corporations throw people out like garbage. Go ask the Senior engineers at Microsoft who worked there for 22 years. Entire teams.

> Corporations throw people out like garbage. Go ask the Senior engineers at Microsoft who worked there for 22 years. Entire teams.

Well that is what happens when people on this site keep telling themselves that it is the "juniors" that are only affected.

Everyone (except the owners) and especially engineers of all levels are always affected.

> Workplace transitions are at an all-time high.

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

I honestly find it difficult to believe it could make knowledge transfer easier than, let's say, a template for the employee to fill out. It (knowledge transfer) is such an unstructured thing and differs wildly from post to post, and from company to company.

I imagine there would be a benefit if they are using an llm to understand key pieces of information (such as we use kubernetes); it could then just know what questions should be asked around that subject area to ensure enough details are captured as part of a handover. I can imagine it as being a template but on steroids.

That makes more sense, but supposedly companies would only need to use the model once to create the templates, which makes it a bad business model...?

Also, I have to admit I did not spend too much time reading the site. I have no idea if this is actually the case...

Interesting product idea. For technical knowledge I don’t see this working at all, maybe for organizational knowledge?

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

I'm in the middle of this right now.. Handover would be super helpful. Cool concept. Kind of reminds me of I Robot where you can ask specific queries to holograms

Slightly unrelated, but Eleven Labs (the AI voices company) has obtained the rights to Laurence Olivier's voice. How long until I can video chat with Laurence Olivier and ask him about which tasks my agents have completed today?

Hotel Handover: You can be employed and laid off, but your AI avatar and knowledge never leaves us (and we can talk to you forever, for free).

please make the pause button stop the video. i bounced as soon as i discovered those controls were performative

Reply on news.ycombinator.com