In short
- Training ≠ competence transfer. Knowledge of how a tool is built does not travel through a presentation — it travels through building it together.
- After a course you are left with a notebook. After joint construction you are left with a person who knows where everything is, because they put it there.
- The transfer has a price: one person's time from the department, and patience at the start, because building with someone who is learning goes slower than building alone.
- One condition cannot be worked around — someone in the company has to want it. Assigning it top-down produces a reluctant participant, not a future owner of the tool.
- The floor below which the company never falls: the code belongs to it from day one and is built on widely used technologies, so it can continue with another supplier without rewriting everything.
What competence transfer actually means
The word "transfer" suggests training: someone comes in, runs a course, leaves behind a manual. That's not how it works. Knowledge of how a tool is built and how to change it doesn't transfer through a presentation — it transfers through working on the build together. That's why the solution gets built alongside someone from the department who sits in on it from the start, watches how decisions get made, and gradually takes over hands-on-keyboard.
The outcome is different from what a course produces. After a course, what's left is a notebook and a hazy memory. After building together, what's left is a person who knows where everything in the tool lives, because they put it there themselves, and who can change it when the process changes. That's the difference between "we trained the team" and "there's someone on the team who can maintain this."
What it costs the company
Let's be honest here, because transfer isn't free or painless. It asks two things of the company. The first is a specific person's time — someone from the department needs room to actually sit down and work on the build, not just report a problem and go back to their own tasks. The second is patience at the start: building with someone who's still getting up to speed goes slower than building alone. A vendor who just wants to deliver and leave will do it faster.
The return on that cost comes later and is simple to calculate. Every future change the company doesn't have to outsource is time and money saved. The more tools a company has, the more this independence pays off — a portfolio dependent on a vendor grows into maintenance costs, while a self-sufficient one grows into capabilities.
Why it doesn't always happen
Transfer has one condition that can't be worked around: someone in the company has to want it. It can't be assigned from above — "you're going to learn this" produces a reluctant participant, not a future tool owner. The person who takes on the competence usually steps forward on their own, because they were already tinkering with something related: advanced spreadsheets, their own automations, after-hours experiments with AI tools.
Sometimes no one like that shows up in the department. That's not a failure — the tool still gets built and maintained from the outside, and transfer simply doesn't happen at this location. What matters is that the company knows this up front and doesn't buy into a promise of "we'll leave you with the skills" that depends on a factor outside anyone's control.
What stays regardless
There's a floor the company never falls below, even if no one picks up the competence. The tool's code belongs to the company from day one, and it's built on standard, widely used technologies. That means the company can bring in a different vendor at any point and continue, without rewriting everything from scratch and without asking the previous vendor for permission. Actually being able to develop the tool is the best-case scenario; code ownership and an open standard are the safety net for when that skill doesn't take root in the company.
What we don't know yet
Before acting on this article, it is worth checking whether the answers to these questions are known on your side:
- whether anyone in the department actually wants to take this on — it cannot be assigned top-down;
- how much of that person's time can be freed for the build, on top of their current work;
- whether the company accepts a slower start in exchange for independence later;
- who owns the code and on what technologies it is built, if the transfer does not happen;
- what the cost of every future change looks like in each of those two scenarios.
Frequently asked questions
What does competence transfer actually involve?
The solution is built together with someone from the department who sits with it from the start, sees how decisions are made and gradually takes over the work. It is the opposite of a model where the supplier delivers a finished tool and runs a training session at the end.
What does taking over competence cost the company?
Two things: the time of a specific person who needs room to work on the build, and a slower start, because working with someone still learning is less efficient. The return comes later — every future change you do not have to outsource is time and money saved.
What if nobody in the department is willing?
Then the transfer does not happen, and it is better to know that upfront than to buy a promise of leaving competence behind. The tools get built and maintained externally. That is not a failure, but it changes the cost picture over the years.
What should we ask a supplier before signing?
Two things directly: who will own the code, and what happens when you want to change something without them. The answers say more about your future independence than any discussion of features.
What's next
If you're considering an implementation, ask the vendor two things directly: who will own the code, and what happens when you want to change something without them. The answers say more about your future independence than the entire conversation about features. How I run work with a client's team, and what stays behind in the company afterward, is described in the methodology.
→ See how working with a client's team looks
→ Book a 30-minute consultation
