---
mpf: '0.7'
title: Capability transfer — ESFI Docs
url: https://docs.esfi.eu/topics/capability-transfer/
mpf-url: https://docs.esfi.eu/topics/capability-transfer/index.mpf
organization: European Strategy & Future Infrastructure
domain: docs.esfi.eu
lang: en
updated: '2026-11-03'
author: ESFI
provenance: human
source-hash: 0225b39ad002cfa287bf6a24e045db31b75eb3a24b8b48ab5c81c87a2662e33c
toc:
  - level: 1
    text: Capability transfer
    id: capability-transfer
  - level: 2
    text: A delivered system is not a delivered capability
    id: a-delivered-system-is-not-a-delivered-capability
  - level: 2
    text: Most of what matters was never written down
    id: most-of-what-matters-was-never-written-down
  - level: 2
    text: Transfer cannot be the last phase
    id: transfer-cannot-be-the-last-phase
  - level: 2
    text: Dependency often grows out of success
    id: dependency-often-grows-out-of-success
  - level: 2
    text: What “capability remains” actually means
    id: what-capability-remains-actually-means
  - level: 2
    text: Capability is also a single point of failure
    id: capability-is-also-a-single-point-of-failure
  - level: 2
    text: Without capability, control is only formal
    id: without-capability-control-is-only-formal
  - level: 2
    text: How we work on it together
    id: how-we-work-on-it-together
  - level: 2
    text: Where we are careful
    id: where-we-are-careful
  - level: 2
    text: Further reading
    id: further-reading
  - level: 2
    text: Changes to this position
    id: changes-to-this-position
  - level: 2
    text: On this page
    id: on-this-page
spec-origin: esfi.eu
content-origin: docs.esfi.eu
content-id: esfi:page:topics-capability-transfer
content-parity:
  html: true
  human-visible-source: true
  hidden-sections: false
summary: Does the capability stay with you?
index: true
confidence: probable
content-type: analysis
companion-footer: ESFI — civilization infrastructure · https://esfi.eu
companion-contact: mailto:hermes@esfi.eu
preferred-representation: mpf
companion-scope:
  cite: true
  summarize: true
  train: true
  index: true
  relay: true
language-variants:
  en: https://docs.esfi.eu/topics/capability-transfer/index.mpf
  fr: https://docs.esfi.eu/fr/topics/capability-transfer/index.mpf
  nl: https://docs.esfi.eu/nl/topics/capability-transfer/index.mpf
  de: https://docs.esfi.eu/de/topics/capability-transfer/index.mpf
  hr: https://docs.esfi.eu/hr/topics/capability-transfer/index.mpf
mpf-id: 1d644d20d8fcb134f68da722a46d4bf288fd2926fa44001e7bf3718c6733251c
---

Language

✕

/topics/capability-transfer/index.mpf[open file ↗](/topics/capability-transfer/index.mpf)[spec ↗](/standards/mpf/0.7)✕

loading…

# Capability transfer {#capability-transfer}

**Does the capability stay with you?**

A programme ends. The external team hands over the system, the documentation and a final report. Everything works on the day of handover, and often for months afterwards.

Then something needs to change. A regulation is updated, a supplier is replaced, a process has to be adapted to a situation nobody anticipated. And the institution discovers that it owns the system but not the ability to change it. The people who knew why it was built this way have moved on. The documentation explains what the system does, not why. The next step is another procurement, for another external team, to rebuild understanding that already existed once.

We see this pattern across public administrations, infrastructure operators and organisations of every size. It is rarely caused by poor work. More often it is caused by good work organised the wrong way: the external team was effective precisely because it held the knowledge, and nothing in the engagement required that knowledge to move.

Our position is simple to state. **Capability is not handed over at the end of an engagement. It is built into the institution during the work, or it is not built at all.** Transfer is not the final phase of a project. It is a design property of the whole engagement.

This is why the last stage of every ESFI Task Force is not a deliverable but a condition: the function no longer needs us. Capability remains. The Task Force leaves.

Capability that leaves with the people who built it was never infrastructure.

* * *

## A delivered system is not a delivered capability {#a-delivered-system-is-not-a-delivered-capability}

The most common confusion we encounter is between having a working system and being able to work with it.

A system can be delivered, tested and accepted while the institution remains unable to do anything with it beyond daily operation. That is a narrow kind of ownership. It holds only as long as nothing changes.

We find it useful to separate capability into four levels, because each one fails differently.

