Contractor or permanent for infrastructure work?
Contractors are poor at anything whose value appears in year two. That is not a comment on the people, it is a consequence of the incentive: an engagement with an end date rewards visible delivery within it, and the work that makes infrastructure cheap to own later, such as documentation, deletion and teaching other people, is invisible on that timescale. Knowing which of your problems has a deadline and which is permanent settles most of this decision before rates enter the conversation.
What do contract engagements do badly?
Ownership over time, and everything that depends on it. Removing an unused system requires knowing it is unused, which takes months of watching. Reducing alert noise requires having been woken by the alerts. Simplifying a platform requires the standing to argue that something built last year should go. None of these fit inside a fixed engagement, and a contractor who attempts them is spending billable time on work that will not be visible when the invoice is reviewed.
The specific risk is an estate that only the person who built it can operate. It is rarely deliberate. Someone experienced builds at the level they are used to, using patterns that are entirely reasonable and unfamiliar to your team, and the sophistication of the result is proportional to the difficulty your engineers will have maintaining it after the last day.
The mitigation is not to avoid contractors. It is to make the maintainability the deliverable rather than the system, which changes the brief, the review process and how you spend the final third of the engagement.
What are they genuinely better at?
Work with a defined end, work requiring experience you cannot justify permanently, and work nobody internal wants to own afterwards. The split below is the one that tends to hold, and the risk column is where each arrangement usually goes wrong.
| Work | Better as | Reasoning | Risk to manage |
|---|---|---|---|
| Cloud migration with a fixed end date | Contract | Concentrated, unrepeatable, and needs experience you will not need again | Leaving behind an estate documented only in someone's memory |
| Building a first platform or paved route | Contract, with permanent alongside | Benefits from having done it before, several times | Building for the contractor's habits rather than your team's ability |
| Day to day platform ownership | Permanent | Value accrues from knowing what is unused and what keeps breaking | Single point of failure if you only hire one |
| On-call cover for a gap | Contract, short | Fills a rota hole without a permanent commitment | Context is thin, so escalation paths must be explicit |
| Cost reduction programme | Contract, outcome based | Bounded, measurable, and unpopular to own internally | Savings that reverse quietly once the engagement ends |
| Security or compliance remediation | Contract for the work, permanent for the ownership | The remediation ends, the obligation does not | Controls that decay because nobody inherited them |
What does the handover actually consist of?
Six artefacts, and the absence of any of them turns the end of an engagement into a slow emergency. Everything the contractor built must exist in your repository rather than theirs. No cloud resource may have been created by hand. No access may run through a personal account or an API key issued to an individual. State files and their storage must be owned by your organisation. Runbooks must describe the recurring operations. And the decisions, particularly the rejected alternatives, must be written down somewhere durable.
The last one is skipped most often and missed most. A year later somebody asks why the platform works this way, and without a record the answer is guessed, usually wrongly, and the guess becomes the basis for a change that breaks something. A short document listing what was considered and why it was not chosen costs an afternoon.
Do not schedule the handover for the final week. Halfway through the engagement, take one of your own engineers, hand them the documentation, and have them perform a deployment and an environment rebuild without the contractor's help. Whatever they cannot do is the actual gap, and there is still time to close it. Done in the final week, the same exercise only produces an accurate list of what you are about to lose.
How do you write a brief that does not end badly?
State the deliverable as a capability your team will have, rather than as a system that will exist. The difference is concrete: a brief to build a Kubernetes platform produces a Kubernetes platform, while a brief for your engineers to be able to create, deploy and roll back a service without assistance produces something they can operate, which may or may not involve Kubernetes.
Then write in the constraints that protect ownership. Work happens in your repositories and your cloud accounts, under named accounts belonging to your organisation. Anything created outside the code is temporary and must be reconciled. Reviews are done by your engineers, even if they are learning, because review is how knowledge transfers and because a change nobody internal can read has not really been delivered.
Keep at least one internal person adjacent to the work throughout, with time allocated for it rather than in addition to their existing job. This is the part organisations cut when budgets tighten, and cutting it is what converts a well-run engagement into a system that arrives complete and unmaintainable.
How do you hire for a specific cloud or Kubernetes skill set?
Screen for the failure modes of the platform, not for familiarity with its services. Anyone can list the components of a cloud provider. The people who have operated one describe the things that hurt: a permissions model that quietly denies rather than errors clearly, quotas that only appear during an incident, the cost line item that surprises everyone, the upgrade that requires draining nodes in a specific order.
For orchestration specifically, the useful question is what they would run instead and when. Someone who has operated a cluster for years will have a clear view of the workloads that do not belong on one, and will describe the maintenance cycle without prompting. Someone whose experience is a course and a demo estate will describe the architecture rather than the year.
Be realistic about the market. Deep experience with a specific cloud, an orchestrator and a security posture, available permanently, is a narrow pool, and insisting on all three is often what keeps a role open for months. Hiring a strong generalist who has operated one cloud well, and buying the specialist experience for the specific project, fills the role faster and usually produces a better outcome than waiting.
What if you can only afford one person?
Then plan for the day they are unavailable, because it will arrive before you have a second. A single infrastructure engineer is a single point of failure for deployments, access and incident response simultaneously, and the usual response, asking them to document everything, does not work: documentation written without a reader is written at the wrong level and goes stale unread.
Two arrangements help. The first is a standing retainer with an external party who has current access and has actually performed a deployment, so the escalation path has been exercised rather than merely written down. The second is deliberately spreading capability: a developer who can deploy and roll back, a second person with production access under a break-glass procedure, and a rule that no change is applied by the person who authored it without review.
Then test it while everything is calm. Have the single engineer take a fortnight of leave with their access temporarily revoked rather than merely unused, and see what happens. Whatever breaks is what would have broken during their notice period, except that this time you can fix it while they are still employed.
Common questions
- Should you hire a DevOps contractor or a permanent engineer?
- Match the engagement to the shape of the work. Contracts suit problems with an end date, such as a cloud migration, an initial platform build, cost reduction or compliance remediation. Permanent hires suit ongoing platform ownership, because the value there comes from knowing what is unused, what keeps breaking and what should be deleted, all of which require months of continuity that a fixed engagement cannot provide.
- What should a DevOps contractor hand over at the end?
- Six things: all code in your repositories rather than theirs, no cloud resources created by hand, no access depending on a personal account or individually issued key, state files stored and owned by your organisation, runbooks for recurring operations, and a written record of decisions including the alternatives that were rejected. The last is the one most often skipped and the one most missed a year later.
- How do you avoid a contractor building something nobody can maintain?
- State the deliverable as a capability rather than a system, so the brief is that your engineers can create, deploy and roll back a service unaided, not that a particular platform exists. Have your own engineers review the changes even while learning, since review is how knowledge transfers. Then, halfway through the engagement, have one of them rebuild an environment from the documentation alone while there is still time to close the gaps.
- How do you hire a Kubernetes or AWS specialist without one already on staff?
- Screen for the failure modes of the platform rather than familiarity with its service list. People who have operated it describe permissions that deny silently, quotas that appear during incidents, upgrade sequences and cost surprises. Ask what workloads they would not put on a cluster and why. If the pool is too narrow, hire a strong generalist permanently and buy the specialist experience for the specific project instead of leaving the role open.
- What are the risks of having only one infrastructure engineer?
- They become a single point of failure for deployments, access and incident response at the same time, and asking them to document everything does not solve it, since documentation written without a reader is pitched wrongly and goes stale. Reduce it by spreading capability across a developer who can deploy and roll back, a break-glass access procedure, and a retainer whose escalation path has actually been exercised.
- How do you test whether your infrastructure knowledge is spread widely enough?
- Have the person who owns it take two weeks of leave with their access temporarily revoked rather than simply unused, and observe what stops working. Whatever breaks is exactly what would break during a notice period, with the advantage that it can be fixed while they are still employed and available to explain it. Run the same exercise midway through any contract engagement rather than at the end.
