Hacker News Reader

Comment by elmerfud | Hacker News Reader

I think if you're worried about knowledge transfer when an engineer puts in a resignation you have bigger problems. Knowledge transfer should be an ongoing thing. If you're not paid like a key man you should not be a key man.

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.

View on HN

"Knowledge transfer should be an ongoing thing"

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.

-> 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)

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.

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.

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.

This is not necessarily the case in military-adjacent R&D laboratories.

Reply on news.ycombinator.com