Published July 26, 2026 · Kiyansh Group
When a technical hire goes wrong, the salary is the smallest line on the invoice. The real bill shows up in the code your team has to unwind, the senior engineers who stop shipping their own work to cover, and the three to six months that pass before anyone will say out loud that the hire is not working. This is how those costs actually accrue, and how to keep the decision from becoming a six-figure mistake.
Talk to us about staffing →A common industry estimate puts the cost of a bad hire at somewhere between one and two times annual salary. For a mid-level engineer at $130,000, that is $130,000 to $260,000 before you account for anything specific to your situation. The reason the multiple is that high is that salary is only the money you can see. The money you cannot see is spread across recruiting fees you paid twice, onboarding time from people who bill at senior rates, and the output you expected but never received.
Ramp is the first hidden cost. A competent engineer takes two to three months to become genuinely productive in an unfamiliar codebase, and longer in a domain-heavy one like payments, healthcare, or logistics. You are paying full freight during that window on the bet that it pays back over the following two years. When someone leaves or is managed out at month five, you never reach the payback. You funded the entire ramp and collected almost none of the return.
Then there is opportunity cost, which is the hardest to quantify and often the largest. The roadmap item that seat was supposed to own does not ship. The customer commitment made on the assumption of that capacity slips. You do not just lose the salary, you lose the thing the salary was meant to buy.
A weak hire does not fail quietly in a corner. The work still has to get done, so it flows uphill to your strongest engineers, who now spend their days reviewing pull requests that need three rounds of comments, pairing to unblock, and quietly rewriting what shipped over the weekend. Every hour a senior engineer spends babysitting is an hour they are not spending on the architecture and hard problems you actually hired them for.
This is where the cost compounds in a way spreadsheets miss. Your best people notice when the bar drops. They notice when their own velocity is being taxed to subsidize someone who is not carrying weight. Strong engineers have options, and nothing pushes them toward those options faster than the sense that the team no longer protects the standard they came for. One bad hire that triggers a good one to leave has effectively cost you two.
Morale erosion is real but slow, which is exactly why it is dangerous. It rarely shows up as a resignation with a clear reason attached. It shows up as reduced discretionary effort, fewer volunteers for the hard tickets, and a team that has stopped believing hiring will fix anything. By the time it is visible, it has already been expensive for a while.
Code written by someone who does not fully understand the system does not simply get deleted when they leave. It ships. It goes to production, it accrues dependencies, and other features get built on top of it. When you later discover the shortcuts and the misunderstood requirements, you are not fixing a module, you are unwinding months of downstream decisions that assumed the original work was sound.
This is the tech debt that has a person's name on it, and it is uniquely stubborn because the person who wrote it is gone and cannot explain the intent. Your team reverse-engineers what was meant, decides whether to patch or rewrite, and either way pays interest on a loan they did not take out. A single poorly designed data model or a rushed integration can cost more in cumulative rework than the hire's entire tenure did in salary.
The quiet damage is to trust in the codebase itself. When engineers stop believing that existing code is correct, they slow down. They re-verify things that should be settled. That defensive tax gets paid on every future change, long after the person who caused it has moved on.
The most expensive property of a bad technical hire is the delay in diagnosis. Nobody wants to conclude at week six that a hire was a mistake, so the benefit of the doubt stretches. Managers attribute slow progress to ramp. Peers cover the gaps out of professional courtesy. The problem hides inside the normal noise of onboarding until enough evidence accumulates that it can no longer be explained away, and by then a quarter or two has passed.
During that lag you keep paying salary, you keep burning senior review time, and the roadmap keeps slipping without a clear cause. Then you enter the exit process, which has its own cost in management attention, documentation, and often severance. Add the time to backfill, and a single bad hire can consume the better part of a year of a seat's productivity while producing very little of it.
This is why the cheapest place to intervene is before the offer, not after. Every dollar spent on rigorous evaluation up front is defending against a downstream loss that is an order of magnitude larger.
The structural fix for the diagnosis lag is to shorten the feedback loop and make the early period reversible. Contract-to-hire does exactly that. Instead of committing to a permanent relationship based on a few hours of interviews, you evaluate against real work over a defined period. You see how someone handles your actual codebase, your review cycles, and your ambiguity, and you convert to full-time only when the evidence is in. The bad-fit case that used to take six months and a termination to resolve becomes a contract that simply concludes.
Pre-vetting attacks the same problem from the front. A candidate who has already been through a technical screen, a work-sample review, and reference checks before they reach your loop carries far less unknown risk. You are not the first line of defense against a mis-hire, you are the confirmation step. That is a meaningfully different bet, and it is why teams that lean on vetted contract talent for uncertain roles tend to absorb fewer of the six-figure surprises described above.
None of this removes the need to hire well. It changes where the risk sits and how quickly you can act on it. The goal is not to avoid ever being wrong about a hire, it is to be wrong cheaply and early instead of expensively and late.
Common estimates land between one and two times annual salary, but the honest answer depends on seniority and how long the problem hides. Add lost ramp investment, senior review time at high hourly rates, rework and tech debt, backfill, and the roadmap items that never shipped. For a mid-level engineer, a real total in the low six figures is normal once you count everything, not just the paycheck.
Typically three to six months, because early underperformance looks identical to normal ramp and teams extend the benefit of the doubt. That diagnosis lag is the single most expensive property of a bad hire. Shortening it, through clear early milestones or a contract-to-hire structure, is where most of the savings come from.
Yes, because it replaces a permanent bet made on limited information with an evaluation against real work over a defined window. You convert to full-time only after seeing performance in your actual environment. A bad fit ends as a contract conclusion rather than a termination, which is faster, cheaper, and far less disruptive to the team.
If you would rather confirm a hire against real work than gamble on a few interviews, Kiyansh places pre-vetted contract and contract-to-hire engineers so you can be wrong cheaply and right permanently.
Start a conversation →