The uncomfortable part of this topic is not the replacement mechanics. It is that in almost every engagement that went wrong, someone knew by the end of week two and said something in month three. Six weeks of a fixable problem were spent hoping it would resolve itself.
So this article is in two halves: how to see it early, and what your contract needs to say so that seeing it early is useful.
The signals that show up in week two
Almost none of them are about code quality, which is the thing managers watch. Code quality is visible but slow — a weak engineer can produce acceptable-looking output for a month. The fast signals are in communication:
- Questions do not arrive. A good engineer joining an undocumented code base generates a stream of specific questions in the first week. Silence means either they are not engaging with the hard parts, or they are not comfortable asking. Both are problems and both get worse.
- Status updates describe activity rather than progress. "Working on the migration" three days running, versus "migration is blocked on the staging credentials, here is what I did instead."
- Estimates never change. An engineer who says three days on Monday and still says three days on Wednesday is not estimating; they are repeating.
- Pull requests are large and narrative-free. A 900-line PR titled "fixes" in week two tells you how the next six months will read.
- They agree with everything. The single most reliable early warning. A senior engineer looking at someone else's architecture has an opinion within ten days. Total agreement usually means disengagement, sometimes means a language barrier you have not accounted for, and occasionally means they do not understand the system well enough to disagree.
Notice what is not on that list: accent, typing speed, and how much they talk in standup. Those correlate with nothing.
Two checkpoints, written down in advance
The reason problems get raised in month three is that nobody scheduled a moment to raise them in month one. Fix it structurally with two short reviews you announce at the start, so neither party experiences them as an ambush.
Day 10 — calibration. Thirty minutes. Three questions: what is still confusing, what would you change about how we work, what do you need from us. Written answers before the call, so you get the real version rather than the diplomatic one. Most fixable problems are fixable here, and most of them turn out to be yours: missing access, no documentation, an unclear owner.
Day 30 — decision. The honest one. Would you hire this person again, knowing what you know now? If the answer is anything other than yes, say so at day 30, while a replacement is still free and the sunk cost is one month rather than four.
What the contract needs to say
Early detection is only worth something if you can act on it. Three clauses decide whether you can:
| Clause | What good looks like | What to watch for |
|---|---|---|
| Replacement | Free replacement inside the first 30 days, no cause required | "Replacement at our discretion" — which means no replacement |
| Notice | 30 days, symmetrical, either side | 90-day notice, or notice that binds only you |
| Term | Month to month | 12-month minimum with early termination fees |
| Ramp-up | The replacement's first weeks are not billed twice | Silence — then you pay full rate for onboarding you already paid for |
A vendor confident in its screening will offer the first three without being asked. Engagements through HireBrazilDevs are month to month with 30 days notice either way and a free replacement in the first 30 days, and the pricing page states both without a call. The point is not that these terms are generous — it is that a vendor who will not write them down is telling you how confident it is in its own selection.
How to run the replacement without losing a month
- Say it early and in writing. One paragraph: what was expected, what happened, what you decided. No performance theatre, no three-week improvement plan you do not believe in.
- Ask for the brief to be revised, not repeated. The first miss usually means the brief was wrong, not that sourcing was unlucky. What did this engagement teach you about the actual requirement?
- Keep the handover to the code, not the person. A departing engineer writing a two-page handover of decisions and gotchas is worth more than two weeks of overlap.
- Cut access on the last day. Not the last week. This is a checklist item, not a statement about anyone.
What waiting actually costs
The reason managers delay is that ending an engagement feels expensive and awkward, while waiting feels free. It is not. Put rough numbers on a senior engagement at $4,900 a month and the arithmetic goes like this.
| Decided at | Fee spent | Replacement cost | Work delivered |
|---|---|---|---|
| Day 30 | One month | Free, inside the guarantee | One month lost, roadmap intact |
| Month 3 | Three months | Full rate from day one | Three months lost, plus the code left behind |
| Month 6 | Six months | Full rate, plus untangling | Six months, and now a quarter has slipped |
The line that does not appear in the table is the one that costs most: the work a functioning engineer would have delivered in the same period. A decision at day 30 is a bad month. The same decision at month six is a missed quarter, and usually a conversation with someone above you about why the roadmap moved.
There is a second hidden cost in waiting, and it is the one that surprises people. Teams tolerate an underperforming member by routing around them — the important work quietly goes to someone else, who is now carrying two jobs. By the time you act, you often have two problems: the hire that did not work, and a tired senior engineer who has been absorbing the difference for four months.
When it is not the engineer
Worth saying plainly, because it is common: a meaningful share of failed engagements are a client-side failure wearing an engineer's name. No owner on the client side, a brief that described a stack instead of a problem, a code base nobody can explain, or a manager on Pacific time who scheduled every decision meeting inside two hours the engineer cannot attend.
The test is simple. If the last two people in that seat failed the same way, the seat is the problem. Replacing the person again will produce the same month. The mistakes guide covers the client-side patterns, and the onboarding guide covers the first week that prevents most of them.
The short version
Run a day-10 calibration and a day-30 decision. Watch communication, not code, in the first fortnight. Make sure the paper lets you act: month to month, 30 days notice, free replacement in the first 30 days. And when it is not working, say it in week four rather than month four — that is the entire difference between a bad month and a bad quarter.