What Work to Give Contractors: Sort by How Long the Knowledge Has to Live

Last updated: October 28, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

The contractor who built our fee calculation did everything right. Tests, a handoff document, shipped two days early, gone on the date the contract said. I would hire her again tomorrow.

I would not give her that work again.

Seven months later a threshold in the rules moved, and the change should have taken an afternoon. It took nine days. The calculation carried four rounding decisions, each one there for a reason nobody had written down, and the only person who knew the reasons had left in March. We paid to bring her back for two days. She found all four in about an hour. Nothing was wrong with her work. The mistake was mine. A placement mistake. I had parked knowledge that needed to live for years in a head on a four-month lease, and I had done it because the work looked bounded on paper and nobody in the room asked how long the answer would matter.

Most leaders sort a backlog by skill (“we need someone who knows Kafka”) or by importance (“that one is core, this one is not”). Both miss. Importance is a poor proxy, since plenty of important work finishes and stays finished. Finished is finished. So I ask something plainer now. After this ships, how long does the knowledge behind it have to stay in the building? Months, or years? Pick one. That one answer settles most of the call, and what follows is how to ask it of a whole backlog, line by line. It’s build vs buy, aimed at the work instead of the tools, and I wrote up the five numbers I put on the table for a build-or-buy call if you want the version for software. If you run contract staffing on an engineering team, this is the sorting step that usually gets skipped.

Video chapters

• 0:00 — Intro
• 0:24 — The knowledge-lifespan rule
• 1:07 — Scoring your backlog
• 1:49 — Load-bearing spaghetti
• 2:23 — When contract work should convert
• 3:04 — Quick questions and next step

Read full transcript

Sort engineering work by how long its knowledge has to live in your building. That’s the whole rule. After the work ships, does the knowledge behind it need to stay for months? Or for years? Months, and it can go to a contractor. Years, and it belongs with an employee. Can’t say yet? That’s contract-to-hire. At KORE1, the median contract assignment runs one hundred sixteen days, across one thousand eight hundred eighty-seven assignments. That’s the clock the work has to fit inside.

Engineering executive Kris Drouet learned this the hard way. A contractor built his team’s fee calculation, did everything right, and left on schedule. Seven months later a threshold moved, and a change that should have taken an afternoon took nine days. Nobody had written down why four rounding decisions were there. The work was bounded. The knowledge wasn’t short-lived. Contractors fit a migration with a cutover date, a spike on a new stack, tests and dependency maps around code nobody dares touch, and an integration with a hard go-live date. Core domain logic stays inside. Fees, pricing, ledgers, eligibility rules. So do architecture decisions, engineering standards, and any module only two people truly understand. A new service you expect to run for two years or more, or a role whose scope is still moving, fits contract-to-hire.

A table of work types is a sorting hat. It isn’t a decision. For a real backlog, score every item on four questions, zero to two points each. How long must someone here carry this knowledge? Can someone outside the team check that it’s done? How many decisions behind it are written down nowhere? And when would you find out it was wrong? Add it up. Zero to two points is contractor work. Three to five is the middle band. Six to eight is employee work. And a two on the first question rules out plain contract work. The fourth question is the one people skip. A mistake you’d catch inside the sprint is cheap to hand off. One that surfaces after the engineer has left belongs to whoever is still around. And slice before you sort. Scoring a whole epic is nearly useless, because an epic is a bag of items with different answers.

What about work buried in a tangle, where every change breaks something else? Nothing scores higher. And the tempting move is wrong. A contractor handed a feature inside the tangle spends the first six weeks learning it, ships a change whose side effects show up after they’ve rolled off, and the one person who finally understood the module leaves with that understanding. Point them at the edges instead. Characterization tests that pin down what the code does today. A dependency map. And one seam, a single place where old and new can meet. Each one is bounded, checkable, and written down. And each makes the next item in the tangle cheaper to score. Contractors draw the map. Employees pick the route.

Rarely, for the low scores. If the knowledge expires with the work, converting the person is a headcount decision wearing a work decision’s coat. The middle band is where conversion earns its keep. Write the term to reach the conversion point on day one, and pair the person with a named employee from the start. A contractor can convert to your team at no fee after one thousand forty hours. That’s six months at forty hours a week. Direct hire is a different path. KORE1’s fee is twenty percent of base salary with a sixty-day guarantee, so a base of a hundred thousand dollars carries a twenty thousand dollar fee. Of KORE1’s contract-to-hire placements, thirty-seven and a half percent convert to permanent employment, across five hundred fifty-two placements. More than six in ten end without converting, and that isn’t failure.

You might be wondering about a role you can’t scope yet. Contract-to-hire. If you can’t say how long the knowledge needs to live, you can’t say whether the seat is permanent. And contractor versus full time? On a contract through KORE1, the engineer is KORE1’s employee, so we carry payroll, benefits, and compliance. A full-time hire goes on your payroll with no end date. Ready to hire for the sorted work? Bring a staffing firm four things. The work items, the skills, your start date, and how long you need people. Once there’s an offer, the median KORE1 contract placement starts in three days. So the first column of any backlog is a number. Months, or years. Bring your scored list to KORE1 and start with the items that score zero to two.

