Ask HN: An engineer resigns -> How tech companies manage knowledge transfer?
19 comments
"Knowledge transfer should be an ongoing thing"
How to make this happen? Any software?
How to make this happen? Any software?
This isn't a technological problem, and there aren't technological solutions. This is a human problem. In my opinion, the way you do that is by not allowing people to specialize too much. Everyone should be rotating through duties so that everyone spends enough time dealing with each aspect of the product(s) that the "knowledge transfer" happens constantly and naturally as part of normal day-to-day operations.
How would this approach apply to, e.g., an R&D project in which each member of the team is a SME, "rotating" is not possible, and hiring two SMEs for each position would have a negligible impact on how quickly the project gets done?
Consider, for instance, an embedded software engineer, a PhD in computer vision, and a PhD in optics working together on a laser weapon.
Consider, for instance, an embedded software engineer, a PhD in computer vision, and a PhD in optics working together on a laser weapon.
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.
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.
> In real world, in your example there would be more than one of each - a lot more.
This is not necessarily the case in military-adjacent R&D laboratories.
This is not necessarily the case in military-adjacent R&D laboratories.
-> ideally yes, but gets very difficult to practice rotation in reality.
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)
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)
I would disagree with your assessment of good engineers wanting to highly specialize and gain deeper knowledge to the exclusion of the understanding of the total solution. My experience has been that it's average engineers who want to pretend they are more capable than they really are like to highly specialize. Because this gives them the ability to be an expert in one area because that's the limit of their capacity. Everyone has a given limit of the knowledge and understanding that they can do so it's not wrong to necessarily want that but that should keep someone always in a junior or a mid-level role.
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.
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.
I agree with what a lot of folks here are saying around knowledge transfer is a continuous/on-going process.
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.
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.
How do tech companies manage knowledge transfer? In 100% of the companies I've worked at, the answer is somewhere between "poorly" and "disastrously".
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.
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.
Most of the companies fail at knowledge transfer as they have very poor documenting culture.
How about create a system for constant brain dump and make it accessible.
Can LLMs help do it?
Can LLMs help do it?
What do you mean? How would such a system look like?
[I] For a given employee:
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)
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)
Unless your SME is building new content to feed the LLM, LLMs won't be able to produce anything specific to your organization. All they can do is write up common knowledge. Which is not any more helpful in transferring institutional knowledge than a search engine.
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.
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.
Employees are not motivated to do knowledge transfer. It goes directly against their job security. You need to motivate them somehow, and I’m not sure how you would achieve that.
In my company, there are some unwritten rules whereby managers typically rotate roles after 3-5 years of working in the same job title.
-> Employees switch within 2-3 years. (2 years being the industry average)
-> Most don't even live 1 whole rotation cycle.
-> But they do create substantial dependencies on themselves.
-> Most don't even live 1 whole rotation cycle.
-> But they do create substantial dependencies on themselves.
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.