Insights · Capability

Capability beats dependency.

There are two kinds of AI engagement. One leaves your organisation stronger: people who understand more, governance that is clearer, capability you own. The other leaves you dependent, and calls the dependency a partnership. Learn to tell them apart before you sign.

Why is dependency so common?

Because nobody designs it and it sustains itself anyway. Become the one who operates the thing, keep the understanding of how it works on your side of the line, and the arrangement renews without anyone deciding to renew it. It arrives quietly, engagement by engagement, until the basics cannot function without the partner who built them.

The AI wave is manufacturing dependency at speed, because urgency suppresses the questions that would normally catch it. When everyone is racing, nobody asks who will hold the map afterwards.

What does capability look like instead?

Your people make better decisions than they did before the engagement. Internal champions exist, and they train others. The governance is documented, owned and operated by you. The system can be extended without a phone call. And the relationship with the partner continues, if it continues, because their judgement keeps earning its place, not because leaving is unthinkable.

The blunt test: could you carry on without them if you chose to? The healthiest client relationships we have are the ones where the answer is yes, and the client stays anyway. Some of ours have lasted more than seventeen years on exactly those terms.

Does that mean building everything in-house?

No. In a fast wave, buying experience is often the quickest way to avoid expensive lessons. The distinction is not build versus buy. It is whether what you buy transfers. Buy judgement, and insist it rubs off. Buy delivery, and insist your people are inside it, not watching it. Buy a platform, and insist you can run it.

Own your AI. Waiting for a vendor to align their roadmap with your edge cases is how companies discover, too late, whose capability it really was.

How do you contract for capability?

Put it in the scope, explicitly: capability goals alongside delivery goals, named internal owners, handover designed from the start rather than improvised at the end, and adoption measured in behaviour. Then ask the uncomfortable question at every review: are we more able to do this ourselves than we were last quarter? If the answer keeps being no, you are not buying a service. You are renting a ceiling.

Common questions

Should we build in-house or buy in?

Both, in the right order. Buy judgement to move fast; structure every engagement so capability transfers.

How do you spot a dependency-builder?

Engagement design. Capability builders write handover and champions into the plan and can tell you how you will need them less next year.

What is a fair long-term role for a partner?

The judgement that keeps mattering: the next hard decision, the next wave. Not operating things you should own. The one thing no engagement can transfer on a schedule is fluency itself, which is the months you cannot buy.

Want capability that stays?

That is what enablement means →