A successful pilot proves that one team could make something work. Organizational capability begins when a different team can reproduce the useful result without inheriting the original team's exceptional conditions.
A pilot can succeed because the organization learned something.
It can also succeed because five unusually capable people learned how to keep it alive.
From the outside, those outcomes can look identical.
The workflow works. The sponsor is pleased. The numbers clear the threshold. The team can explain the decisions and deal with exceptions. A handoff document exists. The obvious next move is to scale.
But there is a question I would put between pilot success and scale:
Can a different competent team reproduce the useful result without inheriting the original team's exceptional conditions?
That is a harder test than deployment.
It is also much closer to a test of organizational capability.
The people who built a pilot accumulate knowledge that rarely appears in the final diagram.
They know which data source is technically authoritative but practically unreliable. They remember why one integration was implemented in an odd way. They can tell when an output looks plausible but wrong. They know which stakeholder needs an early conversation before a process changes. They have a mental model of the system's weak points because they discovered those weak points themselves.
Some of that knowledge gets documented.
Much of it becomes judgment.
This makes the original team a poor instrument for measuring transfer. Every time something goes wrong, they can silently compensate with context acquired during the experiment.
The pilot may therefore keep performing after "handoff" while still depending on the people who created it.
That is not a criticism of the team. It is a property of learning.
Research on absorptive capacity has spent decades examining a related organizational problem: acquiring knowledge is not the same as being able to assimilate and exploit it. Studies of business units and cross-functional teams have repeatedly found that the ability to absorb knowledge affects whether knowledge access translates into innovation performance.
The practical implication is easy to miss.
If only the people who produced the knowledge can use it, the organization does not fully possess it yet.
I would make transfer observable.
After a pilot has produced evidence worth continuing, choose a second team that is competent but was not embedded in the original experiment. It does not need to be a random team, and the exercise should not be designed to make them fail. They should have the skills and authority that a realistic future owner would have.
Transfer what the organization believes it has learned:
Keep the original team available.
Then change their role.
They can answer questions and observe. They should not quietly become the execution layer whenever the receiving team gets stuck.
The purpose is to discover where capability still lives in people rather than in the organization.
The most revealing output of the second-team test is not whether the second team eventually succeeds.
It is the pattern of rescue required to get there.
How often does the original team have to intervene?
What kind of intervention is it?
A missing password is not the same as an undocumented decision rule. A weak runbook is not the same as a receiving team that lacks a necessary skill. An integration that only one engineer understands is not the same as a business exception whose owner was never defined.
I would classify the rescue work rather than hide it.
Context rescue happens when the second team cannot understand why the system or workflow is the way it is.
Technical rescue happens when operation depends on implementation knowledge that did not transfer.
Judgment rescue happens when quality depends on tacit pattern recognition held by the original team.
Relationship rescue happens when progress depends on informal access to people or organizational routes that were never made part of the operating model.
Authority rescue happens when the second team reaches a decision it is expected to own but lacks the mandate to make.
Each category points to a different missing capability.
The intervention is evidence.
This gives capability building a useful direction of travel.
The goal is not zero contact with the original team. That would turn a learning exercise into an artificial isolation test. Good transfer often needs overlap.
The goal is declining dependence on exceptional support.
The second team should need fewer explanations because the reasoning is visible. Fewer technical rescues because the infrastructure is operable. Fewer judgment rescues because evaluation criteria and examples have become legible. Fewer relationship rescues because dependencies have formal owners. Fewer authority rescues because decision rights moved with the work.
The important measure is not documentation completeness.
It is support decay.
As the capability moves, does the amount of exceptional help required from the original team fall?
If it does not, adding more teams may simply multiply dependency on the same experts.
That is a scaling trap. The organization appears to have distributed the capability while actually centralizing the expertise required to keep every instance working.
A second-team test should not require an exact reproduction of the pilot.
That would confuse the prototype with the learning.
The receiving team may work in a different function, with different data, users or constraints. They should adapt what was learned to their environment.
This is where replication becomes more useful than rollout.
A rollout asks whether the original solution can be extended.
Replication asks which parts of the original success survive a change in context.
That distinction matters because durable capability is rarely a single implementation. It is a set of reusable ways to frame the problem, evaluate evidence, make decisions, operate the system and learn from exceptions.
The second team should inherit those principles without being forced to inherit every design choice.
If they can change the implementation and still preserve the quality of the outcome, the organization may have learned something deeper than a recipe.
There is another signal worth watching: what the organization no longer has to discover.
The first pilot pays the full price of uncertainty. It finds the hidden dependencies, tests the wrong assumptions, discovers which evidence matters and learns where the organization resists or adapts.
The second attempt should not pay that price again.
It may face new uncertainty, but it should inherit resolved uncertainty from the first.
That means capability building should create an economic effect before it creates enterprise-wide scale. The next competent team should reach a comparable decision or outcome with less discovery effort, fewer avoidable mistakes and less dependence on exceptional people.
If every new team has to rediscover the same constraints, the organization has a collection of projects.
If learning from one team reduces the cost of learning for the next, capability is beginning to compound.
This is consistent with what organizational-learning research describes as absorptive capacity: knowledge has to be acquired, understood and put to use, not merely made available. Cross-functional integration matters partly because it helps units build the capacity to absorb knowledge from elsewhere. Google Cloud's DORA work makes a similar point in a more recent technical context: AI tends to amplify the underlying technical and organizational environment rather than erase its weaknesses.
A second-team test makes that abstract idea operational.
I have argued before that what happens after a successful pilot matters as much as the pilot itself: the work needs a permanent home, and the learning matters more than preserving the prototype.
There is a further test after the home is named.
Can the new owner actually carry the capability?
And beyond that: can another team learn from the same capability without recreating the exceptional conditions of the first project?
That is the difference between handing over work and changing what the organization knows how to do.
An internal innovation function should eventually make itself less necessary for the classes of problem it has already helped the organization learn to solve. Otherwise it risks becoming the permanent interpreter between new technology and the rest of the business. That is exactly the silo problem described in Building an internal innovation capability without creating another silo.
The first team proves possibility.
The second team reveals transfer.
What the second team can do without being rescued is the part the organization actually owns.
Berk Bayri
Creative Technology & Innovation Leader
Designing and building for digital environments since 1998, across strategy, product, design, technology and organizational innovation.
About Berk →