You hired someone three months ago. Their resume was great. They aced the coding challenge. They said all the right things about microservices and distributed systems. Now you're spending two hours every day explaining basic concepts, fixing their broken PRs, and wondering how you got here. That's 10-15 hours per week you could be spending shipping product, instead of being a full-time tutor to someone who should already know this stuff.

The real cost isn't the hours, it's what you're not building

Most CTOs calculate the cost of a bad hire by salary and recruiting fees. That's wrong. The actual damage is your time, your senior engineers' time, and the opportunity cost of what your team could have shipped instead.

A mid-level engineer making $120k costs you about $10k per month. But if you and two senior engineers spend 15 hours per week combined coaching them through work they should handle independently, you're burning roughly $15k per month in lost productivity. Over six months before you finally let them go, that's $90k in pure waste, not counting the features that never launched and the technical debt that piled up.

The brutal part is that you probably knew something was off by week two. You just hoped it would get better.

Why handholding happens in the first place

Bad hires don't announce themselves on day one. They reveal themselves slowly through a pattern of behaviors:

They can talk about system design but can't debug a failing API endpoint without guidance. They know the buzzwords but freeze when asked to make a trade-off decision between SQL and NoSQL for a specific use case. They write code that works in isolation but breaks every integration test.

This happens because traditional hiring methods test the wrong things. Coding challenges measure algorithmic recall, not engineering judgment. Interviews reward people who can articulate patterns, not people who can apply them under real constraints. Resumes show where someone worked, not how they think through ambiguity.

You optimized for "can they answer questions" when you should have optimized for "can they solve problems independently."

The handholding trap has three stages

Stage one: constant questions

Every task requires clarification. They ask about edge cases that should be obvious. They need you to explain the same architectural decision multiple times. You tell yourself they're just ramping up.

Stage two: low-quality output

Their code works but barely. It's not documented. Error handling is an afterthought. They used three libraries when one would do. You spend more time reviewing and fixing their work than it would have taken to do it yourself.

Stage three: team drag

Your senior engineers start avoiding pairing with them. PRs sit in review forever because no one wants to write another round of "please add tests" comments. Velocity drops because you're routing critical work around them instead of through them.

Most engineering leaders wait until stage three to act. By then, you've already lost months.

What reclaiming those hours actually looks like

The answer isn't time management tactics or better onboarding docs. It's hiring people who don't need handholding in the first place.

That requires changing what you evaluate during hiring. Instead of asking candidates to explain dependency injection, watch them implement it. Instead of discussing database optimization theory, give them a slow query and real logs and see if they can actually fix it. Instead of whiteboarding a system design, put them in a production-like environment and watch how they make decisions when things break.

Here's the difference in practice:

The first column hires people who can talk. The second column hires people who can execute.

The recovery plan if you're already stuck

If you're currently spending 15 hours per week on a struggling hire, you have two options.

Option one: structured improvement plan with a deadline

Give them one month. Assign specific, measurable outcomes. "Independently complete three features end-to-end with zero rework" or "debug and fix production issues without escalating to senior engineers." If they hit it, great. If not, cut them loose. No extensions.

Option two: immediate replacement

If you're past the six-month mark and they still can't work independently, the pattern won't change. Start the search now. You'll lose a few weeks of transition, but you'll gain back 15 hours per week immediately after.

The mistake is choosing option three, which is continuing to hope things improve while doing nothing differently. Hope is not a strategy.

What you should do Monday morning

Stop optimizing for interview performance. Start optimizing for day-one readiness. The candidates who can actually do the work in a realistic environment are the same ones who won't need you to hold their hand later.

Your time is the most expensive resource on your team. Spend it building, not babysitting.