Work you can't throw over the wall
Four tests for whether work can be handed over — and what we turn down.
Outsourcing works. It works reliably for work that can be described completely, measured objectively, and performed without continuous reference to context the provider does not hold. A great deal of work meets that description, and where it does, a provider will usually do it better and cheaper than you will.
The failures happen when work that does not meet that description is structured as though it does. The symptoms are familiar: escalations that take days because nobody outside your organisation can make the call, output that is technically to specification and useless in practice, and a steady drift where the specification grows to cover cases that keep appearing.
Four tests separate the two categories. They are not subtle, and they can be applied in an afternoon.
Context dependency
Can the work be done correctly by someone who knows only the specification? Or does doing it well require knowing this customer's history, this product's peculiarities, the reason a previous decision was made? If context is a prerequisite, a handover boundary is where the work fails.
Judgement
Is there a right answer that can be checked against a rule, or does someone have to weigh trade-offs and be accountable for the choice? Judgement cannot be specified. It can only be developed, in someone who stays.
Continuity
Does value accumulate in the person doing it? If the eighteenth month is materially more productive than the first because of what has been learned, then interchangeable resourcing destroys the thing you are paying for — and interchangeable resourcing is what makes provider economics work.
Collaboration
Does the work require being inside your process — your standups, your reviews, your escalation path, in front of your customers? Or can it be handed across a boundary in defined units? If it is the former, structure has to follow.
Failing one test is a design constraint. Failing three is a warning
Work that fails one of these can often still be handed over with care — a strong onboarding, a documented escalation path, a named individual rather than a pool. Work that fails three cannot, no matter how good the provider or how detailed the statement of work, because the model itself is removing the conditions the work needs.
In that case the people doing the work need to be inside your organisation. Not necessarily employed by you, and not necessarily in your country, but inside your teams: your tools, your rituals, your review process, your escalation path, with names your colleagues and customers know. That is a different purchase from an outsourced function, and it is the distinction that matters when comparing options.
What this looks like in practice
The roles that consistently fail the tests are the ones where the work and the customer are entangled: software and product development on your own codebase, implementation and delivery consulting, project and programme management, application and technical support at second and third line, customer success on complex products, and specialist operations in regulated or technical domains.
The roles that pass — high-volume transaction processing, first-line triage against a script, well-bounded QA execution, standardised back-office administration — are genuinely better served by a provider built for them. Recommending an integrated team for that work would be selling you the more expensive answer.
What we turn down
Requirements where the work is a defined process at volume and the objective is unit cost. A provider is the right answer and will beat us on it.
Single-role requirements in markets with no existing structure, where establishing an arrangement for one person is disproportionate to the outcome. Where a structure already exists, one specialist is entirely workable; where it does not, one role rarely justifies creating one, and saying otherwise would be selling the setup rather than the result.
Requirements where the specification is fixed but the capability behind it has not been examined — a request for two named engineers in a named country when the underlying need has not been described. That is not a refusal so much as a different first conversation, and it is a better use of everyone's time than filling the order.
If the work needs context, judgement, continuity and collaboration, no contract structure will substitute for the people being inside your organisation.