When a placed engineer leaves at month four, the invoice stops and it looks like you saved money. You didn’t. You paid for weeks of ramp-up that you’ll now pay for again, the person took whatever they knew about your system that never made it into a doc, and the work they had half-finished sits there until someone else picks it up and figures out what they meant.
Four things decide whether a placed engineer stays: an interview that screens for communication and ownership as seriously as for code, working hours that overlap with the client’s team, exit terms under which the vendor loses money when a match fails, and how the client treats the engineer in the first months. How fast the vendor fills the seat matters far less than any of them.
Gallup puts the cost of replacing an employee at one-half to two times their annual salary. A contractor isn’t an employee, and the paperwork is lighter, but the part that hurts most (lost context and a team that has to slow down to onboard again) is the same.
Why is there no retention percentage here?
A lot of vendors put a big number on their homepage: 95% retention, 98% client satisfaction. I don’t, and I want to explain why instead of just leaving it out.
Softronic is small and I run it myself. I place one engineer at a time and I interview every one of them. At that size, any percentage I published would be calculated on so few engagements that one client closing their company, or one person relocating for family reasons, would swing it by double digits. That’s arithmetic, and it tells you nothing about what happens to your hire.
When a vendor of any size quotes you a retention rate, ask two things: how many placements it’s calculated on, and what counts as a departure. A company that ended the contract because it ran out of funding and an engineer who quit after three months look very different, and some vendors only count one of them.
What I can describe is how the engagement is built, one factor at a time. Check each of them against me and against anyone else you’re talking to.
1. Most bad fits are visible in the interview
In my experience, engineers rarely leave a placement because they couldn’t do the technical work. They leave, or get let go, because of something that was visible in the interview and got waved through because the coding part went well: they go quiet when blocked, they need a fully specified ticket to start, or they write updates nobody can act on.
That’s why the last of my three vetting interviews is about communication and ownership, with no code in it. One question in it matters most for retention: what do you do when you’ve been stuck for two hours and the person who knows the answer is in a meeting? In a remote team, how someone handles that moment is a large part of how the team comes to see them.
A candidate who gives vague answers there can still pass a live coding exercise. They’re also the one I’d expect to be gone by month six.
2. Working hours that overlap
An engineer who spends half the day blocked waiting for answers wears down fast. The work becomes a series of small stalls, they start guessing instead of asking, and the guesses create rework that makes everyone frustrated with them.
This is the part of nearshore hiring that gets undersold. Latin American engineers can work inside US business hours, which means a question asked at 11 a.m. gets answered at 11:15, not the next morning. I’ve written about the cost side of nearshore versus offshore separately. For retention, the point is simpler: a job where you can get unblocked in real time is a job people want to keep.
In practice, I agree the working window with the client before anyone starts, so the engineer is there for your standup, your code reviews, and the hours when decisions get made in Slack. “Remote, flexible hours” sounds nice in a job post and tends to mean the new person is always a few hours behind the conversation.
3. When it fails, the vendor should lose something
If the fit is wrong with us, you give 30 days’ notice and the engagement ends. No claw-back, no penalty, and we don’t bill you for the transition. The lost revenue is ours.
I’m also careful about what I don’t promise. I won’t tell you a replacement candidate will be in your inbox within a week. I don’t keep a bench of engineers sitting idle, and a vendor who guarantees a seven-day replacement either pays people to wait (and prices that into your rate) or plans to improvise when the time comes.
Exit terms matter for retention because of what they do at the moment of matching. When a bad match costs the vendor the contract, the vendor has a reason not to push a marginal candidate to close a deal. When the vendor gets paid either way, or collects a placement fee up front, that pressure points the other direction. Read the exit clause before the rate card.
4. The engineer’s side of the deal
Retention is usually discussed from the client’s point of view. But the engineer decides whether to stay too, and a senior engineer in Latin America today has options.
The things that keep people, from what I’ve seen, are not exotic. Getting paid in full and on time, in dollars. Being treated as part of the team rather than an external resource that receives tickets. Having someone on the client side who knows their name and cares whether they’re doing well. Working on something where their judgment is wanted.
Most of that is in your hands, not the vendor’s. A few things you can do in the first month:
- Give them access to the repo, CI, and the main channels on day one, not day six.
- Name one person on your side who owns their onboarding and answers their questions.
- Put them in the same code review flow as everyone else. A separate “contractor” lane tells them where they stand.
- By week three, give them something small that ships to production with their name on it.
What are the warning signs before someone leaves?
Departures rarely come out of nowhere. The signs show up in the work first: pull requests that sit longer, questions that move from public channels to DMs or stop entirely, a person who is still being handed only small, isolated tickets at month two.
If your team tracks the DORA delivery metrics, change lead time is the one I’d watch. It’s the time from commit to production, and it tends to stretch when people are working in parts of the system they don’t understand yet or waiting on someone to review. DORA makes no claim about turnover here. I use it as the first place to look when a placement feels off.
The cheapest fix is a 20-minute conversation at the end of the first month: what’s slowing you down, and what do you wish you’d been told on day one? Put it on the calendar the day the engineer starts. It catches most of this while it’s still easy to fix.
If you’re comparing vendors right now, the general questions are in my nearshore partner checklist. The one specific to retention came up earlier: how many placements the figure is based on, and what counts as a departure. How I set up engagements is on the hiring page.