Code Review When Half Your Team Is on Contract
You added two contract engineers to unblock the roadmap. Six weeks later throughput has barely moved. The engineers are clearly working — you can see the commits — but pull requests sit open for three days, your two most senior employees spend their afternoons in review, and nobody is quite sure who is allowed to approve a change to the billing service. The bottleneck is code review with contract engineers, and it is a process problem rather than a people problem.
The engineers are usually not the problem. The problem is that your review process was designed for a team where everyone had the same permissions and the same context, and it quietly broke the day that stopped being true. This post covers the four changes that fix it, the arithmetic behind each one, a 30-day ramp you can run tomorrow, and the cases where adding contract engineers makes review worse rather than better.
Three ways code review with contract engineers breaks down
Review stops being reciprocal
On an all-employee team, review load is roughly symmetric. Everyone opens PRs and everyone reviews them, so the reviewer pool grows at the same rate as the PR volume.
Add contract engineers and a default takes hold that nobody decided on: employees review contract engineers, and contract engineers review nobody. PR volume goes up. The reviewer pool does not. That is the entire mechanism behind “we added headcount and shipped the same amount.”
Say an 8-person team of 5 employees and 3 contract engineers, with the contract engineers opening about three PRs a week each. If only your two senior employees can approve, that is roughly 4.5 reviews per person per week on top of their own delivery work — call it three hours if a meaningful review takes forty minutes. Those numbers are illustrative, but plug in your own and the shape holds: the constraint is reviewer calendars, not engineer capacity.
Nobody wants to be the person who rejects the contractor’s PR
This produces two opposite failure modes from the same avoidance. Some reviewers rubber-stamp, because pushing back on someone they did not hire and do not manage feels like a conversation they would rather skip. Others nitpick — twelve comments about naming, none about the approach being wrong — because style feedback is impersonal and architectural feedback is not. The first ships bad code; the second burns two days on a PR that needed one ten-minute call.
Merge rights are ambiguous, so they default to “ask a senior”
Most teams at this stage have never written down which paths a non-employee can touch. So the question gets resolved per pull request, in Slack, by whoever is busiest. That is not a security posture — it is a recurring interruption that also happens to be inconsistent.
Fix 1: Publish a response-time target, and separate it from approval time
The single highest-leverage change is to stop treating “the review is done” and “the reviewer said something” as the same event. Google’s publicly published engineering practices are explicit on this: one business day is the maximum time it should take to respond to a code review request, and the guide argues that fast individual responses matter more than a fast end-to-end process. It also makes a claim worth quoting to your team directly: “Most complaints about the code review process are actually resolved by making the process faster.”
Write your targets down somewhere the whole team can see them. Something like:
| Event | Target | What counts as meeting it |
|---|---|---|
| First reviewer response | 1 business day | Substantive comments, an approval, or “I can get to this Thursday — ask Ana if it’s blocking” |
| Re-review after requested changes | 4 working hours | The author already context-switched once; a second-day wait doubles the cost |
| Approval, standard paths | 2 business days | Past this, the PR is discussed at standup, not left to rot |
| Protected paths | Named owner assigned at open | No SLA promised, but never unassigned |
Two practical notes. First, Google’s guidance also covers the cross-time-zone case: get back to the author while they still have working hours left, and approve-with-comments when the alternative is making them wait a full day for a trivial fix. Second, be honest about whether this target is achievable at all with your team’s geography. A one-business-day response target is realistic when your engineers overlap five or six hours a day. It is theater when the gap is eleven hours. That overlap is the specific reason we place engineers in time-zone-aligned nearshore staff augmentation roles rather than optimizing purely on rate.
Fix 2: Write the ownership map down once, in CODEOWNERS
Decide the access question a single time, at the repository level, instead of re-litigating it per PR. Three tiers is enough for most teams at this size:
| Tier | Typical paths | Who can approve |
|---|---|---|
| Protected | Auth, payments and billing, secrets and key management, IAM and infrastructure, customer data export, CI/CD config | Named employees only — at least two, so one vacation doesn’t halt the team |
| Standard | Product features, application services, UI, tests, internal tooling | Any engineer past their second week, contract included |
| Open | Docs, fixtures, dev scripts, README | Any engineer |
Enforce it with branch protection and a CODEOWNERS file rather than convention, so the rule is a build failure instead of a memory test. Frame it to the team as an access-control decision, not a trust decision — the same tiering should apply to a new employee in their first month. If you are heading toward SOC 2 or a customer security review, you will need this written down regardless, and doing it before you have non-employees in the repo is considerably easier than doing it after. That said, access tiering is a control decision with legal and contractual dimensions; talk to counsel about what your specific customer agreements and IP terms actually require. Nothing here is legal advice.
Fix 3: Make contract engineers reviewers, not just review subjects
This is the change most teams resist and the one that moves the number most. Look again at the arithmetic. Two approvers handling nine PRs a week is 4.5 reviews each. Five approvers handling the same nine — with the two or three that touch protected paths still routed to employees — is closer to 1.4 each. Same work, a third of the per-person load, and the queue stops being a single point of failure.
There are two secondary benefits that are arguably larger. Reading other people’s diffs is the fastest way a new engineer learns a codebase — faster than documentation, faster than a walkthrough — so review participation shortens ramp rather than lengthening it. And it changes the social position of the person: someone who reviews your code is a colleague, which quietly dissolves the rubber-stamp-or-nitpick problem described earlier.
Gate it sensibly. Review rights on standard paths from week three, after the engineer has shipped a few changes of their own. Anything touching a protected path still requires an employee approval, in addition to whoever else reviewed it.
Fix 4: Cap PR size before it becomes a review problem
A queue problem and a batch-size problem look identical from the outside. Before you conclude your reviewers are slow, check whether they are being handed 900-line pull requests.
DORA’s guidance on working in small batches gives a usable threshold: “Any batch of code that takes longer than a week to complete and check is too big.” The same page flags something specific to how teams work now — AI tools are optimized for generating large, complete features, and DORA notes that “the cognitive load required to review a small chunk of machine-generated code may be higher per line than reviewing human-written code.” Their 2024 report found that AI adoption increased individual productivity while negatively affecting software delivery stability and throughput, with small batch sizes named as one of the fundamentals that still matters.
Practically: pick a line-count ceiling — 400 is a reasonable starting point, adjust to your codebase — and make exceeding it a conversation rather than a rejection. Google’s guide suggests the right reviewer response to an oversized change is to ask the author to split it, or, failing that, to comment on the overall design and hand it back quickly rather than sitting on it. Either way the reviewer’s job is to unblock the author within a day.
A 30-day review-rights ramp
Run this for every engineer who joins mid-stream, contract or employee. It takes about twenty minutes of setup per person.
- Day 1. Repository access at the Standard and Open tiers only. Named onboarding buddy who owns first-response on their PRs for two weeks. Point them at the CODEOWNERS file and say out loud which paths they cannot touch and why — do not make them discover it via a failed check.
- Week 1. First PR is deliberately small and non-critical: a bug fix, a test, a config cleanup. The goal is exercising the pipeline end to end, not delivering value.
- Week 2. Add them as a non-blocking reviewer on two employee PRs. They comment; their approval doesn’t count yet. This is a reading exercise.
- Week 3. Grant approval rights on Standard paths. Add them to the round-robin reviewer rotation. Their first blocking review should be on something small.
- Week 4. Review the actual data with them: median time-to-first-response on their PRs versus everyone else’s, and their own review turnaround. If their PRs wait meaningfully longer than an employee’s, that is a signal about your team, not about them.
- Day 30. Decide explicitly whether any protected-path access is warranted. Write down the decision either way.
Where this is the wrong answer
Adding contract engineers does not always help, and a review process cannot rescue a staffing decision that was wrong to begin with.
- You have exactly one person who understands the system. Every new engineer, contract or not, routes through that person. Adding three of them makes your bottleneck worse for at least a quarter. Fix the bus factor first — pair, document, distribute ownership — then add capacity.
- The work is genuinely undefined. Contract engineers are efficient on scoped work and expensive on discovery, because discovery requires context they don’t have yet and product authority they don’t hold. If you can’t write a ticket, you’re not ready to hand it to anyone new.
- You have no tests and no CI. When review is your only quality gate, it cannot absorb more volume. Adding PR throughput to a team with no automated safety net converts a capacity problem into an incident problem.
- Regulated or contractually restricted code. Some customer agreements, and some regulatory regimes, restrict who may access particular systems or data. That is a question for counsel and your security lead before it is a question about CODEOWNERS.
A five-question diagnostic
If review feels slow but you can’t name why, answer these. Any “no” points at the fix above it.
- Can you state your median time-to-first-response from memory? If not, you are managing a queue you cannot see.
- Is that median different for contract engineers than for employees? A gap of more than a day is a process problem, not a people problem.
- How many people can approve a typical PR? If the answer is two, that is your throughput ceiling.
- Is the protected-path list written down and enforced, or does it live in one person’s head?
- What percentage of PRs exceed your size ceiling? If you don’t have a ceiling, that is the first thing to fix.
If your review queue is the constraint
Every fix above assumes the engineer can actually operate at a senior level — reviewable PRs, same-day responses, design instincts worth extending review rights to in week three. Screening carries more weight on a mixed team than an all-employee one, because you have less time to correct course. That is why our five-gate technical screen is run by a senior engineer in the candidate’s own stack and treats slow communication during screening as disqualifying rather than scored-down. Between 5% and 10% of applicants complete it. Engagement, payroll and compliance mechanics are covered on our nearshore staffing FAQ.
Run the diagnostic first. If the answer is that you need more reviewers rather than more authors, that is a specific hiring brief — a senior engineer in your primary stack, overlapping your working hours, capable of holding review rights by week three. Tell us the stack and the review load you’re trying to relieve and we’ll come back with two or three engineers who cleared all five gates, at no cost to interview.
*Illustrative arithmetic for a hypothetical 8-engineer team. Not measured data.