21 May 20267 min read
Engagements rarely end because of a single catastrophe. They end because something started degrading in month two, nobody named it, and by month five the relationship had accumulated enough resentment that the next disappointment became the reason to stop.
Almost all of that is recoverable if it is caught early. What makes it hard is that the early signals are quiet and easy to explain away individually, and the loud signals arrive far too late.
The signals that arrive early
- Questions stop. A team that was asking three or four clarifying questions a week goes silent. This is almost never because everything became clear.
- Estimates start arriving padded, or stop arriving with any range at all. Padding is a defensive response to having been punished for an honest estimate.
- Delivered work is technically correct and misses the point, repeatedly, which means the reasoning is not reaching them even though the requirements are.
- Pull requests get larger. Small changes are a sign of confidence; large ones often mean someone is working alone for longer before exposing anything.
- The same person answers every question on their side and you never meet anyone else.
- Status updates become more polished and less specific.
Individually each has an innocent explanation, and usually the innocent explanation is offered. Two or three at once, sustained over a month, is a pattern rather than a coincidence.
Question-to-answer latency, in both directions
If you watch one number, watch how long a blocking question takes to get an answer. It is the earliest quantitative signal available and it moves before delivery does, because people work around a slow answer for weeks before it shows up as a missed date.
Measure it in both directions, and pay particular attention to your own. In a large share of engagements that are described as failing, the vendor's latency is fine and the client's is measured in days, because the person who can answer is in four meetings and the question is not their priority. That is the client's failure, and it is fixable in an afternoon by naming a person and a commitment.
The other useful half of this measurement is the trend rather than the absolute. Latency that climbs steadily from hours to a day over six weeks tells you something is being avoided, on one side or the other.
Work out whose problem it is before you escalate
There are three honest possibilities and they call for completely different responses. It can be capability: the people assigned cannot do this work, or have been quietly swapped for less experienced ones. It can be the work: the requirements are ambiguous, keep changing, or depend on something the outsourced team cannot see. Or it can be you: slow answers, absent decisions, review queues, changing priorities every fortnight.
The diagnostic question that separates them: take three recent items that went badly and trace each one back to the first moment it went wrong. Not the delivery, the first moment. If the first moment is usually a ticket with no reasoning in it or a question that waited three days, it is not a capability problem, and replacing the vendor will reproduce it faithfully with the next one.
Have the conversation earlier than is comfortable
The most common management error here is waiting for a review point. Quarterly reviews are where accumulated grievances get delivered in bulk, which is the worst possible format: the other side hears a list of things they could have fixed months ago and did not know about, and the conversation becomes defensive rather than practical.
Say it in the week you notice it, specifically, with an example. "The last three tickets came back matching the specification but missing what we actually needed, and I want to work out why" is a workable opening. "We have concerns about quality" is not, because there is nothing in it anyone can act on.
Expect the answer to contain something about you. If it does not, either the relationship is not safe enough for honesty, or nobody has looked hard enough, and both are worth knowing.
When to stop, and how to stop well
Stop when the reset has been run honestly and the same pattern returns, when the people who were assessed during pre-vetting are no longer the people doing the work and that keeps happening, or when you have concluded the work needs someone permanent and that judgement is not going to change.
How you end it matters more than most people expect, because the cost of a bad ending is not the relationship, it is the knowledge. Give real notice, pay to the end of it, and use that period for knowledge transfer rather than for extracting a last sprint of features. Get the handover written by the people who did the work while they are still being paid and still care.
Confirm the boring things are in order: repository and infrastructure access is yours, IP assignment covers everything delivered, and there is no dependency on an account that belongs to them. If you established those at the start, ending an engagement is an administrative event. If you did not, it is a negotiation, and it is a negotiation you will conduct from the weaker position.
The version of this that is worth doing anyway
Everything above is easier if you set a review point at ninety days when you sign, with agreed criteria, before anyone has an interest in the answer. It is a normal thing to propose, most partners will accept it without argument, and the ones who resist have told you something useful for free.