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'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
