Contractor Code Review Without Becoming the Bottleneck

Last updated: October 24, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Four days. That’s how long the pull request had been open.

It was a contractor’s. A clean change to a retry path, tests included, the kind of diff I could have approved in six minutes. It sat there because I had configured the repo so that nothing merged on that service without my sign-off. I did it on purpose, after one rushed merge cost a team a weekend, and at the time it felt like the responsible thing to do. Reasonable, I thought. Meanwhile the engineer who wrote it, billing by the hour, had quietly started the next ticket on top of the unmerged first one, which is how you end up with stacked branches, a painful rebase, and a standup where three people say “waiting on review” in the same flat voice. You know the voice.

Nobody was slow in that story except me. Not the contractor. Not the code.

I’ve written before about what happens when the leader becomes the gate. Contractors sharpen the problem in one specific way. You are paying for their hours, they have a start date and an end date, and a stalled pull request is a meter running with nothing to show for it. If you run contract staffing on an engineering team, review policy is where the money leaks first, and it leaks quietly because every individual delay looks like care.

So how do you review contractor code without becoming the thing everyone waits on? Hold the bar steady. Then change who has to say yes, and when.

Same Bar, Different Trust Ramp

A trust ramp is a fixed schedule that widens what a new contractor can merge alone as their record in your codebase builds. The review standard is identical for everyone. Only who approves, and which pull requests the author may merge alone, changes, on dates you wrote down rather than a feeling.

Why not go easy on contractors? Because a lighter bar ships worse code, and a heavier one tells a good engineer you don’t trust them before they’ve written a line. You lose either way.

There’s a second reason I won’t let anyone skip review to save time. Alberto Bacchelli and Christian Bird surveyed 165 managers and 873 programmers at Microsoft, and they found that although people say they review code to catch defects, reviews are less about defects than expected. What reviews delivered instead was knowledge transfer, team awareness, and alternative solutions to the problem. For a contractor, that second list is the entire ramp. A review is the cheapest way a new engineer learns how your system really works, so cutting reviews for contractors doesn’t save time. It just moves the learning to production. Expensive teacher.

Trust, here, isn’t a verdict on a person. It’s a record. About a codebase. An employee who joined last week gets the same ramp, and the contractor’s version only feels different because it has to run on a shorter clock, since the engagement does. It’s the same principle behind integrating contract engineers without a two-tier culture, where review rights follow knowledge of the code and never the badge.

Here is the schedule I’d hand a team on a Monday.

Only the first row has a calendar. The last two never expire. That’s deliberate.

What Needs an Employee Owner?

Four things get an employee on the approval line every time, from day one through the last day of the engagement. Anything that moves money. Anything that touches personal data. Anything that can take production down. Anything that changes who is allowed to do what. In code, that means payment and billing logic, PII handling, authentication and authorization, schema migrations, infrastructure and deploy configuration, and secrets.

This isn’t suspicion. It’s durability. The person who approves a change to the ledger should be someone who will still be around when the quarterly reconciliation finds out what that change did, and I apply that rule to a permanent engineer who has just given notice exactly as I apply it to a contractor with ten weeks left.

A contractor can absolutely write that change, and often they should, because they hold the most context on the thing they were hired to fix and have usually spent their first month learning exactly how it breaks. The line is who signs.

Make GitHub Enforce It

A policy that depends on your memory is a policy that fails during your vacation. Put it in the repo. GitHub’s CODEOWNERS file maps paths to the people or teams responsible for them, and it lives in the .github folder, the repository root, or docs. Mine looks something like this.

# .github/CODEOWNERS
/services/payments/    @your-org/payments-owners
/db/migrations/        @your-org/data-owners
/infra/production/     @your-org/platform-owners
/.github/CODEOWNERS    @your-org/eng-leads

The last line is the one people skip. GitHub’s own documentation recommends giving the CODEOWNERS file an owner, otherwise anyone can quietly edit the rules. Then switch on the settings that make owners mandatory, which GitHub lays out under protected branches.

