Last updated: October 20, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
A mixed team in a regulated codebase works when contractors get the same written answers employees get, covering who owns each decision, who holds which access, who carries the pager, what done means, and how knowledge stays. KORE1’s engagement data puts the median contract assignment at 116 days (n=1,887), so the exit plan starts on day one.
The auditor’s request fit in one line. Everyone who had write access to the loan-origination repository at any point in the quarter, please. Simple request. Hard answer.
We came back with thirty-one names. Eleven were gone, either out of the company or finished with an engagement, and four of those eleven could still log in. All four were contractors. Their assignments had ended within the previous two months. Nothing bad had happened through any of those accounts. The auditor was kind about it. The finding still went into the report as an exception. We had been lucky. Everyone in the room knew the difference.
What stuck with me was the postmortem. I asked who was supposed to switch those four accounts off and got three honest answers. Nobody was lying. The staffing partner assumed our IT desk handled it. IT assumed the engineering manager filed a ticket. The engineering manager assumed contractors dropped out of the directory when the contract ended. Each assumption was reasonable. None of them was written down, so all three were wrong.
That is a clarity problem wearing a staffing costume. I keep running into it on mixed teams in regulated shops. When you run contract staffing engagements alongside employees, a handful of questions get answered by osmosis for the employees and not at all for everyone else. This piece is the operating model I use to answer them in writing. It builds on the Clarity Stack and on what I wrote about running contractors in a regulated codebase, and it is the hub for the narrower pieces on culture, access, and ratios that I link along the way.
Why Do Mixed Teams Stall in Regulated Shops?
A mixed team stalls when the three things every team needs in writing, what done means, what comes first, and who decides, live in employees’ heads instead of somewhere a newcomer can read them. Contractors can’t absorb unwritten rules on a short clock, and auditors can’t test them at all.
Take the Clarity Stack one layer at a time. Done comes first. It always does. An employee has spent two years learning what a finished ticket looks like here, through review comments, rejected pull requests, and one memorable incident, while a contractor gets a link to a definition-of-done page last edited in 2023. Priorities are the second layer, and in most shops they live in a leadership sync and three Slack threads that employees pick up simply by being around and that a contractor, who bills by the hour and sits outside half those channels, will never see. The third is the hallway decision. A contractor is not in the hallway. Often can’t be, by contract or by badge. The math is unkind.
Now add a clock. KORE1 counted a median contract assignment of 116 days across 1,887 placements, a little over sixteen weeks. That’s the whole window. Offer-to-start has a median of 3 days (n=1,997), so the contractor is at a keyboard before most teams have finished the onboarding doc. An employee gets a year to absorb your unwritten rules. A contractor gets one quarter, minus ramp.
Regulated shops add a fourth reader. The auditor. Whatever is unwritten for the contractor is also unprovable to the auditor, and an unprovable control reads as a missing control. Writing things down pays twice. Once for the contractor, and once more at audit time.
The instinct is a bigger onboarding deck. It doesn’t help. A deck is a snapshot and the work keeps moving. What the team needs is a short list of questions with standing written answers, kept where the work happens.
- Who decides what.
- Who can touch which system, and until when.
- Who answers the page at two in the morning?
- What “done” means, in terms an auditor could check.
- What happens to the knowledge on the last day.
The rest of this piece takes them in that order.
Who Owns Which Decisions When Part of the Team Is Contract?
I covered the philosophy in integrating contract engineers without a two-tier culture. Assign decisions by the work, not the badge, and send one-way doors to someone whose time on the team outlasts the consequences. A regulated codebase adds a second sorting question on top of that one, which is whether the decision is a control. Architecture and implementation calls follow the grid in the decision ownership diagram. Control decisions, the ones an auditor will ask about, need a named owner who can be questioned.
| Kind of decision | Who decides | The contractor’s seat | Where it is written |
|---|---|---|---|
| Implementation inside a service they work in daily | The engineer doing the work | Decides | The pull request |
| A data model, a public API field, a vendor commitment | Someone who will still be here when the consequences land | Writes the decision record and argues the tradeoffs, does not sign | The architecture decision record |
| Approving a production change | A reviewer who did not write it, picked by role | Reviews other people’s changes, never their own | The change ticket |
| Changing priority or scope mid-sprint | The named product owner | Told in writing, can object in writing | The priority list |
| Accepting a risk or an audit exception | A named employee who owns the control | Consulted, never the signature | The exception register |
The failure I see most is the silent veto. I once watched a contract engineer wait nine days for a yes that was hers to give. Nobody had told her it was hers, and the employees around her assumed somebody senior was weighing in. Nobody was. The decision sat in the gap between two assumptions, and that gap cost a sprint. A whole one.
If a decision has a row in the table, it has an owner, and the owner’s name is in a document the contractor can open on day one, which sounds obvious until you try it and discover that half your decisions have no owner at all, only a habit nobody remembers starting. If it doesn’t have a row yet, add one the first time somebody asks “wait, who decides this?” That question is a free audit of your documentation.
Who Holds Access, and How Is It Granted and Revoked?
Access is where regulated shops get written up, and contractors are where the write-up usually starts. The reason is simple. Their access carries a built-in expiry date that nobody put into a system.
The frameworks agree on the shape of the fix. The AICPA’s Trust Services Criteria that SOC 2 reports test against cover logical access in their CC6 series, including how access is authorized and how it is removed when it is no longer needed. NIST SP 800-53 Rev. 5 lists least privilege and separation of duties as separate controls, AC-6 and AC-5, because one doesn’t imply the other. And if you lend or broker mortgages, the FTC says its Safeguards Rule covers you, and 16 CFR 314.4(c)(1) requires you to implement and periodically review access controls, limiting users to the customer information they need for their duties. A contractor access policy that cites CC6 and the Safeguards Rule puts both into clauses a hiring manager can follow.
None of those texts says “unless they are contractors.” Not one word.
The fix we landed on is almost embarrassingly simple. The end date goes into the access request. Not into the contract, where IT will never see it. Into the ticket that grants the access, as a required field, and the account is created with an expiration set to that date. Extending it takes a new ticket from the engineering manager. Easy. Revoking it takes nothing. It just happens. That flips the default from “access stays until someone remembers” to “access ends unless someone says otherwise.” That is the whole mechanism.
| Stage | What has to be true | Who owns it | What the auditor asks to see |
|---|---|---|---|
| Request | Names the system, the role, and the end date | Hiring manager | The ticket |
| Approval | Given by the system’s owner, never by the requester | System owner | The approval, with a timestamp |
| Provisioning | Done through a role-based group, no one-off grants | Platform or IT | A group membership export |
| Review | Quarterly, same list and same standard as employees | Engineering manager | The signed review |
| Removal | Automatic on the end date, confirmed the same day for early exits | IT, with the staffing partner telling them | A dated disable log |
One wrinkle. The staffing firm is the employer of record, so it runs payroll and the HR side of offboarding. It can’t turn off your accounts, and it shouldn’t be able to. Ask your partner to tell you in writing the day an engagement ends early, and wire that notice into your offboarding runbook as a trigger, because early exits are where the stale accounts come from, since nobody schedules a surprise resignation or a sudden budget cut and the calendar reminder never fires. KORE1 keeps a contractor access and offboarding checklist that walks the steps in order. I’ve also written about what SOC 2 changes day to day and about making audit evidence a byproduct of delivery, and both apply here without edits.
Who Carries the Pager?
Both. In order of readiness. The longer answer starts with arithmetic.
Google’s SRE book says the minimum for a healthy single-site on-call rotation is eight engineers, or six per site for a dual-site team. It caps on-call at 25 percent of an engineer’s time, and it sets a ceiling of two incidents per twelve-hour on-call shift. Most mid-market teams I have worked with sit well under that floor. Count yours. A team of five can’t staff a healthy rotation, so the three people who know the system best end up carrying it, and those three are the first to quit.
Adding a contractor helps only when they are ready, and ready should be a checklist, not a feeling. Access provisioned and tested. Not before. Runbooks they have actually run, not read. Two shadow shifts. A named escalation to an employee who owns the one-way calls. Rolling back, restarting, and failing over are two-way doors, so a ramped contractor can take them, and I would argue they should, because the alternative is an employee getting paged at 2 a.m. for a restart the contractor could have done half asleep. Declaring a security incident, notifying a customer or a regulator, or changing a data store goes to an employee, because those consequences outlive the contract.
Read the agreement before you add anyone to the rotation. After-hours pay and overtime rules for hourly workers are not details to discover after the first midnight page. I wrote more about what the rotation says about your design in your on-call rotation is a design signal, and it is worth rereading before you decide who joins it.
What Does Done Mean for a Contractor’s Ticket?
In a regulated codebase, a merged pull request is half a ticket. The other half is evidence.
Here is the version I put in the ticket template, where it can’t be skipped and where employees follow it too, which is how you avoid building a second tier by accident.
- Merged and deployed, with the change ticket linked in the pull request rather than found later by someone with a search bar.
- Reviewed by a person who did not write it.
- Does the failure path have a test? In my experience contractors write the happy path well and the rollback path never, because nobody asked.
- Runbook updated, if what the pager does changed.
- Any access or configuration change ticketed on its own.
An hourly contractor has no reason to guess what done means, and you have every reason to say it. Ambiguity costs hours first and rework second, and in a regulated shop it costs a third thing, an audit sample nobody can explain, which is the expensive one. Show me the data on your last ten closed tickets. How many had the change record attached at close? Be honest. If it’s fewer than all of them, your definition of done is a hope. It isn’t a rule yet.
How Does Knowledge Stay When Contractors Roll Off?
It stays if you plan for the exit on the day they start. Everything else is hoping.
The numbers argue for it. KORE1’s median contract assignment is 116 days (n=1,887). Of KORE1’s contract-to-hire placements, 37.5 percent convert to permanent employment (n=552), and any contractor can convert at no fee after 1,040 hours. At 40 hours a week, 1,040 hours takes 26 weeks, about 182 days. So on a standard full-time schedule, more than half of assignments end before conversion is even on the table. If you might want to keep someone, that is a day-one decision about contract length, and contract-to-hire staffing exists for exactly that case. If you won’t, the knowledge needs a way out of their head before they go. Write it down. For the fuller plan, including who owns each handoff row, see the knowledge transfer plan for contractors.
Four habits do the work. None are complicated.
Name a pair in week one. One employee, shadowing, with the pairing written into both of their goals so that it survives a busy sprint, the quarter-end crunch, and the inevitable week when the employee’s own manager reassigns them to a fire. A vague hope about knowledge transfer is not a plan, and it is the version I see most. Hope is not a handoff.
Write the handoff weekly, not at the end. Decision records, runbook changes, and a running file of things the contractor wishes they had known on day one. By the last week there is nothing left to reconstruct.
Run the last-week rule. No new feature work in the final five working days. Spend them on a recorded walkthrough, and have an employee ship a real change in the contractor’s area while the contractor watches and answers questions.
Then audit the exit. Access removed, tickets reassigned, and the docs read by someone who has never touched the system, because that person finds the gaps the author can’t see. The author knows too much.
The sharpest version of this I have seen was a migration team that made the departing contractor the reviewer on their replacement’s first pull request. Not the author. The reviewer. It surfaced six undocumented assumptions in two days.
Build a contract engineering team that fits this model.
If you are staffing a team that has to live inside the answers above, tell KORE1 the roles, the team size, the compliance regime, your start date, and how long you need them at contract engineering teams. If you are filling a single seat on a regulated codebase, start with regulated industry software engineers.
Which Work Should Go to Contractors at All?
This is build vs buy applied to people, and the same rules hold. Buy what has a defined end state, a known shape, and no long tail of context. Build, meaning hire and keep, what accumulates context, what carries the audit controls, and what only works if the person is still here in two years.
Contractors are strong on migrations, integrations with a clear cutover, a platform build with a handoff date, and spikes where you need a skill for a quarter and not a career. They are weak on anything where the first six months are spent learning the domain and the payoff comes in year two. Devin Hornick, a KORE1 partner, puts the appeal this way. “The contract allows that company… you can get them quick… flexible… to scale up, to scale down as needed.” I’d add one condition. That flexibility is only real if you can write the done condition. If you can’t, the work isn’t contractor work yet.
For the ratios, pods, and ramp plans, see scaling an engineering team with contractors. For the money, KORE1 publishes what employers pay. Here is one cut of the KORE1 Contract Rate Index for software engineers.
| Level | Source and market | n | Bill rate p25 to p75 | Median | 3 months | 6 months |
|---|---|---|---|---|---|---|
| All levels | KORE1 observed, placements primarily in Southern California | 16 | $91 to $120 | $105 | $54,600 | $109,200 |
| Senior | KORE1 observed, placements primarily in Southern California | 7 | $91 to $138 | $120 | $62,400 | $124,800 |
Those are what employers pay KORE1 per hour, and the engagement costs assume 40 hours a week. The cells come from W2 contract placements KORE1 started between 2023 and 2026, and the sample for the senior row is small, so treat the range as a signal and not a quote. The KORE1 Contract Rate Index for 2026-Q4 took effect October 16, 2026, and the contract rate methodology explains how every cell is built.
How KORE1 Sources, Vets, and Places the Engineers This Model Assumes
This section is written by KORE1, not by Kris. Kris wrote the operating model above, and KORE1 supplies the engineers who work inside it.
The model assumes engineers who arrive ready to work inside a change-control boundary. Our regulated-industry screen is built around that. It runs about forty-five minutes. First comes a Friday production bug that tests whether the candidate asks who can approve an emergency change before they ask about the bug, then a code review with problems planted in it, and finally an incident story. We grade what candidates catch without being prompted.
Speed matters too, because the clock on a contract assignment starts when the contractor does. KORE1’s average time-to-hire on IT roles is 17 days, the median offer-to-start on contract placements is 3 days (n=1,997), and twelve-month retention across placements is 92 percent.
When the need is a team and not a seat, we deploy pre-matched benches. An architect, a tech lead, and senior engineers who have shipped together before, led by a named tech lead who owns the calendar and the standup, in 14 to 21 days. Contractors are W-2 employees of KORE1, so payroll and the HR side of the engagement stay with us, and they can convert to your payroll at no fee after 1,040 hours.
Start with our pre-matched contract benches for a team, or regulated-industry engineering placements for a single seat. Figures are as of October 2026, and we review this page every six months and as new guides in this series publish.
Questions VPs Ask Before the First Contractor Starts
How Should a VP of Engineering Run a Team That Is Part Contractors in a Regulated Company?
Write down the five answers employees absorb by osmosis (decisions, access, on-call, done, and handoff), apply them identically to both groups, and keep only the differences tied to the employment relationship.
The split is simple. Pay, benefits, formal reviews, and the employer of record belong to the staffing firm. Everything about how the work gets done belongs to you, and it should read the same for everyone. If you want a test, ask a new engineer after a month which colleagues are contractors. If they have to look it up, the model is working.
Can a Contractor Hold Production Access in a SOC 2 Environment?
Yes, if the access is role-based, approved by the system owner, set to expire on the engagement’s end date, and reviewed on the same schedule as employee access.
The auditor’s question is whether the control worked for everyone who had access, not what their employment status was. The four accounts in my opening story were an exception because nobody owned the removal, not because the people were contractors. Put the end date in the request and the problem mostly solves itself. That’s the fix.
So How Long Do Contract Engineers Actually Stay?
116 days is the median across 1,887 KORE1 contract assignments, a little over sixteen weeks.
Plan for that. Not for the year in the proposal. Contract-to-hire placements convert to permanent employment 37.5 percent of the time (n=552), and conversion is no-fee after 1,040 hours, which at a full-time schedule is about 182 days. A single assignment tells you little. Your own roll-off history, pulled from the last two years of access tickets, tells you a lot.
Is It Fair to Put a Contractor on the On-Call Rotation?
Readiness is a better test than fairness, and it means provisioned access, runbooks they have run, two shadow shifts, and a named employee for escalation.
The honest alternative is that your employees carry every page forever and burn out, which is its own kind of unfair. Keep the one-way calls with employees, check how your agreement treats after-hours work, and let ramped contractors take the rollbacks and restarts. If your rotation is smaller than six or eight people, adding a ready contractor is probably the kindest thing you can do for the team. Really.
Which Engineering Work Should Stay With Employees?
Anything that accumulates context over years, owns an audit control, or can’t be handed off with a written done condition.
Core domain models, the control owners for your SOC 2 or lending audit, and the systems nobody else can explain all fit that description. Contractors are best on bounded work, like a migration, an integration with a hard cutover, or a platform build with a handoff date. The test is simple. Write the done condition. If you can’t, wait.
Start With One Page
If you do one thing this week, take the five questions from the top of this piece and write one page that answers them for your team. Decisions, access, the pager, done, the last day. Put it where the work happens and name an owner for each answer. Then hand it to the next contractor on day one and watch where they ask questions, because those are your gaps. Worth the hour.
The four accounts from the opening were closed within the hour. The end date went into the access request that same week, and the next quarter’s list came back with no exceptions. Same people. Same partner. Same repository. One written answer.
If you want to argue with any of this, or tell me what your auditor made you change, connect with me on LinkedIn or DM me there. And if the gap turns out to be people who can work inside this model from week one, talk to a KORE1 recruiter.
Related reading: The Hallway-Decision Problem: Why Engineering Priorities Have to Live in Writing, Contractor Onboarding Checklist, and The Incident Review That Changes Behavior.
