The Vendor Dependency Problem

There is a structural problem in enterprise L&D that rarely gets named: most L&D teams lack the technical depth to evaluate whether the training they are commissioning is any good.

This is not a criticism. It is a description of a structural condition. L&D professionals are generalists. Their expertise is in learning design, programme management, stakeholder relationships, and organisational development. They are not, typically, experts in Kubernetes, LLM fine-tuning, or penetration testing. But they are the ones deciding which Kubernetes, LLM, and pen-testing programmes to buy.

How dependency gets established

When an L&D team cannot independently evaluate a technical programme, they fall back on proxies. Vendor reputation. Trainer charisma. Participant satisfaction scores. Course outline comprehensiveness. These are not worthless — but they are uncorrelated with the thing that matters, which is whether the programme produces the capability it claims to produce.

Once a vendor relationship is established, dependency deepens. The vendor understands the client's systems. They have delivered programmes the client stakeholders remember positively. They are easy to work with. Switching costs — real and perceived — accumulate. The L&D team becomes progressively less able to evaluate whether a competitor would serve them better, because they have no independent basis for comparison.

Vendor dependency is not just a commercial risk. It is an epistemic risk — the L&D team loses the ability to know whether what they are buying is working.

What good vendor evaluation actually requires

Proper evaluation of a technical training vendor requires either technical depth in the L&D team or access to it. There are three practical approaches:

Subject matter expert involvement. Before commissioning a technical programme, involve a senior technical practitioner from the organisation in the evaluation. Ask them to review the curriculum, audit the assessments, and sit in on a sample session. Their assessment will be more reliable than any satisfaction score.

Output-based contracting. Structure vendor agreements around capability outcomes, not content delivery. Define measurable outcomes — a specific assessment threshold, a capstone pass rate, an observable behaviour change — and tie commercial terms to those outcomes. Vendors confident in their quality will accept this. Vendors who are not confident will not.

Reference depth. Most vendor references are cherry-picked. Ask for references from the last three programmes the vendor ran for organisations similar to yours — not the ones they volunteer. Ask specifically about transfer rates and long-term capability change, not about satisfaction scores and whether the trainer was engaging.

Building internal evaluation capacity

The longer-term solution is building the L&D team's ability to make independent judgements. This does not mean making L&D professionals into technical experts. It means ensuring that the team includes people who can read a curriculum and identify gaps, who understand what rigorous assessment looks like in technical domains, and who have practitioner networks they can draw on when evaluating unfamiliar subject areas.

Teams with this capacity consistently make better vendor decisions. They are harder to oversell. They ask harder questions. They are more likely to recognise when a programme that looks good on paper is thin in practice. And they are more likely to build the kind of long-term vendor relationships that actually serve the organisation — relationships built on mutual accountability for outcomes rather than mutual comfort with the status quo.