Every founder eventually faces it: a developer who is not working out. The work is slow or wrong, deadlines slip, or the fit is off, and you feel it but keep hoping the next sprint turns it around. It rarely does, and the hoping is one of the most expensive habits in a small company, because a struggling engineer on a tiny team drags down everyone around them. The better path is unglamorous: diagnose the problem honestly, give a real and specific chance to correct it, and if that does not work, act decisively instead of letting it drift for months.
Key Takeaways
- Waiting and hoping is the common response and usually the wrong one.
- First diagnose honestly: is it skill, clarity, fit, or something external.
- Give a specific, time-boxed chance to correct, not vague dissatisfaction.
- If it does not turn around, act decisively; dragging it out costs more than the hard conversation.
Diagnose Before You Judge
Before deciding a developer is not working out, figure out why, because the fix depends entirely on the cause. Sometimes it is a genuine skill gap, the person cannot do the work at the level the role needs. But often it is something more fixable: unclear expectations they were never actually given, a lack of context or onboarding that left them guessing, a mismatch between what they were hired for and what they are being asked to do, or an external factor you do not know about. Jumping straight to "this was a bad hire" when the real problem is that nobody told them what good looked like is both unfair and a waste of someone who could succeed with clarity.
| Apparent problem | Possible real cause |
|---|---|
| Slow or wrong work | Unclear expectations, weak onboarding |
| Missing deadlines | Overcommitment, hidden blockers |
| Poor fit | Wrong role, not wrong person |
| Disengaged | External factors, or a real mismatch |
Give a Real Chance to Correct
If the diagnosis points to something correctable, the fair and effective move is a specific, time-boxed chance to fix it, not a cloud of vague dissatisfaction. Tell the person clearly what is not working, what good would look like, and by when, then support them to get there. This does two things: it gives a fixable situation a genuine shot, and it makes the eventual decision clear either way. Vague unhappiness helps no one, because the person cannot correct a problem they have not been told about in concrete terms.
A Concrete Version
Picture a developer whose output has been disappointing for a month. The weak response is to stew, drop hints, and wait for improvement that does not come. The strong response is a direct conversation: here specifically is where the work is falling short, here is what I need to see, let us check in two weeks, and here is the help available to get there. Two outcomes follow. Either they hear it, the real issue was clarity or context, and they turn it around, in which case you saved a good engineer. Or the check-in comes and the gap is still there despite real support, in which case you now have a clear basis to act, and you act, rather than letting it grind on for another quarter of everyone's frustration.
When It Is a Contractor or Augmented Engineer
The calculus shifts when the person is a contractor or an augmented engineer rather than a full-time employee, because you have more flexibility and less friction to make a change. This is one of the underrated advantages of staff augmentation: when a placement is not working out, a good partner can move quickly to replace them rather than leaving you stuck. It is the logic behind Ruzora's 30-day replacement guarantee, which exists precisely for the case where an engineer underperforms on technical grounds early on, so a miss becomes a swap instead of a drawn-out problem you carry alone (how to de-risk hiring a nearshore developer).
The Honest Counterpoint
Acting decisively does not mean acting hastily, and the opposite failure is real too. Some managers pull the trigger too fast, mistaking a rough first month, common even for strong hires as they ramp, for a permanent problem, and lose someone who would have become excellent (the j-curve of new hires). The diagnose-and-correct step exists partly to guard against this, to distinguish a slow start from a genuine mismatch. The goal is neither endless hoping nor a hair trigger, but honest diagnosis, a fair and specific chance, and then decisive action once the evidence is actually in.
The Bottom Line
When a developer is not working out, the expensive mistake is to wait and hope. Diagnose the real cause first, since the answer is often fixable clarity or fit rather than raw ability. Give a specific, time-boxed chance to correct, which is fair to them and clarifying for you. And if it still does not turn around, act, because dragging it out costs your team far more than the hard conversation does. With contractors and augmented engineers, that action can be a fast replacement rather than a painful unwind, which is much of the point of hiring that way.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