What Is the Knowledge-Lifespan Rule?

The knowledge-lifespan rule sorts each piece of engineering work by how long the knowledge behind it must stay inside the company after the work ships. Short-lived knowledge suits contractors. Knowledge that has to last years belongs with employees. Work where you can’t yet say belongs in contract-to-hire.

Start with the sort. Everything after it is detail.

Why lifespan, and not “core versus not core”? Because my fee calculation was not the crown jewels. It was bounded, well specified, and testable, which is exactly why it looked like contractor work to me. Bounded isn’t the same as short-lived. Specified isn’t the same as simple. Two different things.

Knowledge is also more fragile than most of us admit. In a 2016 study, Guilherme Avelino and his colleagues estimated the truck factor of 133 popular GitHub projects, meaning the number of developers who have to leave before a project is incapacitated, and found that 65% of them had a truck factor of two or less. Open source isn’t your codebase, and the study says nothing about staffing models, but if projects with enormous contributor pools sit that close to the edge, you should assume your internal service does too. Then ask which two people hold it. Name them. If one of them is on a contract that ends in March, you have found your risk.

Devin Hornick, a KORE1 partner, described the flip side of contract flexibility on a recent internal KORE1 call. “The benefit of hiring full time is quite the opposite. It’s really not super flexible, but you have stability… legacy knowledge.” Legacy knowledge is my entire middle column. You can’t rent it.

Show Me the Data: How Do You Score a Backlog?

A table of work types is a sorting hat. It isn’t a decision. For a real backlog I score every item on four questions, zero to two points each, and I do it in a room with the person who would inherit the work, because they will answer honestly about how many decisions live only in a chat thread. Be honest.

Add it up. Zero to two points is contractor work. Three to five is the middle band, where I want contract-to-hire or a contractor with a named employee pairing and a term long enough to convert, because that is the band where you genuinely can’t tell yet whether the seat is permanent. Six to eight is employee work. One override sits on top of the arithmetic. A two on the first question disqualifies an item from plain contract work no matter what the total says.

The fourth question is the one people skip, and it’s the one that cost me nine days. A mistake you’d catch inside the sprint is cheap to hand off. A mistake that surfaces eight months later, in a quarter-end run, when the engineer is two jobs down the road and the notes sit in a folder nobody has opened, belongs to whoever is still around. It’s cheap insurance.

Here is the scoring on a made-up backlog. An illustration, not a measurement.

Slice before you sort. Scoring an epic is nearly useless, because an epic is a bag of items with different answers. On the event-platform migration I led, where we replaced point-to-point integrations with a Kafka pub/sub backbone, the original ticket said “migrate integrations” and would have scored a six. So I cut it. Topic design and schema rules stayed with employees, because the knowledge behind them had to outlive everyone on the project. Each integration cutover became its own ticket with a number attached to it, which was the old link off, the consumers reading the new topic, and lag flat for a week. Those scored ones and twos, and contract engineers took them. Downstream processing latency fell 45%.

There’s a money side to the first question too. Say a knowledge-heavy item needs six weeks of learning before the first useful merge. KORE1-placed software engineers billed $91 to $120 an hour, median $105 (n=16, primarily Southern California, KORE1 Contract Rate Index 2026-Q4), so six weeks at 40 hours is 240 hours and $25,200 spent on learning before anyone ships what you hired for. The median assignment is 116 days. Six weeks is 42 of them, more than a third of the whole engagement, gone before the work starts. Treat that as an illustration, since your ramp may be shorter. It still explains why long-lived knowledge loses money on a short contract. Learning is not shipping.

What About Work Buried in Load-Bearing Spaghetti?

Nothing scores higher. “Every time we touch something, something else breaks” is a four-way two, which makes eight, and the score is the whole message. I described how a codebase gets that way in what load-bearing spaghetti does to a team, and the part that matters here is the staffing consequence. Fear, mostly. Nobody dares touch it because nobody can see what holds what up.

So the tempting move is wrong. Handing a contractor the feature that lives inside the tangle means they spend their first six weeks learning it, they ship a change whose side effects show up in production after they have rolled off, and the one person who finally understood the module leaves with that understanding. You paid for the lesson and didn’t keep it.

The right move is to point contractors at the tangle’s edges and have them produce knowledge you can keep. Three things work.

• Characterization tests, which pin down what the code does today, right or wrong. They check themselves. A reviewer outside the team can run them.
• A dependency map. Who calls what, what reads which table, which job runs at 2 a.m. and why.
• One seam, a single place where old and new can meet, so the next change can go through a door instead of through the wall.

Bounded. Checkable. Written down. Each one scores a one or a two. And each makes the next item in the tangle cheaper to score. A seven becomes a four. Eventually a four becomes a two, and at that point the work is contractor-shaped for the first time in ten years. Different job entirely.

