#155 added

articles/know-how-transfer.md

@@ -0,0 +1,56 @@
+---
+authorName: Christoph Zuber
+authorGithubUsername: abeggchr
+issue: 155
+title: Know-how Transfer – Just explaining once is not enough
+---
+# {{page.title}}
+
+Most projects face situations where knowledge needs to be transferred from one person to another. Integrating new team members quickly with an effective and efficient know-how transfer minimizes delays and transition costs - you can react flexibly to changing requirements and ideally specialists can contribute to several projects. How can you ensure that nothing of importance is being lost even in complex projects?
+
+## Everything, as fast as possible
+
+The expression “Know-how transfer” suggests that knowledge can easily be handed over to another person. But it’s not that simple:
+* Often knowledge is available only implicitly and distributed over several people.
+* The time to hand over and the capacity to adopt information is limited.
+* Knowing something does not automatically mean it is understood or can be applied.
+
+How to organize a handover then? 
+
+## Set priorities
+
+First and foremost: Set priorities. It’s an illusion to expect that all knowledge can be entirely transferred. Therefore, a better strategy is to ensure that all central topics are well covered. And remember, priorities depend on the perspective: Perhaps the knowledge recipient has a different mission? Surely the recipient is the one that needs to work with the new knowledge, the one handing over is often not available anymore after the transfer. Hence it should always be the receiver guiding the handover process and he therefore needs to know his goals. 
+
+It is a legitimate concern that entire topics may be overlooked when following this approach. To avoid large gaps, be sure to start with a high-level overview in order to understand the bigger context. Knowledge maps and user story mapping can be useful tools to support this process.
+
+## Documentation
+
+If good documentation is available, the handover can be simplified to providing an introduction and overview of the documentation as well as explanations for undocumented topics. It is crucial, however, that the documentation is trusted and up-to-date. As a minimal structure, onboarding  checklists proved to be helpful. Neither as a list of technical setup tasks, nor as comprehensive documentation, but rather as a map of the most important topics and where to find documentation. Like that they are small enough and don’t get outdated as fast as (yet another) documentation.
+
+## Apply what you learned
+
+Documentation provides explicit knowledge – a conscious effort to preserve and make available knowledge on a topic.  Much more difficult to share is implicit knowledge, acquired from years of experience.  For instance, knowing with whom to consult with on various topics as the result of passed interactions with persons within a network.
+
+Typically, the absence of implicit knowledge is first noticed once it is needed – when the “real work” begins. An effective method to ensure that you have the required knowledge is to work under the supervision of the knowledge giver. In software development projects, this could include fixing bugs, implementing new features, creating and executing tests or deployment of the application. To quote Benjamin Franklin:
+
+> Tell me and I forget. Teach me and I may remember. Involve me and I will learn.
+
+Doing practical work in the acquired codebase will immediately reveal the knowledge gaps which need to be filled.  More importantly, the learnings are more likely to endure if they are a result of practical work.
+
+## Continuous know-how transfer
+
+Even if no employee exchange is planned, it is good practice to share knowledge within the team:
+* Exchange sessions covering important topics in order to increase awareness within the team
+* A group chat tool with good search functionality to simplify informal exchange, especially within distributed teams
+* Methodologies with short feedback loops to foster the exchange within the team
+The above points help to avoid knowledge silos - which will in turn lessen the impact of a leaving team member 
+
+## Check the success
+
+As a knowledge receiver, make sure you understand what you receive. The transfer of knowledge is not a one-way street, ask questions and try to apply what you learned. A simple and very effective check to see if you really got the point is to give a short summary of the topic to outsiders. And think about the next joiner already: give feedback on how the onboarding process can be optimized.
+
+Without such checks, you might grasp a passive understanding of the topic, without acquiring the ability to apply it in practice.
+
+Hopefully your next project change will be successful with these suggestions.
+
+*By {{page.authorName}}*