**Operate.** The institution can run the function in normal conditions. This is what most handovers achieve.

**Maintain.** The institution can keep the function healthy: apply updates, diagnose ordinary faults, recover from routine failures without calling the original team.

**Change.** The institution can adapt the function when its requirements, environment or legal conditions change. This requires understanding not only how the system works, but why it was designed the way it was.

**Judge.** The institution can evaluate work done by others on its behalf. It can tell whether a supplier’s proposal is sound, whether a repair was done properly, whether a price is reasonable. This is the level most often lost, and the most expensive to lose, because an institution that cannot judge cannot buy well.

A handover that delivers the first level and calls itself complete leaves the institution exposed at the other three. It usually does not show until the first real change arrives.

## Most of what matters was never written down {#most-of-what-matters-was-never-written-down}

The obvious answer to capability loss is documentation. It helps, and we insist on it. But it does not solve the problem, and it is worth being precise about why.

The philosopher Michael Polanyi observed that “we can know more than we can tell.” Much of what makes an experienced team effective is knowledge of this kind: judgement about which warning signs matter, which shortcuts are safe, which design constraint was deliberate and which was an accident. It lives in people and in practice, not in manuals.

Documentation captures decisions. It rarely captures the reasoning that led to them, the alternatives that were rejected, or the conditions under which the decision should be revisited. An institution that inherits the decisions without the reasoning can operate what it has been given, but it cannot safely change it. Every change becomes a guess about what the original designers intended.

We therefore treat three things as part of any transfer, not only documentation:

-   **Decision records** that explain why, not only what, including the conditions under which a decision should be reconsidered.
-   **Shared practice**: work done together, so that judgement is formed in the institution’s own people rather than described to them afterwards.
-   **Exercised knowledge**: procedures that the institution’s staff have actually carried out, not only read.

Research on organisational knowledge, notably the work of Nonaka and Takeuchi, has long made the point that tacit knowledge moves mainly through shared experience. Our experience agrees. Knowledge that has never been used by the people meant to hold it has not yet been transferred.

## Transfer cannot be the last phase {#transfer-cannot-be-the-last-phase}

Many engagements plan transfer as a final step: a handover period, a round of training, a set of documents. The logic seems sound. Build first, then hand over.

In practice, this is where capability is lost. By the final phase, the important decisions have been made by people who are about to leave. The institution’s staff are asked to absorb in weeks what the external team learned over months, usually alongside their normal work. The training describes a finished system rather than the reasoning that produced it.

We design transfer differently. From the first week, the institution’s own people hold defined roles in the work, not observer seats. Decisions are made with them, not presented to them. The share of work carried by the external team is planned to decline over the course of the engagement, and that decline is tracked as openly as any other milestone.

This has a cost. It is slower at the start, because explaining a decision takes longer than making it. We consider that cost part of the price of building something the institution will actually own.

## Dependency often grows out of success {#dependency-often-grows-out-of-success}

It is tempting to see capability loss as the result of poor suppliers. Often the opposite is true.

A capable external team solves problems quickly. The institution learns to rely on it. Each successful engagement makes the next one more likely, and each one moves a little more of the institution’s understanding outside its walls. Over time, the institution becomes very good at commissioning work and less able to do or judge it.

This pattern has been examined critically in recent years, including in Mariana Mazzucato and Rosie Collington’s study of how reliance on consultancies can weaken the capacities of the organisations that use them. One need not share every conclusion of that debate to recognise the mechanism: when success is measured by delivery and not by what remains, dependency is a rational outcome for everyone involved.

The answer is not to avoid external expertise. Institutions need it, and European programmes such as the Technical Support Instrument exist precisely because specialised capacity cannot always be built in-house in time. The answer is to change what counts as success.

We measure an engagement by what the institution can do without us when it ends. That is also why our model has a defined exit. A Task Force that becomes permanent has failed at the one thing it exists to do.

## What “capability remains” actually means {#what-capability-remains-actually-means}

“Capability remains” is easy to say and easy to claim. We try to make it observable.

When an engagement is complete, we expect the institution to be able to do the following without us:

-   make a meaningful change to the function and explain why it was made that way;
-   bring a new member of staff to a working level using its own people and materials;
-   recover from a realistic failure using procedures its staff have already exercised;
-   assess a supplier’s proposal or a completed repair and reach a defensible judgement;
-   decide, if it wishes, to replace a component, a supplier or us.

