The standard frame treats the software as the product and the receiving team’s readiness as a risk to manage. Inverting it explains the practices better: the capability is the product, and the artifact is the occasion for producing it.
This is not a motivational reframing. It changes what gets scheduled, what gets accepted, and what counts as done.
Read the practices backwards
Every practice that eases transfer becomes legible as a training design once the frame is inverted.
Boring technology constrains the stack to what the receiving team can operate. Shadowing and reverse shadowing are supervised practice with graduated responsibility. The evaluation harness is a portable definition of correct behaviour the recipient can run alone. The debt ledger is a documented account of what the system cannot do, addressed to whoever inherits it. Architecture decision records preserve reasoning for people who were not in the room.
None of those improves the software. Each improves what someone else can do with it, which is the actual thing being transferred.
Demands made during the build
Build-time recipient demands are the requirements and working arrangements through which a future owner influences the system while it is still being built. They concern sustained ownership rather than a document delivery on the final day.
The design works backward from representative tasks — a change, a release, a diagnosis, a recovery, an access-management action, an evaluation decision. For each one: the artifact or collaboration needed, how the recipient will inspect or exercise it, and who can accept it.
Four things get separated that are routinely conflated: source ownership, repository access, permitted data use, and credentials. None automatically grants the others.
Then the practical conditions. Reserved recipient time and a usable environment. Review scheduled at architecture and dependency decisions that are costly to reverse. Decision rationales and rejected alternatives preserved, so that participation has a traceable effect. And an established route for the buyer to raise a blocking concern, because meeting attendance is not decision authority.
A recipient asking for a clean-environment deployment exercise during the build, which reveals a vendor-only dependency credential, has found the problem while it is still cheap. Passing that exercise later establishes the tested deployment path and not operational independence — which is the correct, narrow reading.
Capability is not the same as insourcing
Internal prototyping capability is the sustained ability to frame questions, test systems, evaluate results, and make ownership decisions. It does not require building every component internally or removing specialist suppliers.
The published delivery models make this explicit: internal delivery, a bridge using supplier capability while internal capability develops, fixed-term borrowing of capability, and outsourced delivery are distinct arrangements rather than a maturity ladder.
So the question is which decisions require internal understanding, and those get funded with repeated practice, feedback, and reusable assets. A buyer that initially has a supplier design and run every evaluation, and later funds internal analysts to edit the rubric, inspect disagreements, and run an evaluation under supervision, has moved a specific decision inside. The record distinguishes attendance from task performance and notes the remaining supplier help.
Two dependencies get tracked, not one: dependence on a supplier, and dependence on specific individuals. What happens when a key employee leaves is the same question as what happens when the vendor does.
Measure the demonstration, not the input
Supplier spend, course attendance, and headcount are inputs. Demonstrated performance on the selected tasks, with difficulty and required assistance recorded, is the measure.
The practical rule is that a supervised attempt and an unaided one answer different questions, and both are useful provided the record says which occurred. Success on the original exercise is not evidence about a new task, and a later unaided attempt on a different task supplies something the first could not.
Staff also need the opportunity to do meaningful work — define a hypothesis, revise a test, review a design, deploy a change, explain a failed result. A supplier demonstration introduces a task. It does not provide practice at it.
There is a real cost on the other side. Internal practice that delays essential delivery needs appraising too, and no optimal ratio of internal to external staffing follows from anything here.
Where the return appears
Not on the first transfer. The first one pays for building the practice: the evidence format, the exercise design, the acceptance conventions, the discovery of which assumptions were wrong.
The second and third transfers to the same organisation reuse all of it. The receiving team knows what a readiness exercise looks like, the builders know what evidence will be requested, and the assets from the first engagement — evaluation cases, runbook structure, decision-record conventions — are already in a usable form.
An organisation that runs one transfer and dismantles the practice has paid the setup cost and collected none of the return. That is the ordinary outcome, because the practice is invisible in the artifact.
The rule
What stays fixed is that the acceptance evidence is produced by the receiving team on the tasks it will own. What changes is which tasks those are, and they are selected from the responsibilities actually being transferred rather than from a general readiness checklist.
Not to be confused with
A training budget. This is about what the delivery work is arranged around, not about a line item. A programme that builds the system first and trains afterwards has chosen the frame it thinks it rejected.
Evidence of effectiveness. No longitudinal dataset establishes when outsourcing causes capability loss, and no learning gain is measured here. The argument is that the practices are better explained this way, and the measurement remains outstanding.