• Require review from Code Owners, so a contractor’s approval on a payments change can’t satisfy the gate.
• Dismiss stale approvals when new commits arrive. Otherwise a reviewed pull request can change after the green check and nobody looks again.
• Require approval of the most recent reviewable push, which means the last person to push can’t be the one who approves.
• Required status checks. Tests and linters should pass before a human spends any attention at all.

One more, and it’s the setting everybody forgets. Keep contractors off the repo admin role, and check that your rules apply to administrators too. A rule an admin can step around is a suggestion. Auditors notice.

Access is its own conversation, and the contractor access and offboarding checklist covers revoking it on the way out.

How Do You Stop Review Queues From Eating the Hours You Bought?

Promise a first response inside one business day, keep pull requests small, and let automated checks do the nagging. That’s most of it. The rest is arithmetic about what waiting costs.

Google’s engineering practices guide says that one business day is the maximum time it should take to respond to a code review request. Respond, not finish. Notice how generous that is for a company that large, and then think about how many contractor pull requests you’ve watched sit untouched while the author quietly started something else on top of the unmerged branch. Three days is common. Five isn’t rare. In my experience those weren’t hard to review. They were nobody’s job.

Here is what waiting costs at the rates KORE1 sees.

These are bill rates, so payroll taxes, workers’ compensation, insurance, and benefits already sit inside them. I’m not adding anything on top. The observed rows come from KORE1 W2 contract placements started between 2023 and 2026, and the Southern California weighting is real, so read them as a regional number. The modeled row starts from BLS Occupational Employment and Wage Statistics data for May 2025, adds a 24% employer burden, and applies the bill-to-cost range KORE1 observes, with the method written out on the contract rate index methodology page. Read the labels.

Nobody sits at their desk staring at a wall for a day. They start the next ticket on top of the unmerged one, and the cost shows up later as rebases, stacked branches, and context somebody has to rebuild from memory. Treat those figures as a ceiling, not an invoice.

An illustration. Not a measurement. Four contractors at the $105 median who each lose three hours a week to review wait add up to 12 hours, which is $1,260 a week. Across a 13-week quarter that comes to $16,380 for a line item nobody ever put in a budget.

What actually shortens the queue, roughly in the order I’d do it:

• Write the one-business-day promise into the team’s working agreement, then measure it weekly from the timestamps your Git host already keeps.
• Cap the size of a pull request. Small ones get reviewed. A 2,000-line one gets deferred, and deferred has a way of turning into never.
• Name two reviewers per area, minimum. If your name is the only one on the rota, you’ve found the bottleneck without any help from me.
• Make CI the boring part. Formatters, linters, and tests fail the build before a person opens the diff, so human attention goes to design and to the edge case the tests didn’t know to ask about.
• Pair on the first pull request. Thirty minutes, screen shared. It teaches a new contractor more than a week of comments, which is the knowledge-transfer finding from the Microsoft study showing up in practice.

None of it is clever. After week two, low-risk changes can merge on green CI with the review following inside a business day. That single move kills more queue time than anything else in the ramp. It is safe for exactly one reason, which is that the money, PII, and production row still stops everything that matters.

When You Are the Bottleneck

Here is how I define engineering leadership, and it applies to this problem without edits. I mean that literally.

If you’re the bottleneck, you’re not leading. You’re just a senior individual contributor with a calendar full of one-on-ones.

A review gate is a decision, so treat it like one. Put “who can merge what” on the same map you use for every other call, the one in the decision ownership diagram, and the ramp table above turns out to be mostly that map with dates written on it.

After the four-day pull request I did what I always tell other people to do, which is show me the data, and I aimed it at myself. I pulled thirty days of merged contractor pull requests and counted two things: how long each one waited for a first response, and how many listed me as the only requested reviewer. The median wait ran past a business day, and my name was on most of them. So the policy wasn’t the problem. I was. Your Git host already keeps the timestamps, so the same count on your repo takes about ten minutes.

