The obvious cost of a bad engineering hire is the salary you paid for work you did not get. That is the small part. The real damage is everything around it: the time lost, the code left behind, the effect on the rest of the team. Here is what a bad hire actually costs, and how to make one far less likely.
A bad hire is not just a salary you wrote off
When people think about the cost of a bad hire, they picture the months of salary paid for underwhelming work. That is real, but it is the cheapest part. Studies and hard experience both put the true cost of a bad hire at several times their salary once you count everything it drags down. For an engineer, whose work the whole team builds on, the multiplier is higher still.
What a bad engineering hire actually costs
The bill comes from five places, most of which never appear on a spreadsheet:
- Wasted salary and onboarding. Months of pay, plus the time senior people spent ramping them up.
- Rework. Code that has to be reviewed harder, fixed, or rewritten, often after it has already shipped.
- Team drag. Your best engineers slow down to cover, correct and supervise, so you lose their output too.
- Lost momentum. The roadmap slips while the seat is filled but not productive, and again while you re-hire.
- Morale. Carrying a weak teammate is demoralising, and it is one of the reasons good engineers quietly start looking.
Why engineering hires are especially expensive to get wrong
In many roles a weak hire underperforms in isolation. In engineering, everyone builds on everyone else's work. A bad hire does not just fail to add value, they add negative value: brittle code, hidden bugs, and decisions the team lives with long after the person has gone. That is the quiet way a single wrong hire turns into months of technical debt. It is also why "some experience" is not enough, and why real seniority is worth paying for.
The slow, expensive process of unwinding it
Realising a hire is not working is only the start. In much of Europe, notice periods and process mean a permanent hire who is not working out can stay on the payroll for months. Then you begin the whole search again, and as we cover in how long it takes to hire a senior developer, that is another several months of sourcing, interviewing and onboarding, while the problem the role was meant to solve keeps waiting. The cost is measured in quarters, not weeks.
How to lower the risk
- Hire for judgment, not just a CV. Interview for how someone reasons and handles being wrong, not years served.
- See real work early. A short, paid trial or a scoped first piece of work tells you more than any interview.
- Keep the commitment reversible at first. Structure the start so that changing course, if you need to, takes days rather than months.
These are exactly the things a permanent, full-time hire makes hard and a more flexible model makes easy, a trade-off we covered in staff augmentation vs full-time hiring.
How Soroc removes most of the risk
Our model is built to take the gamble out of adding engineers. Every Soroc engineer is senior and already vetted, the opposite of the padded-CV risk we flagged in red flags when choosing a partner, and fewer than 15 percent of applicants ever reach a client. You judge them on delivered work in the first sprint, not on a hopeful interview. And because it is not a permanent local contract, if the fit is wrong you change course in days, not quarters, with no severance and no re-hiring cycle. Start with one engineer through staff augmentation and scale only once it is clearly working. A bad hire is one of the most expensive mistakes a small company can make, so the best way to lower its cost is to make it easy to undo.