What Capability Transfer Actually Looks Like When It Works

A digital transformation's project plan budgeted two hours of training per person. That was their idea of successful adoption.

The organization was a mid-size, family-run manufacturer of toys and games. The founder still ran it, not yet ready to hand the business to his son. The master production schedule lived in his personal black spiral notebook. Employee turnover was close to zero. Most of the production staff had worked there since they were young, and some employees had never used a computer in a working capacity. Two hours was not a mistake in the plan. It was the plan.

Several of the longest-tenured employees, the ones holding decades of institutional knowledge that existed nowhere else, started saying openly that they would retire early or find another job rather than learn the new system. I took that to leadership and made the case for expanding the training and enablement budget and the timeline.

The CEO's first response, verbatim: "We can't afford to wait. If they can't hack it, they can leave."

Rather than argue the principle with him, I asked two questions. Could the company actually keep operating without a few specific people? This question was met with silence. Would halting production cost more or less than the change I was proposing? He didn’t need to tell me the answer. We both knew it.

Instead of limiting to just two hours of training, we did something different. We expanded the training timeline, brought in technical and industry experts to help deliver it, gave employees extensive practice and involved them in testing before go-live, and kept the experts on-site through launch and for two weeks after. Then came an informal survey to gauge comfort level. Experts were released one at a time, as each employee confirmed their own readiness, not on a fixed date leadership had picked in advance. A named contact stayed on call for a further month, one person to reach for each kind of issue. Employees admitted they did not end up calling but they felt better knowing who to call “just in case.”

The launch succeeded. The transformation succeeded. Not one valuable employee left. The extra cost of the additional effort was still less than the cost of replacing just one employee had they chosen that early retirement option.

Most conversations about capability transfer stop at delivery: the workshop happened, the training hours are logged, the slide deck exists somewhere in a shared drive. That measures whether something was taught. It does not measure whether actual adoption happened. I always use the example of my son and driving. He is 11 right now. He had played games where he “drives.” He understands the mechanics of shifting gears, pushing in the clutch, pressing the gas, etc. I have even explained these things to him. He also knows quite a lot about the rules and laws of the road. Simplistically, he has been taught to drive. But could he actually get behind the wheel and drive? Of course not. He is not old enough, does not have a license, has not practiced, is too short, does not have the muscle memory built up yet. This is the difference between training and adoption.

The instrument that actually tells you how adoption was handled is how the outside help leaves. A consulting engagement that ends the way this one almost did, experts pulled out en masse on the date the contract specifies, hands the organization back its own operations with no one confident enough to run them. This results in project completion but transformation failure. The impact is lost productivity and financial impact of replacing employees. A consulting engagement that ends the way this one actually did, support withdrawn in stages, on the employee's own signal, with someone specific to call if the signal was wrong, hands the organization back its operations and the confidence to run them. That is project and transformation success. This method retains your valuable employees and ensures they can continue operations even during transition. Completely different result, and the difference shows up only at the exit, not at the start.

The Kinetic Leader newsletter argued two issues ago that consultant dependency often starts with a contract that never includes for skills transfer as a deliverable. While that's true, it's only half the mechanism. Ensuring knowledge or skills transfer is one aspect but what about how the ending of the contract occurs? Does the contract include training only or actual adoption? Does support gradually taper off or abruptly stop? That is the part that determines whether the skills transferred from training to adoption.

One reasonable objection is that a month of experts on paid standby is exactly the spend a cost-conscious leadership team resists, the same pressure that produced their first answer in this situation. That's a real cost. It isn't the cost that mattered here. The two questions I asked them reframed the choice. They were considering 2-hours of training spend versus training and adoption spend. I reframed the choice to training and adoption spend versus a halted production line. In this case, the choice was clear.

A second, fair objection is that this is one workforce, with a specific profile, long tenure, low digital literacy, a family-run culture that valued people who'd earned their place. It is true that every company is different, with different employee profiles, who have different responses to change. No two organizations are identical. But the

principle underneath remains the same. Capability transfer should be assessed by how support gets withdrawn, not just how it got delivered. An organization that can't answer, in plain terms, how it plans to taper its own dependence on outside help before the engagement even starts hasn't actually planned for transformation. It has planned for delivery, and hoped the rest would follow. That is planning for project completion, not transformation success.

That hope is exactly where the Capability Building dimension of the Adaptive Capability Ecosystem (ACE) is built to intervene. If any of this sounds familiar in your own organization, the Organizational Adaptability Pulse Check is a free starting point. It's only twelve questions and takes about five minutes. For anyone who already knows the answer, a conversation with me is the next step.