Transferring ownership, not just skills

At the end of most consulting engagements sits a reassuring line: “skills transfer”. It takes the form of training sessions, wrap-up workshops, sometimes a manual. Everyone signs off, the engagement closes, and six months later the organisation calls the provider back, because nothing that mattered has really changed hands.

It is not that training is useless. It is that it transfers only one of the four things that make up ownership. Knowing how something is done is not enough: you must also hold responsibility for it, have the tools to do it, and have proven that you can do it again on your own. Training passes on knowledge; ownership requires knowledge, responsibility, the means and the test.

Why the classic transfer fails

Transfer fails first through its timing. Placed at the end of the engagement, it comes when all the structuring choices have been made, when the budget is running out and when the provider's teams, already deployed elsewhere, rush through what no longer bears on their success. You cannot transfer in three weeks what was built over eighteen months.

It fails next through its object. People are trained in the actions, rarely in the decisions. The client team learns to use the tool; it does not learn why it is configured this way, which trade-offs were made, what will happen when the context changes. The day an unforeseen situation arises, knowledge of the actions is no longer enough, and the dependency reappears intact.

It fails finally through the asymmetry of incentives. A provider paid by the engagement has no economic interest in organising its own redundancy. As long as transfer remains an appendix clause rather than a measured commitment, it will be treated like appendix clauses: formally honoured, substantively empty.

The four transfers

Transferring ownership means organising four distinct movements, of which training is only the first.

• The transfer of knowledge: what the provider knows, the team knows: not only the procedures, but the reasons for the choices, the dead ends ruled out, the known weaknesses.
• The transfer of responsibility: what the provider decided, the team decides. This is planned milestone by milestone: on this date, prioritisation passes to the client; on that date, validation. A transfer with no schedule of responsibilities is a wish.
• The transfer of means: what the provider used, the organisation owns: access, environments, up-to-date documentation, code, configurations, contracts. Anything that remains on the provider's machines or in its archives is a deferred dependency.
• The transfer through testing: what the team is supposed to be able to do, it has done, alone, in real conditions, before closing. A simulated incident, a full cycle run without support, a change carried through end to end: handover readiness is not declared, it is demonstrated.

Withdrawal as method

These four movements sketch a mechanism that is simple to state: the provider's intensity must decrease as the client's autonomy grows, along a trajectory agreed from day one. At first, the provider does and the team observes; then they do together; then the team does and the provider observes; finally the team does alone. Each step has a date, criteria and an honest assessment: if the test fails, the failure is not hidden, the trajectory is adjusted.

This mechanism has a contractual consequence: transfer must be a deliverable, with acceptance criteria, and not an intention. It can be measured: responsibilities actually passed over, means actually handed over, tests actually passed. What is measured is steered; what is steered is achieved.

The economic objection remains: support designed to withdraw forgoes future revenue. That is true, and it is the price of a conviction: sustained dependency is a rent for the provider and a loss for the client. The organisations that have understood this choose their partners on that criterion: not what they will do during the engagement, but what will remain afterwards. From Strategy to Autonomy.