A reasonable default is 30 days (our judgment, not an industry standard) to decide whether an underperforming staff augmentation developer gets fixed or replaced. Most of that window should go to ruling out your own side first, because some "bad engineer" cases turn out to be setup failures: no repo access, vague tickets, nobody reviewing pull requests. If you've audited all of that and the gap is still there, you replace. Quickly and in writing.
This applies to one augmented engineer from any vendor. If you're choosing between models in the first place, Software development engagement models: staff augmentation, dedicated teams, nearshore and offshore compares them side by side.
Is it the developer, the setup or the vendor?
Start with the symptom, not the person. The same symptom (nothing merged in a week) has three very different causes, and each one has a different first move.
| Symptom | Likely cause | First action |
|---|---|---|
| No commits in the first days | Blocked access: repo, secrets, IAM, VPN | Check every permission yourself |
| PRs open for days with no feedback | Your review lag, not their speed | Name a reviewer and set a turnaround |
| Work comes back off-spec | Vague tickets or no acceptance criteria | Rewrite two tickets and compare the result |
| Asks no questions, goes quiet | No named tech lead, unclear who to ask | Assign one person as first contact |
| Misses the same bar after fixes | Skills or fit gap | Move to step 2 below |
| Several engineers from one vendor struggle | Vendor vetting or staffing problem | Escalate at account level |
One staffing firm, in its own staff augmentation guide, treats secrets or IAM access still blocked after day 2 and no pull request by day 4 as red flags, and a velocity plateau below your internal median in days 31 to 90. That's one vendor's benchmark, not an industry standard, but the shape is useful. The first flags (days 1 to 5) are access and onboarding problems. The later ones (rejected PRs, constant hand-holding, a velocity plateau) point at the engineer's output, but several of them also trace back to specs and review habits on your side.
What counts as underperforming, in writing
"Not working out" is not a definition, and replacement windows vary from vendor to vendor, so the term means little unless it defines what is being measured. Write yours before the engineer starts.
Measure against your own team, not an abstract bar. Three numbers are enough: velocity or throughput compared with your team median at the same seniority, pull request cycle time, and review turnaround (both how fast they review others and how many rounds their own PRs need). Add one qualitative item, such as whether they raise blockers early.
Anadea's staff augmentation best-practices post offers two warning signs worth borrowing as starting points: a team satisfaction score under 5 out of 10 and a velocity gain under 20%. Treat those as examples. Pick your own thresholds before day one, and put them in the same document as the engagement terms so nobody argues about them later.
How to handle an underperforming augmented developer
1. Check your own side first
Before you say anything to the engineer or the vendor, audit what you control. Can they reach the repo, the CI pipeline, staging, the ticket board and the docs? Were their first three tickets specified well enough that a new hire in the office would have succeeded? Is there a named tech lead who answers questions within a few hours? How long do their PRs wait for review?
Be honest here. If your reviews take three days, a "slow" engineer is partly you. Fix what's yours and give it about a week (a judgment call). If the pattern persists after that, you have a real signal.
2. Give specific examples, in writing
Vague feedback ("I need more ownership") can't be acted on or enforced. Write down three to five dated examples: the ticket, what was expected, what was delivered, and the gap. Link the PRs. Keep the tone factual.
Anadea's advice is blunt on this point: if a specialist isn't delivering, don't stay quiet for months, give specific examples, agree a timeframe for improvement, and escalate if nothing changes. The written record matters later, because the vendor will ask for it and any contract dispute will depend on it.
3. Agree a short improvement window
Two weeks is a reasonable default. That's a judgment call, not a sourced standard, so adjust it to your sprint length. The window should have two or three concrete targets taken from your definition above, such as "PRs merged with no more than two review rounds" or "blockers flagged same day."
Say the window out loud, with the engineer and their vendor contact present or copied. Surprises at the end of it help nobody.
4. Escalate to the vendor with the same document
Send the vendor the same written examples and targets the engineer got. Don't rewrite them into a complaint. Ask for three things: their read on the cause, what support they'll provide (a call with the engineer, a mentor, a scope change), and a replacement plan on standby if the window passes without improvement.
Anadea makes the point from the buyer's side: a provider worth keeping would rather replace the person than lose you as a client. If the vendor gets defensive or stalls, note that. It's information about the next engineer you'd get from them.
5. Decide: replace or keep
At the end of the window, compare the targets with the results. Keep the engineer if the trend is clearly upward and the remaining gap is small, if the issues were mostly on your side, or if the person is strong in a narrow area and you can reshape the role. Replace if the same misses repeat after the setup is fixed, if they don't respond to feedback, or if the gap is a skills mismatch for the stack you actually run.
A half-decision is the expensive one. Extending "one more sprint" three times can burn six weeks of a senior engineer's rate plus the drag on everyone reviewing their work.
6. Run the replacement handover
Ask for overlap days between the outgoing and incoming engineer where the contract allows, and use them for knowledge transfer: open branches, undocumented decisions, where the bodies are buried. Sphere's guide to software staff augmentation lists a knowledge-transfer buffer among the things to ask a vendor about before signing, which is the right instinct. Get it agreed in advance.
Then close out access the same day: revoke repo, cloud, SaaS and VPN credentials, rotate any shared secrets they touched, and reassign their tickets. Check whether the contract lets you avoid billing for the new engineer's ramp-up. It's worth asking.
7. Review the contract terms you learned from
Whatever slowed you down, whether it was a vague definition, a slow replacement window or a ramp-up charge, goes into your template for next time. The vendor-evaluation checklist covers what to check in replacement and notice terms before you sign, so the next problem starts from a better position.
What replacement terms to ask for
Four clauses do most of the work.
The first is a definition of "not working", tied to the measures above rather than to the vendor's discretion. The second is the replacement window, with the clock start stated: from your written notice, not from the vendor's acknowledgement. The third is who pays for ramp-up, and whether the first days of the replacement are billable. The fourth is notice and handover: how much notice you must give, and how many overlap days the vendor provides.
As one example of a replacement term, the staffing firm mentioned earlier advises buyers to ask for a contract that lets them swap out an augmented engineer within the first two weeks at zero cost if the engineer misses technical standards or initial pull request benchmarks. A window that short only helps if the contract defines those standards, so read the fine print rather than the headline.
You don't need to treat these as adversarial. Many vendors have standard replacement language, so ask for yours to be added.
When the problem is the vendor, not the person
If a second or third engineer from the same vendor shows the same pattern, you're not looking at an individual problem. Weak vetting, a thin bench or staff rotated off your account all show up this way. Swapping people won't fix it. At that point you're better off reading about replacing an entire offshore team, which covers diagnosing the failure, reviewing exit rights, securing access, running a parallel pilot and exiting the old vendor cleanly. Don't let a single weak engineer force that decision, but don't ignore a pattern either.
Replacing an engineer through HighCircl
If the engagement isn't working, HighCircl replaces the engineer at no additional recruitment cost. Shortlists are 3-5 candidates, matched within 72 hours, from a pool where about 1 in 10 applicants pass four vetting stages. There's no minimum hour commitment, no subscription and no recruitment fee. A deposit of one month's estimated cost is applied to your first invoice. Rates run €45-105/hr ($50-115/hr), with a 20% capped margin on top of what the engineer earns. You can start on HighCircl's hire page.
FAQ
How long should you wait before replacing an underperforming developer?
There's no sourced industry number. A workable pattern is a week to fix your own side, then a two-week written improvement window, so a decision lands inside about 30 days. Move faster if the problem is plainly a skills mismatch, and slower if the cause was access or onboarding that you've only just fixed.
Who pays when a staff augmentation developer is replaced?
It depends on the contract. Some vendors replace at no additional recruitment cost, which is HighCircl's policy. Other vendors' terms differ, so ask whether replacement is free and whether the new engineer's ramp-up is billable. Ask for both in writing before you sign, while you still have negotiating room.
Can you replace a contractor developer without breaching the contract?
It depends on your contract's notice and replacement clauses, which is why the written record from step 2 matters. Terms differ between vendors and countries, so check the notice period, the definition of unsatisfactory performance and any minimum term. This isn't legal advice. For anything unclear, ask a lawyer to read the clause.
What if the replacement also underperforms?
Check your own side again before blaming a second person. If your access, specs and review turnaround are sound and a second engineer misses the same bar, the likelier cause is the vendor's vetting or your requirements. Raise it at account level, and read the section above on when the problem is the vendor.