The short answer
Engagements fail when the work was not defined well enough to hand over, when there was nobody with time to review and answer questions, or when the augmented developer was kept away from the context they needed. Those three account for most of what we see.
That is worth knowing because all three are fixable before you start, and none of them is solved by changing supplier.
Cause one: the work was never defined
Handing over a vague objective to someone who does not know your product produces either paralysis or the wrong thing. Your own team fills gaps from experience; a new person cannot.
The test is whether you could write down what done looks like for the first month. If you cannot, the problem is not resourcing and adding people will make it more visible rather than better.
Cause two: no review capacity
Every change needs reviewing by someone who knows the system. If that person is already fully committed, the review queue grows, feedback arrives late and by the time it does the developer has built more on top of it.
- Reserve review time in the reviewer's week rather than assuming it fits
- Keep the ratio sensible, around two or three developers per reviewer
- Watch how long reviews sit, because that number moves before anything else
- Treat a growing queue as a resourcing problem, not a diligence problem
Cause three: context withheld
Some teams keep external developers away from the roadmap, the reasoning behind past decisions, or the parts of the system considered sensitive. The intent is caution. The effect is people building against assumptions.
If a person cannot be trusted with the context needed to do the work, the engagement should not have started. Once it has, withholding context guarantees rework.
Cause four: nobody owns it on your side
| Symptom | Underlying cause |
|---|---|
| Questions unanswered for days | No named owner with time |
| Priorities change without being communicated | Relationship managed by committee |
| Problems surface only at month end | No regular check-in |
| Same issue raised repeatedly | Feedback going to the wrong place |
One named person on your side, with a weekly conversation with the supplier, prevents most of this. It is a small commitment and it is the single highest-value thing you can do.
When it genuinely is the developer
It happens, and a decent supplier will replace someone without a fight. The signals worth acting on are work that consistently needs rework after review, a pattern of the same feedback, or an obvious gap against the seniority you were sold.
Raise it early and in writing. Suppliers can act on a specific concern raised in week three; they can do very little with a general complaint delivered at the end of month four.
Checking before you start
- Can you describe the first month of work in writing?
- Who reviews, and do they have the hours?
- Who answers product questions within a day?
- Is the environment documented and working?
- Who owns the supplier relationship on your side?
Five questions. If more than one has no clear answer, fix that before adding anyone, because the engagement will surface it anyway and at a higher price.