DevOps Burnout Has a Tooling Problem

And why absorbing complexity should not be mistaken for expertise

Image generated with ChatGPT

A recent Medium post on DevOps burnout caught my attention. Not because the topic is new — everyone in DevOps, SRE and platform engineering knows the pressure of broken pipelines, pager load, infrastructure drift, deployment risk, and systems that only a handful of people truly understand. What caught my attention was that, at the time I saw it, the post had zero claps, despite coming from an author who regularly writes for this audience and has other posts that clearly track much better.

The part of burnout we do not surface enough

That silence says something. DevOps burnout is widely felt, but not always directly discussed, especially when the conversation moves beyond incidents and on-call pressure. When people do talk about burnout, the discussion often shifts quickly into culture, leadership, boundaries, psychological safety, staffing, and compensation. Those things matter, but they are not the whole story.

There is also a much more concrete contributor: too much of the daily work is low-value operational toil. Engineers spend enormous time maintaining complicated workflows, stitching tools together, babysitting automation, reconciling state, fixing brittle pipelines, patching configuration, and keeping delivery machinery alive. This work is often necessary in the moment, but that does not make it valuable by design.

Complexity is too often treated as expertise

The industry has a habit of romanticizing people who can absorb enormous complexity.

We admire the engineer who can debug a broken deployment across CI, Terraform, Helm, Kubernetes, IAM, observability, and five internal conventions at once. Those people are valuable, and every serious engineering organization has a few of them. But they should not be the model the entire system depends on.

Most engineers do not want their careers defined by human glue work. Most platform teams do not want to maintain fragile internal machinery forever. Most SREs do not want to keep proving their value by rescuing systems that should have been easier to operate in the first place. The point is not that operational complexity can disappear completely; production systems are hard. The point is that much of today’s burden is accidental complexity created by tools and workflows that keep humans in the loop for repetitive, well-understood tasks.

We need to build for the many, not for the few.

A small number of people may enjoy absorbing complexity, solving edge cases manually, and carrying the whole mental model in their heads. But healthy infrastructure and delivery systems cannot depend on rare people constantly compensating for fragile tooling. If the work is repetitive, predictable, and already understood, it should be automated deeply enough that humans are not dragged back into it every week.

The goal is fewer human obligations in the path

This is where platform engineering has to be honest with itself. The goal cannot be to put a nicer portal on top of the same fragile machinery, or to hide complexity behind templates while the same experts still have to intervene whenever reality deviates from the happy path.

A golden path that still requires constant manual interpretation, reconciliation, and repair is not removing toil; it is just packaging toil differently.

The better question is: why is a human still doing this? If the same infrastructure change follows the same pattern every time, it should be on autopilot. If the same drift needs to be detected and corrected repeatedly, it should be on autopilot. If the same deployment workflow requires tribal knowledge, manual checks, and tool-by-tool coordination, the engineer is not the problem. The operating model is.

This matters even more now because AI is increasing the speed and volume of software change. If delivery accelerates while the operational layer still depends on humans manually holding everything together, burnout will get worse, not better. DevOps burnout is not only a people problem. It is a tooling problem, a workflow problem, and a design problem.

We should stop celebrating toil as expertise and start removing the unnecessary work that makes good engineers tired for the wrong reasons.

Check out formae — our idea of how infrastructure management and IaC can be put on autopilot and help with clear use cases: https://platform.engineering/foermae