Guides

The True Cost of a Bad Technical Hire

By Marc Molas·February 5, 2024·9 min read

The standard industry estimate says a bad hire costs between 1.5x and 3x the annual salary for the role. If you hire a senior engineer at EUR80,000 per year and it doesn't work out, you're looking at a hole of EUR120,000 to EUR240,000.

But that figure only captures what's visible. The part you can put on a spreadsheet. What actually kills a startup isn't the money that's gone -- it's the time that never comes back and the damage left behind.

The visible costs: what you can calculate

Let's start with the obvious, because it already stings:

Accumulated salary. The months you paid before realizing the mistake. Typically 3-6 months.
Recruitment costs. If you used an agency, you paid between 15% and 25% of the annual salary. If you handled it internally, the time spent on screening, interviews, and negotiation.
Severance. Depending on the country and the contract, this can range from one month to several months of salary.
Replacement cost. You start the process all over again. Another round of posting listings, screening CVs, running technical interviews, negotiating. If you're lucky, 2-3 months. If not, 6.

Add it all up and you easily reach that 1.5-3x estimate. But this is where most analyses stop. And it's where the real damage begins.

The invisible costs: what doesn't show up on any spreadsheet

Inherited technical debt

A bad engineer doesn't just fail to build what they should. They build what they touch badly. Code without tests, architecture that doesn't scale, unnecessary dependencies, abstractions no one understands. When they leave, that code stays. And someone has to deal with it.

I've seen cases where an engineer spent 4 months at a startup and left behind a codebase that the next senior spent 6 weeks rewriting before they could move forward. Those 6 weeks are pure sunk cost -- you're not building new features, you're undoing the work of someone who's already gone.

Team morale damage

This is the least measured and highest-impact cost. When a team member isn't performing, everyone else knows. Before you do, usually. And every week that passes without you doing something about it, your credibility as a leader erodes.

Good engineers don't want to work with bad engineers. If you take too long to act, the risk isn't just losing the underperformer -- it's that the people who are performing start looking elsewhere.

Missed deadlines

You hired that engineer because you needed to deliver something. A critical feature, an integration, an MVP. Every month that passes with someone who can't execute is a month of delay on your product. In a startup, that can mean:

Losing a market window. Your competitor shipped first.
Losing investor confidence. You didn't deliver on the roadmap you presented during the round.
Losing customers. You promised a feature for Q1 and it didn't ship.

Loss of institutional knowledge

When someone leaves -- even someone who wasn't performing well -- they take context with them. Decisions they made, conversations they had with other team members, understanding of the business domain. Some of that context is lost forever. The next engineer starts with an information deficit that takes weeks to close.

The disaster timeline

Let's put numbers to the time:

Months 0-3: Hiring. You post the listing, screen, interview, negotiate, onboard. If everything goes well, 2-3 months. If the market is hot -- and in tech, it is -- it can be 4-6.
Months 3-6: Honeymoon. The new engineer joins. The first few months are ramp-up. It's normal for them not to produce at 100%. You give them the benefit of the doubt.
Months 6-9: The suspicion. You start seeing signals. Code reviews coming back with lots of comments. Tasks running behind. Other engineers starting to complain in private. But you think: "Maybe they need more time."
Months 9-11: The certainty. You know it's not working. But now you have to manage the exit. Difficult conversations, documenting performance, the offboarding process.
Months 11-14: Back to square one. You hire again.

Result: up to 14 months lost. For a startup trying to reach product-market fit, that can be fatal.

Why it happens: the most common mistakes

Bad hires aren't bad luck. They're the result of a broken process. These are the mistakes I see most often:

Hiring with urgency, not with standards

"We need a backend developer yesterday." Sound familiar? The pressure to deliver makes you lower the bar. You accept the candidate who's "fine" instead of waiting for the one who's "excellent." That shortcut always ends up costing more.

Over-relying on the CV

An impressive CV doesn't guarantee anything. I've interviewed candidates with Google and Amazon experience who couldn't solve a basic system design problem. And I've seen engineers from companies you've never heard of who wrote impeccable code. The CV tells you where someone has been. It doesn't tell you how they work.

Skipping a real technical evaluation

A 30-minute conversation isn't a technical evaluation. If you're not doing code reviews of real code, system design exercises, or at least a pair programming session, you're guessing. And guessing on hires that cost EUR60,000-100,000 a year is an absurd risk.

Evaluating the interview, not the output

Some people interview incredibly well and produce mediocre work. And vice versa. If your process selects for interview ability instead of execution ability, you're optimizing for the wrong thing.

How to prevent it: the framework that works

There's no 100% guarantee, but you can drastically reduce the risk:

1. Rigorous technical vetting. Not just algorithms and data structures. Evaluation of real code. How do they structure a project? How do they handle errors? How do they think about testing? Can they explain architecture decisions they made on past projects?

2. Evaluation by engineers, not recruiters. A recruiter can assess soft skills and cultural fit. They can't assess whether someone knows how to design a distributed queue system. Your senior engineers -- or your CTO -- need to be in the process.

3. A real trial period. Not a trial where you watch whether the person "fits in." A period where you assign real work with concrete deliverables and evaluate the quality of the output. 2-4 weeks is usually enough to know if someone actually executes.

4. Technical references, not just professional ones. Don't just call their former manager. Talk to someone who reviewed their code or worked on the same technical team. The questions that matter: "Would you work with this person again? Would you give them a critical project?"

How we solve this at Conectia

All of the above requires time, technical expertise, and a well-defined process. Most early-stage startups don't have all three. They're in a rush, they have a technical founder who's already at capacity, and they don't have a proven hiring process.

That's exactly why we built Conectia. Our vetting process has an 8% acceptance rate. It's not a CV filter -- it's a technical evaluation led by CTOs with production experience. We assess real code, system design ability, and demonstrable experience in startup environments.

If an engineer doesn't work out, we replace them within the first 30 days at no additional cost. Not because we expect it to happen -- our retention rate is 95% -- but because we understand that for a founder, trust in the process matters as much as the result.

The cost of a bad hire isn't a number on a spreadsheet. It's time you don't get back, code you have to rewrite, and team morale that takes months to rebuild. The best investment you can make isn't hiring fast -- it's hiring well.

Tired of hiring processes that don't actually filter? Talk to a CTO -- pre-vetted senior engineers with a 30-day replacement guarantee.