Navigaite
Even the best contractor in the market is only as productive as the environment they land in.
When a placement disappoints, the instinct is to look at the person. Sometimes that is right. But a surprising amount of the time the cause is what they arrived to: no access for the first week, nobody to review their work for three days, decisions that live in someone's head, a team that has never agreed what a reasonable change looks like.
None of that is the contractor's fault, and none of it shows up in a CV. It is also fixable before the engagement starts, which is what makes it worth checking.
Why this matters more now
Google's DORA research, based on nearly 5,000 respondents and more than 100 hours of interviews, found that AI acts as an amplifier. It magnifies the strengths of organisations that are already working well and the dysfunctions of those that are not. DORA identified seven organisational capabilities that determine which way it goes. They are team and company conditions, not tools.
A contractor behaves in much the same way. They amplify what is already there. A good one lands in a clear, well documented, quickly reviewed environment and delivers fast. A good one lands in confusion and spends the engagement navigating it, at a day rate.
Atlassian's 2026 developer experience survey adds a telling detail. The top obstacle in a developer's week is not writing code. It is finding information, named by 51%. That is among people who have colleagues nearby to ask. A contractor has no corridor.
Seven checks before day one
DORA's findings are survey based and show association rather than guaranteed cause, so treat this as a practical checklist rather than a formula. Several items below come from DORA's capabilities directly. Others are simply what follows from them for someone arriving from outside.
Can they get in on day one?
Repository, CI, ticket system, environments, documentation, accounts. The test is simple: could a capable person with no history make a small change and see it run within a day? If access depends on three people being available, the first week is already spent.
Can they find out why?
Written decisions, an architecture note, a README that actually works. DORA found that connecting AI tools and people to internal documentation and code context amplifies individual effectiveness and code quality. For a contractor, context is the difference between a confident first contribution and a polite one in week three.
Is your AI stance written down?
DORA names a clear and communicated AI stance as one of the seven capabilities, because ambiguity about permitted tools creates risk and slows adoption. For a contractor, make explicit which AI tools they may use on your code, what data may and may not be entered into them, and who owns the output. We are not lawyers and these terms belong in your contract, so have whoever advises you on that review the wording. The point here is simply that the question should not be left unanswered.
Are your changes small?
AI makes it easy to produce one very large change. DORA found that working in small batches strengthens AI's positive effect on product performance and reduces friction. Agree up front what a reasonable pull request looks like, and expect the contractor to follow it. If your own team routinely merges enormous changes, say so now.
Who reviews, and how fast?
Name a person and an expected turnaround. A contractor whose work waits days for review is being paid to wait, and the engagement is short enough that the delay is a large share of it. Review is also where unfamiliar work gets checked, so a reviewer who has the time to read properly matters more than one who is quick.
Can a change get out safely?
Version control, automated tests, a deployment path, a way to roll back. DORA describes frequent commits and robust rollback as essential in an AI assisted environment, and quality internal platforms as the automated, secure pathways that let AI's benefits scale without sacrificing stability. Its 2025 findings also associate higher AI adoption with higher delivery instability. A fast contractor with no safety net simply produces problems faster.
What does done look like?
Define the outcome and the quality bar, not the volume. DORA is blunt that output measures such as lines of code inflate easily with AI and should not stand in for productivity. A clear definition of done protects both sides: the contractor knows when to stop, and you know what you are paying for.
If you cannot tick all seven
Almost nobody can, and that is fine. If you have to choose, start with three: access, a named reviewer, and a small change rule. Those cost the least, take days rather than weeks, and remove the most common causes of a slow first month.
Some of the rest, such as documentation and test coverage, take longer than any engagement. A contractor can sometimes help build them, but only if the brief says so explicitly. Asking for a feature and hoping for a documentation clean up is how both get done badly.
Where Navigaite fits
Quality governance from brief to delivery means the brief is where this gets checked. We would rather raise a gap at the start than discover it in week three, because a gap that is known can be planned around and one that is not becomes a disappointment that gets attributed to the contractor.
Every developer we put forward works through a live session on code they have not seen before, because that shows how someone performs when context is thin. But no assessment makes up for a team that has not prepared to receive someone, and we would rather say that plainly than imply a good contractor fixes everything.