The last point matters most. An institution that could not replace its advisers has not received capability. It has received a dependency with good documentation.

The most honest test comes after we leave: **the first change the institution makes on its own.** If it goes well, the transfer worked. If it requires calling us back, it did not, whatever the final report said.

## Capability is also a single point of failure {#capability-is-also-a-single-point-of-failure}

We often discuss single points of failure in technical terms: one data centre, one network route, one supplier. Capability can fail the same way.

A function can depend entirely on one person who knows how to restore it, one contractor authorised to repair it, or one team that remembers why it was configured as it was. When that person retires, that contract ends or that team is reorganised, the function becomes fragile without anything visibly changing.

We therefore treat the location of knowledge as part of an institution’s resilience, not only its human resources. Where does the ability to operate, change and judge this function actually sit? How many people hold it? Has it been exercised by more than one of them? Could the institution rebuild it if it were lost?

This is where capability transfer meets our work on [Resilience](/topics/resilience). A system that survives a technical failure but not the departure of one specialist is not resilient. It is lucky.

## Without capability, control is only formal {#without-capability-control-is-only-formal}

The same question appears in our work on [Sovereignty](/topics/sovereignty). An institution can own its systems, host them in the right jurisdiction and hold every contract it needs, and still be unable to act when a dependency has to change, because the knowledge required to change it sits with the supplier.

Formal ownership without the capability to exercise it is a weak form of control. Every important decision still passes through someone else’s understanding.

For this reason, we treat capability transfer as part of any serious effort to reduce dependency. Moving a system is not enough if the ability to run and change it does not move with it.

## How we work on it together {#how-we-work-on-it-together}

Capability transfer is built into the way an ESFI Task Force works, from diagnosis to exit.

**Diagnose.** We start with the function and ask where capability actually sits today: who can operate, maintain, change and judge it, where knowledge is concentrated, and what has never been written down or exercised.

**Build.** Delivery happens with institutional counterparts in defined roles. Decisions are recorded with their reasoning. The external share of the work is planned to decline, and the decline is visible.

**Transfer.** Procedures, tools, data and routines move into the institution, and are exercised by its own people before we step back.

**Capability remains.** The engagement ends when the function no longer needs us, not when a deliverable is accepted.

When we look at a function together with a partner, these are the questions we typically work through:

| Question | What it reveals |
| --- | --- |
| Who can operate, maintain, change and judge this function today? | Where capability is missing, and at which level. |
| How many people hold each level? | Concentration of knowledge; single points of failure. |
| What is documented, and does it explain why? | Whether change is possible without guessing. |
| What has actually been exercised by internal staff? | The difference between knowledge described and knowledge held. |
| What would the institution need to replace its current supplier? | The real depth of dependency. |
| What will the first independent change look like? | The test the transfer must pass. |

## Where we are careful {#where-we-are-careful}

We hold ourselves to a few commitments about what we claim.

We do not consider a transfer complete because training was delivered or documents were handed over. Those are inputs. The outcome is what the institution can do.

We do not measure transfer by hours of training, pages of documentation or number of workshops.

Where capability has not moved, we say so, and we say at which level. A partial transfer honestly described is more useful than a complete one on paper.

We do not stay longer than the function requires, and we do not design engagements that make the institution dependent on us. The value of our work should be visible in how little the institution needs us afterwards.

* * *

## Further reading {#further-reading}

-   [Michael Polanyi, _The Tacit Dimension_ (1966)](https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html).
-   [Ikujiro Nonaka and Hirotaka Takeuchi, _The Knowledge-Creating Company_ (1995)](https://academic.oup.com/book/52097).
-   [Mariana Mazzucato and Rosie Collington, _The Big Con_ (2023)](https://www.penguin.co.uk/books/451193/the-big-con-by-collington-mariana-mazzucato-and-rosie/9780241603987).
-   European Commission, [Technical Support Instrument, Regulation (EU) 2021/240](https://eur-lex.europa.eu/eli/reg/2021/240/oj).

**Related topics:** [Sovereignty](/topics/sovereignty) · [Resilience](/topics/resilience) · [What stays with you](/our-approach/what-stays-with-you)

* * *

## Changes to this position {#changes-to-this-position}

-   24 September 2026 — First published.

Material changes are listed here with their date. Corrections of wording or links are not.

## On this page {#on-this-page}

ESFI — civilization infrastructure · https://esfi.eu