It isn’t only about money, either. Devin Hornick, a KORE1 partner, was blunt on a recent internal KORE1 call about why contractors leave: “If you aren’t managing very well and you’re treating them kind of crappy as a manager, they’re going to… leave.” There’s no replacement guarantee on contract to soften that, which makes the manager the retention plan. A four-day wait on a clean pull request is a small, daily version of treating someone badly. Engineers read it as a message about how much their time matters here. They notice.

AI-Written Code in Contractor Pull Requests

Assume some of the code in that pull request came from a model. Assume the same about your employees’ code. Your policy shouldn’t care who typed it.

The author owns every line they submit, whatever its origin. Same bar. Put the approved tools in the contractor’s onboarding document and the contract, because an assistant that sends your source to a third-party service is a data-handling decision, not a productivity preference. Ask for the pull request description to say which parts were generated, since that tells the reviewer where to spend attention. Generated code tends to fail by being plausible, with an edge case handled confidently and wrongly or a helper that quietly duplicates one you already own. Plausible is the problem. And have the author write the tests, not the model that wrote the code.

I covered how to add automated reviewers without adding a new queue in AI code review for engineering teams, and the contractor version needs nothing extra beyond the rules above. If a model wrote half the change, though, who owns the code your contractor writes gets a more interesting answer. That one is a question for your counsel, not your reviewer.

Questions I Get From Engineering Leaders

Should contract developers be allowed to merge their own pull requests?

After week two, for low-risk changes, once CI passes and a review is either done or promised inside one business day. Not on day one, and never on code that touches money, PII, or production.

Branch protection does the enforcing, so the rule survives your vacation. Everything between those two limits is an ordinary feature change, which any engineer who knows that code can approve, contractor or not.

Same review standard for contractors, or a lighter touch?

Hold contractors to the same review standard as employees, because a lower bar ships worse code and a higher one tells good engineers you don’t trust them.

Change who approves and when, never what good means. The ramp is the lever. It’s the same one a new hire would get, run on a shorter clock because the engagement is shorter. When you catch yourself writing a rule that only makes sense because of the employment badge, it’s usually a status rule dressed up as a control.

What does a contract software engineer actually cost per hour?

As of 2026-10-16, KORE1’s own contract placements for a Software Engineer (n=16, 2023-2026, primarily Southern California) billed $91 to $120 per hour, median $105.

A full-time 3-month contract at the median is about $54,600; 6 months is about $109,200. Bill rates include payroll taxes, insurance and benefits. Source: KORE1 Contract Rate Index 2026-Q4. Senior engineers (n=7) billed $91 to $138, median $120.

Can a contractor review code written by employees?

A contractor who knows the module can approve changes to it, because review rights follow knowledge of the code, not employment status.

Wrong question, slightly. The better one is which controls apply by role. The exception is a regulated control. If you run segregation of duties for SOX or a lending audit, write the rule by role and apply it to everyone, so the person who wrote a change can never approve it. A rule that says contractors cannot approve is a status rule, and an auditor will eventually ask you to justify it.

How fast does a first review have to come back?

One business day at the outside, and that is for a first response, not a finished review.

It’s the published expectation in Google’s engineering practices guide, and it’s a fair default for contractors, because their hours are the ones being billed. Put it in the working agreement, measure it from your Git host’s timestamps, and watch the median every week. You want the median well under the limit, not hugging it.

Merge the Four-Day Pull Request

I did merge that retry-path change eventually. Six minutes. That’s the part I still think about.

Afterward I changed three things. I moved the payments path into a CODEOWNERS file with real owners, took myself off the list of universal approvers, and wrote a one-business-day response promise into the working agreement. The next contractor pull request on that service got a first response before lunch. Same engineers. Same code. Same bar. The only thing that changed was that I stopped being the gate. That was the fix.

If you want to argue about the week-three line, or tell me where your own gate is hiding, connect with me on LinkedIn or DM me there. And if the real gap is contract engineers who can ramp inside a review policy like this one, talk to KORE1’s engineering recruiters.

Related reading: The Clarity Stack: 3 Reasons Engineering Velocity Stalls, Why the Best Engineering Leaders Stay Technical, and Tech Contractor Hourly Rates in 2026.