Contract-to-hire vs. permanent hiring: When each model makes sense.

When a permanent hire is worth the commitment.

My test is simple. If you can't say with confidence that you'll want this work done by this person two years from now, you're probably looking at a contract.

That bar is higher than it seems. Median tenure for workers ages 25 to 34 is 3 years. Setting a two-year horizon asks the work to hold someone for most of the time they’re likely to stay with an employer. What makes the test useful is that it forces you to examine the work itself: whether the function or project still exists in two years, and whether it changes enough over that span to keep someone interested in staying.

The threshold sits that high because the exit costs are lopsided. Ending a contract means reaching an end date. Ending a permanent hire means performance management, severance exposure, COBRA, unemployment claims, and then paying to recruit a replacement. The employer carries all of it, and none of it shows up in the salary figure that got the requisition approved in the first place.

When a role clears that test, permanent hiring is the right model. From there the difficulty moves to execution, because a direct placement search gets lost more often in scoping and speed than in sourcing.

Which roles suit contract-to-hire, and which need permanent headcount.

Some functions fail the two-year test structurally. The work has an end state built into it, and hiring permanently produces turnover you could have predicted at the scoping stage.

The clearest case is a role whose purpose is to make itself unnecessary. A DevOps engineer arrives when deployments break, pipelines are manual, and systems go down at night. Eighteen months later deployments are clean, the pipeline runs itself, and nothing goes down. I watch those engineers leave at almost exactly that point. Nothing went wrong. They finished the interesting work, and no one had lined up what came next.

A few patterns hold across most of my clients:

• Security belongs on permanent headcount. A security team has to learn your architecture, your threat model, and your regulatory obligations, and that knowledge compounds every year someone stays. Institutional context is most of the job.
  
  
• Migrations and platform builds are contract work. A cloud migration has a defined end state. When a client tells me they want to staff one with permanent engineers, I ask what those people are doing the month after it finishes. Usually nobody has worked that out yet. Staff it with contractors, then decide at the end whether to convert a couple who understand the new environment best.
  
  
• Infrastructure and QA depend on what's ahead of them. A two-year build justifies permanent hires. Stabilization work with a foreseeable finish line doesn't, and treating it as permanent is how you end up with bored engineers auditing their own automation.

But the right model for a role can change as the work changes. A role that warranted a contractor during a migration can warrant permanent headcount a year later, and the reverse happens just as often. Before you open a requisition, run the two-year test against the work sitting in front of that role now, not the work that justified it when you first scoped it.

Why contract-to-hire conversions succeed or fail.

The outcome is usually determined in the first conversation with the hiring leader, before anyone looks at a resume. A client who tells me that this is a real permanent need with a slow-moving requisition already knows they'll want the work done for years. A client who tells me not to call it a contract-to-hire, that there's budget and work but no certainty past that, is saying something different. Both are legitimate, but the distinction matters enormously to the person being asked to take the job.

Candidates sometimes read a contract offer as a lesser opportunity, but in most large organizations it reflects how procurement runs rather than how the company values the role. Saying that plainly is part of my job. What I won't do is let someone believe a permanent role is waiting when the hiring leader never said so. Trust is thin enough already, and an agency that spends it to close one placement costs its client the next five.

Once the contract starts, the failures I see have almost nothing to do with capability. The top reason new hires leave early, regardless of contract type, is mismatched expectations, followed by lack of connection. A manager tells me a contractor isn't taking initiative. I ask whether they've said so directly, and the answer is usually “not really.” In one case a contractor had spent weeks waiting to hear from a colleague who'd been reassigned without anyone mentioning it. Thirty minutes of direct conversation early on is the cheapest retention tool in the arrangement, and it's the one most often skipped.

Choosing the model before you open the requisition.

The decision comes down to what you know about the work: how long it runs, whether it has an end state, and whether it changes enough to hold someone for two years. Most teams answer that once, at the beginning, and never revisit it as the roadmap moves.

Kelly has spent 80 years matching hiring models to business needs, across contract, contract-to-hire, and direct placement. If you're planning a build, a migration, or a team expansion and want a second opinion on how to staff it, my team is glad to talk it through.