Open the DevOps job description you last posted and read it as if you were the candidate.
Deep Kubernetes — not "familiar with", you want someone who can debug a CNI problem at 2am. Terraform across a real estate of modules. AWS or GCP to architect level. PostgreSQL: replication, failover, the migration that must not lock the table. Networking, load balancers, TLS termination, probably an F5 somewhere. Security and compliance, because SOC 2 is on the roadmap. CI/CD. Observability. Cost control. And on-call.
Every one of those is somebody's entire career. You have asked for six of them, in one person, at one salary, available permanently.
That person is not rare. That person is fictional — and the interesting part is that the problem does not go away if you find them, because it is not only a problem of skills. It is also a problem of arithmetic: one person can be in one place at a time. The two worked examples below are the two ways that bites.
What you actually get when you hire
There are three candidates for this job and you have met all of them.
The strong generalist. Genuinely good, covers 70% of the list competently, and is the right hire far more often than people admit. But the 30% they don't cover is not evenly distributed — it is concentrated in the things that are rare, expensive and dangerous. They will keep your cluster healthy and they will be learning Postgres replication semantics from a blog post on the night your primary fails over badly.
The deep specialist. Brilliant at one or two of those things, which is exactly what you want during the quarter that needs those things — and then they spend the other three quarters doing work that neither uses their expertise nor develops it. They leave, and reasonably so.
The unicorn. Exists. Is currently a staff engineer somewhere that pays well, or is running their own consultancy. If you land them, you have a single point of failure with a market value that rises every year you keep them and a resignation that takes six months to recover from — we wrote the recovery playbook in When Your Only DevOps Engineer Quits, and it is not a document anyone enjoys needing.
None of this is about money. We argued the cost side separately in The Ghost on Your Payroll. This is the other half: the part a bigger salary does not buy.
Use case one: the year that needed six disciplines
Here is a year at a Series A company — around eighteen engineers, production Kubernetes, a SOC 2 commitment and a cloud migration. Each row is a body of work that genuinely arrived. Each needs someone who has done it before.
Nobody is deep in six of those rows. Realistically a strong hire owns two and is competent in two more, which means a third of that year is done at a level you would not have accepted if you had watched it being done. The work still ships. It ships with decisions in it that a specialist would not have made, and you find out which ones eighteen months later.
Notice August. Three rows run at the same time, because that is what a migration does — it pulls the platform, the database and the network in together. Which is the second problem.
Use case two: the two weeks that needed two people at once
Skills are only half of it. Suppose you did hire the unicorn. Here is a two-week stretch: a SOC 2 evidence deadline with a fixed date, and — on day four — replication lag on the primary database that turns into a failover problem.
This is the failure mode people underestimate, because there is no villain in it. The engineer did not underperform. The estimate was not wrong. Two things needed doing and there was one person, so one of them waited — and the one that waited happened to be the one with a date attached to it.
An incident is the sharpest version, but the same arithmetic applies to anything with a deadline: a launch, a pen-test remediation window, a customer's security questionnaire, a region that has to be live before a conference. Every one of them collides with normal operations sooner or later.
What a team changes, specifically
Not "more hands." Three concrete things, and they map onto the two charts above.
Breadth without a hiring round. The specialist for each row already exists on the team and rotates in for the weeks that need them. You are not paying a Postgres expert to sit through the three quarters that have no database work; you are borrowing them for the two weeks that do. That is what closes the first chart.
Two engineers on every engagement, minimum. Not two people sharing the hours — two people who both know your infrastructure, which is what makes the second chart's bottom row possible at all. It is also why a vacation, a bad flu or a resignation is a scheduling event here rather than an outage in your roadmap.
Context that outlives any individual. The thing that actually makes a single hire scary is not their skills, it is that the reasoning lives in their head. Work delivered as code, documented, in your accounts, reviewed by a second engineer who also has to understand it — that is a different risk profile, and it is deliberate. The engagement models differ in how they are billed, not in this.
When one hire is still the right answer
When the rows stop being spiky. If your infrastructure genuinely needs Kubernetes work every week of the year, you do not have a breadth problem — you have a full-time job, and you should fill it. Past roughly fifty engineers that is usually where things land, and the honest advice becomes "hire, and let us hand over cleanly."
It is also the right answer when the work is unusually narrow. A company whose entire infrastructure story is one well-understood stack, with no compliance pressure and no migration on the horizon, does not need six disciplines. It needs one good engineer and someone to call when the unusual thing happens.
What does not work is the middle: a job description with six careers in it, one salary attached, and a quiet assumption that whoever takes it will cover the rest by reading fast.