Ikujiro Nonaka’s Harvard Business Review article “The Knowledge-Creating Company” draws the line that matters here, between explicit knowledge, which can be written down, and tacit knowledge, which lives in people. Contractors are good at producing the first kind. The second stays with whoever lives with the system.

Martin Fowler writes that the technical debt metaphor, coined by Ward Cunningham, frames the extra effort to add features as interest. Undocumented knowledge accrues interest the same way, and you pay it in the one place a contract can’t reach, which is after the engineer is gone. The rule I use is blunt. Contractors draw the map. Employees pick the route.

When Should Contract Work Convert?

Rarely. Not for the zero-to-two items, anyway. If the knowledge expires with the work, converting the person is a headcount decision wearing a work decision’s coat. The migration ended. Let it end.

The three-to-five band is where conversion earns its keep, and where most teams buy the wrong thing. A 90-day contract for a four-point item gets you the ramp and the exit before the knowledge ever pays off, and you spend the whole engagement paying down a learning curve you will never get to cash in. Worst of both. The arithmetic is simple. A contractor can convert to your team at no fee after 1,040 hours, which is six months at 40 hours a week, and at the $105 median that is $109,200 of billed time. Direct hire runs 20% of base salary with a 60-day guarantee, so a $100,000 base carries a $20,000 fee. Devin made a related point on that internal call, that once you spread a direct hire fee across the hours there is really no savings in one path over the other. What differs is what you learn before you commit.

So for a middle-band item, write the term to reach 1,040 hours on day one, and give the person a named employee to work beside. Then treat the six months as the knowledge-transfer window it is, not as an audition. Conversion is common without being the default. Of KORE1’s contract-to-hire placements, 37.5% convert to permanent employment (n=552). More than six in ten end without a conversion, and that isn’t failure. Plenty of work finishes. Sometimes the work finished. Sometimes the manager learned what they needed to learn. The contract-to-hire guide walks through how to set that up.

Questions Engineering Leaders Ask Before They Hand Off the Backlog

Which engineering work goes to contractors, and which stays with employees?

Give contractors work whose knowledge expires within months and whose finish line you can write down. Keep work whose knowledge has to last years with employees. Put the unsure middle on contract-to-hire.

Migrations, spikes, test coverage, and integrations with a hard go-live date land on the contractor side. Core domain logic, architecture, and anything only two people understand stay inside. Score each item on the four questions above and the lane mostly picks itself.

Contractor or full-time hire, when I can’t scope the role yet?

Short answer, contract-to-hire. If you can’t say how long the knowledge needs to live, you can’t yet say whether the seat is permanent, and contract-to-hire lets you find out while the work gets done.

Write the term to reach 1,040 hours so conversion is a real option, and pair the person with an employee from week one. If the work turns out to be bounded after all, the engagement simply ends on its date. For the cost and engagement comparison, see contract versus full-time IT hiring.

W2 contract vs full time, what actually changes for me?

On a W2 contract through KORE1, the engineer is KORE1’s employee, not yours, and we carry the payroll, benefits, and compliance. A full-time hire goes on your payroll with no end date.

The practical difference is the clock. A contract has a term, a bill rate, and a built-in decision point, while a full-time hire is a standing commitment. Both can work inside your sprints. Worker classification is a legal question, so have counsel check it for the state where the person works.

What does it cost to convert a contractor to full time?

$0 from KORE1 once the contractor passes 1,040 hours, which is six months at 40 hours a week. Before that point, confirm the terms with your recruiter in writing.

Direct hire is a separate path with its own price. KORE1’s fee there is 20% of base salary with a 60-day guarantee, so a $100,000 base carries a $20,000 fee. People blur the two numbers when they budget. Keep them apart, because the conversion path is the one where you have already watched the engineer work.

How do I hire contractors for the work once it’s sorted?

Bring a staffing firm four things. The work items, the skills, your start date, and how long you need people. A recruiter can work from those and come back with candidates.

Scored items help here. A zero-to-two item has a written finish line, which is what a recruiter needs to screen against, and which is why those searches tend to fill faster than open-ended ones. Once an offer is made, the median KORE1 contract placement starts in 3 days (n=1,997). Read more on how contract staffing works, or talk to a KORE1 recruiter about the bounded work.

Sort the Backlog Before You Staff It

I’ve told the fee calculation story a few times now. People assume the lesson is don’t hire contractors for important work, but she was excellent, and the actual lesson is that I never asked how long the answer needed to stay in the building, a question that takes four minutes. That’s the whole trick.

These days the first column of any backlog I look at is a number. Months or years. Everything else follows from it.

If you want to argue about where one of your items scores, or tell me which question you’d add, connect with me on LinkedIn or DM me there. And if the bounded work is ready to go, start the search with KORE1’s engineering recruiters.

Related reading: Contract Engineering Teams in Regulated Codebases: An Operating Model for VPs, Knowledge Transfer and Exit Planning for Contractors, and Scaling an Engineering Team With Contractors.