The Power of Partnership

Dependency is created by accident

The moment of recognition usually arrives in a renewal meeting. Someone asks what would happen if this supplier were replaced, and the room goes quiet, not because the contract is punitive, but because the answer involves a person who has been resolving the awkward integration failures for three years and has never written down why they occur.

No one chose that. It is the natural result of a sensible policy applied for long enough: give the work to whoever can do it fastest. Knowledge accrues to the party that handles the incidents, and the party that handles the incidents becomes the only party who can. Dependency is an emergent property of convenience.

Supplier, resource, partner

These words are used interchangeably and describe three different commercial relationships. A supplier delivers to a specification and is right to build what was asked for. A resource fills a seat and takes direction. A partner shares the objective, and the distinguishing feature is that a partner is contractually and culturally permitted to say the request is wrong.

That permission is the whole difference. A supplier who tells you your specification is flawed is creating friction and risking the contract. A partner who does not is failing at the job. If your commercial arrangement punishes the second behaviour, you have bought a supplier and labelled it a partnership.

Shared outcome changes the backlog, not the language

“We share your outcomes” is easy to say and observable in exactly one place: the order of work. A partner who understands that the business is trying to reduce order-to-cash time will argue for sequencing that gets there sooner, even where the sequence contains less work for them.

Which exposes the honest tension. A partner paid for delivery has a structural interest in more delivery; nothing dissolves that, and firms claiming otherwise deserve suspicion. What can be done is to make the conflict visible: agree the business measure in advance, review the backlog against it openly, and expect the partner to nominate work to remove as well as add.

Transparency is a structure, not a disposition

Transparency described as an attitude produces friendly meetings and no evidence. Described as a structure, it produces artefacts: a roadmap with dependencies both sides can see, a decision log, and a risk register whose risks carry named owners on both sides.

There is a simple test for whether it is real. Can your finance director read the risk register without a translator? If the risks are phrased in the supplier’s technical vocabulary, they are being reported rather than shared, and risks that only one party understands are effectively unowned.

Knowledge transfer fails because of when it is scheduled

Most engagements include knowledge transfer. Most place it at the end, where it lands in the same week as go-live support, budget exhaustion and the client team’s return to business as usual. It is then delivered as documentation and a recorded session, which is a record of knowledge rather than a transfer of it.

Transfer works when it is a delivery method rather than a phase. The client’s people co-own work from the first sprint; run-books are written by whoever will be woken up by the alert; the partner deliberately steps back during the second and third occurrence of a recurring task, even though doing it themselves would be faster. It costs velocity in the early weeks. That is precisely what is being bought.

The counter-argument: not everything should be transferred

The standard advice (build it internally, avoid dependency) is right often enough to be dangerous. Some capability should not be brought in-house, and pretending otherwise produces a different failure: a single internal specialist maintaining a skill they use twice a year, badly, with no peer to check them.

The test is frequency and consequence, not principle. Capability the business exercises weekly should be internal, because the learning loop is fast enough to keep it sharp. Capability exercised rarely but with severe consequences (a certification cycle, a data migration, an acquisition integration) is usually better borrowed, and borrowed from people who do it continuously.

The mistake is not buying help. It is failing to notice when a rarely used capability has become a weekly one, and continuing to rent it. Where a capability sits should be reviewed as the business changes shape, not settled once.

Design the exit at the start

Contractual exit terms are the easy part and the least protective. Technical lock-in does not live in the contract; it lives in whose name the cloud accounts are in, whether the source and infrastructure definitions are in a repository you control, whether integrations were built to a documented interface or to an undocumented habit, and whether anyone but the incumbent has ever deployed a change.

Run the audit at the beginning, when nobody is annoyed and the answers are cheap. A partner confident in the value they add will help you write it. Relationships that continue because both sides keep choosing them are stronger than relationships that continue because unwinding them is frightening, and they tend to last longer, which is the part that surprises people.

What good partnership costs the client

Partnership is often described as though the obligations run one way. They do not. It costs the client senior attention: a decision-maker available at the pace the work moves, not at the pace of the monthly steering group. It costs the willingness to hear that a request is unwise, and to act on that rather than escalating around it.

It also costs the discipline of keeping your own people in the work when it would be quicker to hand it over. Businesses that pay those costs get partners. Businesses that do not get suppliers, which is a perfectly respectable thing to buy, provided everyone is honest that it is what has been bought. The work worth examining is the work where the client is visibly stronger afterwards.