LO
DevOps / platform / SRE engineer — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Writing the configuration
Automating✓ Evidence-backedInfrastructure as code, pipeline definitions, manifests — the large volume of structured text that describes what should exist.
This is code with a machine-checkable outcome — it applies cleanly or it errors — which is the property that lets a model try, fail and retry without supervision. It is also famously verbose and repetitive, so the volume being drafted is large and the review is quick.
Faster configuration means more configuration, not less work: every resource created is a resource somebody has to keep, secure and eventually delete, and the hours move from writing to untangling. Untangling is invisible on a roadmap, which is why this is the task most likely to look like a saving and behave like a debt.
Being woken up
Still human-led✓ Evidence-backedDeciding at 3 a.m., under time pressure and with partial information, what to roll back, what to degrade and what to tell people while it is still broken.
Automated remediation exists and handles the failures somebody anticipated; an incident is by definition the one nobody did. The decision is about acceptable damage rather than correct answers — which customer-facing degradation is tolerable for twenty minutes — and that is a business judgement carried by a person who will be asked about it afterwards.
The decision staying human says nothing about how many people are on the rota. The common design is fewer engineers covering more services with better automation, which keeps every task intact and makes the on-call worse — and the sustainability of that is a staffing question that no automation metric captures.
What it costs and why
Being augmented≈ Platform inferenceExplaining a cloud bill, finding the thing that tripled it, and deciding which inefficiency is worth an engineer's week to fix.
Finding the anomaly is analysis and tools do it well; deciding what to do about it is a trade-off between engineering time, risk and money that depends on what the company is trying to do this quarter. The first half has got much cheaper and the second has not.
Cheap analysis raises the expectation rather than lowering the work: once a dashboard can name the top ten wasteful resources, somebody has to justify each one that is still there. The task shifts from investigation to explanation, and explanation is a meeting.
Deciding how it should be built
Still human-led≈ Platform inferenceChoosing the architecture, the failure modes you are willing to have, and what the team will still be able to operate in two years.
This is the task with no automatic referee in the whole occupation: whether a design was right is discovered eighteen months later, by which time the person who chose has usually left. It depends on knowing this team's capacity and this company's tolerance, neither of which is in any repository.
Being the safest task is also being the smallest: in most teams design decisions are a few days a quarter, and the rest of the week is the work that is being drafted for you. A role can be secure in its most senior task and still lose most of its hours.