What does a DevOps engineer actually do?
Most of it is not automation. A DevOps engineer spends the larger part of an ordinary week unblocking other people: repairing a pipeline that broke on a provider upgrade, working out why staging behaves differently from production, and processing access requests. The automation happens in the gaps between those. Hiring on the assumption that the person will spend their days building elegant systems is the most reliable way to disappoint both sides within six months.
What does the job actually consist of?
Six areas, in most organisations. The path from a commit to running code. The provisioning of the environments that code runs in. The observability that says whether it is working. The handling of incidents when it is not. The access, credentials and secrets that let people and services do their jobs. And the cost of all of the above. A DevOps engineer owns the plumbing between developers and running software.
Ownership is usually shared rather than exclusive, and the split matters. Developers write the Dockerfile and the deployment manifest for their own service; the DevOps engineer owns the template those were copied from, the base image underneath, the pipeline that turns them into a release, and the cluster or platform they land on. When that split is not stated, the role collapses into a request queue.
A test you can run today: list the last ten changes that reached production and ask who could have made each one without help. If most of them required one particular person, you do not have a platform, you have a bottleneck, and removing that bottleneck is what the hire is for.
Why do the job ads not describe any of this?
Because ads are written as tool lists, and a tool list describes the environment rather than the work. Two companies can both ask for Kubernetes and Terraform and be advertising jobs that share almost nothing: one is authoring a platform from a blank account, the other is maintaining an estate that predates everyone in the room.
The translation is usually predictable, and worth doing before you publish anything. Each phrase below has a normal meaning and an omission that decides whether the right candidate applies.
| Job ad phrase | The work it usually means | What it leaves out |
|---|---|---|
| Experience with Kubernetes | Diagnosing why a pod will not schedule, and owning upgrades of the cluster add-ons | Whether you run the control plane or a cloud provider does, which changes the job entirely |
| CI/CD ownership | Keeping build times down and quarantining flaky tests so releases are not blocked | Who is permitted to merge and deploy, which is a policy question rather than a tooling one |
| Infrastructure as code | Writing and reviewing Terraform, and repairing state when reality has drifted from it | How much of the estate is already coded, the difference between authoring and archaeology |
| Monitoring and observability | Deciding what wakes a human at three in the morning, and deleting the alerts that should not | Whether anyone is actually allowed to delete an alert once it exists |
| Security best practice | Rebuilding base images, rotating credentials, triaging scanner output | Whether the role can block a release, which decides whether any of it happens |
| Automate everything | Removing the three or four things done by hand every week | That most manual work is manual because of an approval, not a missing script |
Where does the time actually go?
Into the upgrade treadmill and into interruptions, in roughly equal measure. The treadmill is constant: cloud provider versions deprecate, Kubernetes minor releases remove APIs that manifests still use, Terraform providers change resource behaviour, certificates expire, base images accumulate patched packages that only arrive with a rebuild. None of this produces a visible feature and all of it is load-bearing.
Interruptions are the other half, and they are the part that surprises managers reading a sprint board. Access requests, an environment that will not come up, a developer whose build has failed for a reason the logs describe badly. Each is small; together they can consume the working day, which is why platform work reliably slips unless someone protects time for it.
The practical consequence is that a single DevOps engineer with no self-service in place will stay busy forever without improving anything. If you want the treadmill to shrink, the first projects have to be the ones that remove interruptions, not the ones that look most like engineering.
What is not the job, even when it gets assigned?
Being the permanent queue for access requests, being the only person permitted to touch production, and being the default owner of every incident regardless of which service failed. All three get assigned by drift rather than by decision, and all three make the role less effective the longer they persist.
The mechanism is straightforward. If one person is the only route to production, every deployment is scheduled around their calendar, and the queue grows faster than they can clear it. The fix is not more hours; it is a paved route that a developer can take unaccompanied, with the DevOps engineer reviewing the route rather than walking it each time.
Security is the ambiguous one. A DevOps engineer will implement controls, patch images and wire up scanning. They should not be the person who decides your risk appetite or signs off on compliance, because that is an accountability question and giving it to the person who also has production access removes the separation you were trying to create.
What separates a good hire from an expensive one?
Willingness to remove things. The strongest people in this discipline talk about what they deleted: the alerts nobody acted on, the three deployment paths reduced to one, the custom tooling replaced by a supported product. The weaker ones describe what they added, usually a stack of components each solving a problem created by the previous one.
The second marker is comfort with being wrong in public. Infrastructure work is diagnostic, and the honest answer during an incident is often that nobody knows yet. Candidates who narrate a hypothesis, test it and discard it are doing the actual job in front of you; candidates who state causes with certainty before evidence exists will do the same thing at three in the morning.
Ask them what they would do in their first month, then listen for whether they intend to change anything before understanding it. A confident plan to migrate you to a new platform before they have seen your deployment process is a warning rather than initiative.
How do you know whether you need one at all?
You probably do not, if a small team ships to a managed platform, the cloud bill is unsurprising, nobody is on call, and releases are not waiting on a person. That situation is better served by a few days a month of external help than by a permanent hire who will spend most of their time looking for work that matters.
The signals that a full-time role is justified are specific. Releases queue behind one individual. Environments differ from each other in ways that produce bugs nobody can reproduce. The cloud invoice contains line items nobody can explain. Someone is carrying a pager informally and has stopped mentioning it. More than one team now deploys, and they have each invented their own way to do it.
If two or more of those are true, the work already exists and is being done badly by people whose job it is not. That is the case for hiring, and it is a much stronger case than a general wish to be more automated.
Common questions
- What does a DevOps engineer do day to day?
- Mostly unblocking other people and keeping the release path working. A typical week includes repairing a build pipeline that broke on a dependency or provider upgrade, investigating why one environment behaves differently from another, handling access and credential requests, patching base images, and following up on the previous incident. Project work such as automation or platform building happens in whatever time is left over, which is why it slips unless it is protected.
- Is DevOps a job title or a way of working?
- It began as a way of working and became a job title because the work is real and somebody has to own it. The useful reading is that the title describes ownership of the shared path to production: pipelines, environments, observability, access and cost. Hiring one person and expecting the working practices of an entire engineering organisation to change as a result is the misunderstanding that causes most disappointment.
- Does a small team need a full-time DevOps engineer?
- Often not. A small team deploying to a managed platform, with a predictable cloud bill, no formal on-call and no queue behind releases, is usually better served by a few days of external help each month. The case for a permanent hire strengthens when releases wait on one individual, environments differ in ways that cause unreproducible bugs, more than one team deploys, or someone is quietly carrying a pager.
- What is the difference between a DevOps engineer and a system administrator?
- A system administrator maintains systems that other people use. A DevOps engineer builds the path those people take to production and is measured by how rarely they need to be involved in it. The practical difference shows in the artefacts: administration produces tickets resolved, while the DevOps role produces templates, pipelines and documented routes that let a developer ship without asking anybody.
- What tools should a DevOps engineer know?
- Fewer than most job ads list, and the specific ones matter less than the categories. Expect familiarity with a cloud provider, a container runtime and orchestrator, an infrastructure as code tool, a CI system, and a metrics and logging stack. Someone strong in one tool per category learns the equivalent quickly, so screening on exact tool names mostly filters for people who last worked at a company shaped like yours.
