18 November 20257 min read
The awkward version of this conversation happens eight weeks into a project. A client notices a name they do not recognise on a pull request, or an email domain that is not yours, or a public holiday nobody warned them about, and asks a question you now have to answer defensively. Nothing has actually gone wrong with the work, and yet you have spent trust you cannot easily get back.
The comfortable version happens in the sales conversation, takes about ninety seconds, and is almost never objected to. The difference between them is not honesty in some abstract sense. It is timing.
What clients actually object to
It is worth being precise about the objection, because agencies tend to imagine a stronger one than exists. Very few clients believe they are buying a specific set of employment contracts. What they believe they are buying is accountability: that one company answers for the outcome, and that they do not have to manage a chain of suppliers themselves.
So the objection is rarely to the existence of a partner. It is to three specific things.
- Being surprised, which reads as concealment even when it was only awkwardness.
- Being handed a supplier chain, where a problem gets explained as someone else's fault and the client is left to arbitrate.
- Being charged a premium for capability they now suspect they could have bought directly.
All three are addressable, and all three are made worse by delay.
Say it in the sales conversation, in one line
The disclosure that works is short, unapologetic and framed around accountability. Something close to: we deliver with a long-term partner team who work as part of our delivery organisation, we manage them, and we are accountable to you for the result. Then stop talking. If you deliver that line as though it were a confession, the client will treat it as one.
Notice what it does not do. It does not oversell the partner's independence, which would raise the question of why the client is not buying directly. It does not hide behind vagueness like our extended team, which sounds like a euphemism because it usually is. It states the arrangement and it states who answers for it.
Clients do not buy your employment contracts. They buy a single accountable party, and that is exactly what a well-run partner arrangement gives them.
What goes in the contract
Most client agreements already contain a subcontracting clause, and it is usually one of two shapes: you may subcontract with the client's prior written consent, or you may subcontract and remain fully liable for your subcontractors' performance. The second is the one to have. Consent clauses give the client a veto they will rarely exercise but which hangs over every staffing decision you make.
Two other things belong in the same section. Confidentiality and data protection must flow down: whatever you promised the client about handling their data, you must have promised your partner in writing, including a data processing agreement where personal data is involved. And IP assignment must be unbroken, so that rights vest in the partner's people, pass to the partner, pass to you, and pass to the client without a gap in the middle. A gap in that chain is the one client-facing problem that a lawyer will find years later and that cannot be fixed retroactively without everyone's goodwill.
Presenting the team day to day
Once disclosed, the practical question is how the partner team appears in the work. There is a workable middle between pretending they are your employees and making the client manage two companies.
Use your tooling. The partner works in your repository, your ticket tracker, your Slack or Teams, under your definition of done and your review standards. This is not cosmetic: shared tooling is what makes you able to see the work, which is what your accountability actually rests on.
Introduce people by name and role. Anonymous resources are less trusted than named individuals, and clients who know who is doing the work behave better towards them. If a partner engineer joins a client call, that is normal and good, provided your lead is in the room and the client's questions are answered by one voice at the end.
Be honest about calendars. Public holidays differ between countries, and a holiday nobody mentioned looks like a missing person. A shared calendar of both organisations' non-working days, sent at the start of the engagement, removes an entire category of small suspicion.
What not to do
Do not issue partner staff email addresses at your domain and hope nobody looks. Beyond the security and data-protection questions, it converts a disclosure problem into a misrepresentation problem, and the client's reaction on discovery is proportionally worse.
Do not let partner staff attend a client meeting where the client believes they are talking to your employees. It puts a person in the position of either lying on your behalf or contradicting you, and both are unfair.
Do not explain a delay by naming the partner. The moment you say the partner was late, you have told the client there is a supplier chain and that you do not control it. You bought a single accountable party for your client; behave like one, and take the failure yourself.
If you have already not disclosed
Plenty of agencies read this from the middle of an engagement where the conversation never happened. The move is a scheduled, planned disclosure rather than waiting to be caught: raise it in the next review, describe the arrangement, say who is accountable, and pair it with something that demonstrates control, a quality report, a calendar, a named lead. It will be a slightly uncomfortable ten minutes. Discovery is a permanently uncomfortable relationship.