I once thought of a technical handover mainly as the disciplined preparation of information. The originating team knew the process; the receiving team needed the relevant instructions, reports and records. Over time I became more interested in a different test: could the recipient explain why a consequential choice had been made, and recognise a proposed change that required renewed examination? A complete set of files could support that understanding, but its existence did not demonstrate that the understanding had arrived.
This distinction matters because development knowledge is unevenly distributed. Some is explicit in formal work. Some remains in the memory of the colleague who examined an unsuccessful route or noticed a material sensitivity. Some is so familiar to the originating group that nobody thinks to state it. When a process moves, the instruction can travel faster than these reasons. The recipient may then reproduce the visible steps while lacking the context needed to interpret an unexpected observation or assess whether a seemingly minor adjustment matters.
The document and the understanding
I am not arguing for replacing controlled records with conversation. The record remains essential. My concern is that a team can mistake documentary completeness for a shared technical account. A list of equipment, a sequence of operations and a collection of development reports may all be accurate while leaving the relationship between them difficult to use. The receiving specialist needs to find the observation that supports a choice and understand what the originating team concluded from it. That relationship should survive the absence of its original author.
One useful starting point is a consequential instruction that looks arbitrary. In a transfer from Nanjing to Suzhou, an addition order had a development rationale that was scattered through earlier work. The final sequence was clear, but the recipient could not readily explain why another plausible order had been rejected. That gap would matter if a later equipment or scheduling proposal made the alternative attractive again. Preserving the rejected route helped prevent a future team from unknowingly repeating a question whose earlier answer was already available.
The answer is not to describe every historical discussion in equal detail. An indiscriminate archive can bury the reasoning as effectively as an incomplete handover. I ask teams to identify the decisions whose explanation is important to the next use: material choices, equipment assumptions, sensitivities, unresolved questions and the conditions under which observations were obtained. The full supporting record remains available. The transfer account provides a route through it, so a specialist can understand what matters and examine the underlying work rather than depend on an unsupported summary.
There is also a boundary to preserve. Explaining why a process behaves as it does does not authorise any person who understands it to change it informally. Quality and operating responsibilities continue to apply. A developer accompanying a receiving team can help interpret a question, but cannot make another function's decision merely because the developer knows the history. A good transfer makes both knowledge and authority clearer. If it improves technical confidence while making decision responsibility less clear, it has solved only part of the problem.
Let the recipient challenge the account
I prefer a handover in which the recipient has work to do. Asking receiving specialists to explain a process back to the originating team is not an examination of their competence. It is an examination of the account being transferred. Their questions reveal assumptions that the developer may no longer notice. A recipient who cannot explain a choice is providing useful information about the preparation, especially when the available documents appear complete. The conversation should allow that gap to emerge without treating it as personal failure.
This can create a genuine resource conflict. Developers are often expected to finish a transfer while beginning the next candidate. Operations may want to learn during the first campaign because bringing specialists together earlier affects the schedule. In our Suzhou preparation, I supported six weeks of joint work at CNY 2.3 million, including visits and paired technical sessions. The campaign began three weeks later than planned. That consequence belonged in the programme account. Better preparation should not be described as free simply because its expenditure appears smaller than an imagined future problem.
The work gave us a shared explanation of important choices for that transfer. I did not convert it into a percentage reduction in future deviations, because the programme had not established such a result. That restraint helps preserve the actual value of the effort. The receiving team could explain the addition-order rationale and recognise when an equipment adjustment needed another assessment. These are meaningful outcomes without a fabricated productivity number. If a later programme measures a wider benefit, its population, period and method should be stated separately.
Recipient challenge should begin earlier than the final handover. A manufacturing specialist involved during development can ask questions while the relevant work is still being planned. The programme may then examine an assumption before it becomes expensive to revisit. That does not mean every site must participate equally in every early experiment. It means the development plan should consider who will eventually need to use the knowledge and when their perspective would most improve the next decision. The timing of participation can matter as much as its formal existence.
Leave a usable inheritance
A transferred process continues to accumulate experience. The first handover should therefore make it possible to distinguish original development knowledge from later operating observations and subsequent changes. If every addition is folded into a single undated explanation, a future reviewer may not know which conclusion supported an earlier decision. I want a record that can evolve without rewriting its own history. An observation made later can change our understanding while leaving an accurate account of what was known when the previous choice was made.
People also leave. A transfer dependent on two named specialists being available indefinitely is vulnerable even if the initial campaign goes well. Part of leadership is recognising when personal expertise has become an unacknowledged operating dependency. The response includes developing colleagues and making the reasoning usable, rather than assuming that a recorded meeting captures everything important. A new specialist should be able to find the relevant evidence, understand the conclusion and identify whom to involve when the intended use differs from the circumstances originally examined.
I would assess a handover by the questions the receiving team can now ask more precisely. Can it distinguish an observation from an explanation? Can it locate the rationale for an important choice? Can it identify an unresolved question without treating it as a failure of the whole programme? Can it recognise the boundary of its own authority? These are practical capabilities. They make the transfer more than a transaction between a sender with a complete folder and a recipient with a new set of obligations.
My own improvement is to make that recipient perspective part of development earlier. The expensive moment is often the late discovery that an apparently complete account relies on knowledge nobody wrote down because everybody nearby already knew it. Technical leadership should make the nearby knowledge usable at a distance: across a site, a function and eventually a change of personnel. That is when a process has travelled in a form the next team can responsibly understand, question and develop further.