I'm sure you recognize job descriptions with responsibilities like this: Design the architecture. Build the platform. Own the pipeline. Then monitor it, respond when it breaks and do the on-call rotation.
Nine months in: still looking.
The problem isn't just the length of that list. Dev and Ops are not a collection of skills that go well together. I strongly believe they need very different ways of thinking and therefore are done best by different kinds of people.
How DevOps became a job title
DevOps started as a philosophy, not a job title. The idea was that development and operations teams should work more closely instead of throwing deployments over a wall. At some point it became a hiring category for one person expected to own the full cloud platform, the delivery pipeline, and the security posture simultaneously. The engineer who could actually do all of this at production quality was always rare. The job specs describing them as a baseline requirement not.
Two very different modes of thinking
The build side is the creator: designing, conceptualising, translating requirements into infrastructure. Landing zones, Terraform modules, pipelines, architecture that does not exist yet.
Ops works the other way: start from an issue, move through logs, metrics and configuration, find the crux, fix it and sometimes make improvements so it won't happen again. Monitoring, alerting, incident response, on-call.
Where one side creates, the other investigates.
I am the creator type. I like to design and build, I love the creative process of it. Give me a cloud environment and tell me what your goal is with it, and I am happy to design and build it for you. Ops on the other hand, I've learned by now this really drains my energy.
Most people are wired for only one of these modes. And besides capability, there is also preference. People who prefer to create often do not want to own monitoring or carry an on-call rotation. Ops engineers often have no interest in designing new infrastructure from scratch. When someone spends a lot of time doing work they dislike it shows.
Then there is focus. Building and designing requires deep, uninterrupted concentration. You cannot properly work out a cloud architecture in the gaps between production alerts. The brain needs around 23 minutes to return to where it was after an interruption. Ops doesn't wait for perfect timing, but brutally interrupts the engineer's focus. Combining both in one role slows down the development process drastically.
Job descriptions like the one above are not describing one role, but two disguised as one.
What happens when you hire the closest available candidate
When you hire the closest available candidate rather than the right one, a consistent pattern follows. The cloud environment grows without governance because there's no time for it. Security checks happen after incidents, not before. Monitoring gets configured minimally and then forgotten. When that engineer eventually leaves, the environment is harder to hand off than it was to build.
The business risk is much bigger than just a messy codebase. In a small team where one or two people carry all cloud responsibility, the exposure compounds fast. A security incident means the same people who built the platform now have to triage, contain, and remediate simultaneously while everything else waits. When these people leave, a crisis is easily triggered.
Yeah, there are engineers who do both well and actually enjoy both. They exist, but are rare.
Hire for what you actually need
If you want quality, hire the required specialisation. If what you need is a solid cloud foundation, infrastructure automation and guardrails that make sure the environment is secure and meets best practices, that is platform engineering. Hire for that, or bring someone in fractionally to build it. Then figure out who owns production.