Training your customer out of needing you

Every services business faces the same quiet incentive: the less the customer understands, the longer they need you. Almost nobody acts on it deliberately. It happens anyway, through a hundred small decisions — the undocumented change, the runbook that never gets written, the explanation that is a bit too brief — and the result is a relationship held together by ignorance rather than value.

How it happens without anybody deciding

Nobody writes “keep them dependent” in a strategy document. The mechanism is much more ordinary.

Documentation is written when there is time, and there is never time. Access is granted to those who need it, and the definition of need narrows quietly. Changes are made during incidents and reconstructed later, or not. Handover is scheduled for the end of the project, which is where budget goes to die.

Six months in, the customer cannot operate their own system, and nobody did anything wrong on any particular day.

Why we would rather not

Partly ethics and mostly economics, which is a more durable reason.

A dependent customer is a resentful one. They know. It shows up as price pressure, reluctance to expand scope, and an RFP the moment somebody senior notices the annual number.

Dependency is fragile revenue. It survives until a new CTO arrives with a mandate. Revenue built on being genuinely better survives that conversation.

Trained customers buy more. A team that understands the system finds new things to do with it, and those things are projects. A team that fears it keeps the scope frozen.

It is what we are selling. The whole Kyber story argues that intelligence should belong to the people and companies that use it, on systems they can read and run themselves. A supplier who made their customers dependent while saying that would be selling something they do not believe.

What deliberate knowledge transfer looks like

Documentation as a deliverable, not a courtesy. Written during the work, with the customer reviewing it, because documentation nobody has read is not documentation.

Configuration in their repository from day one. Not ours with a copy handed over at the end. Every change is a commit they can see, in a place they own.

Pairing during incidents. The most valuable training in existence, and it only works if somebody from their side is in the room while it is happening rather than reading a summary.

Scheduled sessions on what changed and why. Not a certification course. A recurring hour where the decisions get explained while the reasoning is fresh.

A declining support tier as a stated goal. Written into the engagement: this much support now, less in six months, this shape after that. If it does not decline, one of us is not doing our job.

The obvious objection

If the customer no longer needs you, where does the revenue come from?

From the next thing. A team that has successfully adopted one system is the best possible customer for the next one, and they buy faster because they trust you. From the ongoing parts they will never take in-house — updates, audits, the on-call rota nobody wants. And from the referrals a company gives when they got what they paid for.

The alternative model — revenue from confusion — has a ceiling and an unpleasant ending. It just takes a few years to arrive, which is why so many companies drift into it.