liveBook · Manning

Knowledge transfer

As explained in Think Like a Software Engineering Manager

A structured interaction in which knowledge, skills, or work context are conveyed from one person or group to another.

When one person is the only one who knows how to complete a task or maintain a critical service, work can stall when that person is busy or leaves. Knowledge transfer means helping someone else gain the information and skills needed to take on the work. It takes time up front, but it can reduce bottlenecks, support growth, and make a team less dependent on any one person. section 5.1.1 section 5.1.2 section 8.4.3

Choose an approach that fits what needs to be passed on:

  • For delegated work, hold a knowledge-transfer session, demonstrate the task, and let the new owner shadow you. Match the task to their experience and continue offering supervision. section 5.1.1 section 5.3.2
  • For a departing specialist, arrange lunch-and-learn sessions or technical talks and document critical information before they leave. section 8.4.3
  • For a leadership change, have outgoing and incoming leaders plan the handover, define responsibilities and timelines, and organize conversations about critical information. Document what must remain available afterward. section 13.3.1
  • For ongoing engineering work, use code reviews, code walk-throughs, pair programming, and mentorship to share practices and learn from one another. section 12.2.1

The time trade-off

Suppose ten similar tasks would take you ten days to complete alone. Spending three days transferring knowledge and one day demonstrating the work while a teammate shadows you takes four days up front. If the teammate can then take on the tasks, you free six days of your own time. The benefit depends on choosing suitable work and giving the person enough support to succeed. section 5.1.1 section 5.3.2

Figure 5.1 Days of work with and without delegation
sidebar figure

Compare the days spent doing ten tasks alone with the initial time spent teaching and delegating them. section 5.1.1

Sharing knowledge does not mean sharing every detail with everyone. Communicate information relevant to the team’s work while protecting sensitive information. Check whether knowledge is spreading: team-development and collaboration measures can include whether sharing prevents a single point of failure. Where external partners hold expertise, assign someone to work closely with them so that expertise also develops within the team. section 3.2.3 section 9.2.6 section 9.2.2

How Think Like a Software Engineering Manager covers it

How deep it goes
Provides practical methods such as sessions, shadowing, talks, and documentation, without prescribing a universal handover procedure.
Examples
Illustrates a ten-task delegation calculation and a leadership handover built around conversations, responsibilities, and documentation.
What it assumes
Assumes responsibility for coordinating team work; introduces knowledge-transfer actions without requiring prior management experience.
What you can do after
Practice/perform it through suitable delegation, demonstrations, shadowing, talks, and documentation to reduce dependence on one person.
How it connects
Connects knowledge transfer with delegation, documentation, mentorship, code review, and succession during employee attrition.

Also explained in

Compare how 5 books explain knowledge transfer →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.