This article is based on reporting originally published by TechTarget, covering a session by Ken Mugrage at the 2017 O’Reilly Software Architecture Conference in New York City.
A Serious Problem That Deserves a Serious Conversation
Ken Mugrage, a former U.S. Marine and technology evangelist at ThoughtWorks, brought an uncomfortable truth to the stage at the 2017 O’Reilly Software Architecture Conference: software developers and engineering managers are burning out—and in the most extreme cases, that burnout is contributing to deaths.
This is not a peripheral concern or a soft-skills sidebar. The U.S. Centers for Disease Control and Prevention (CDC) has listed computer programming among occupations where individuals are statistically more prone to suicide. DevOps practitioner and industry voice John Willis addressed this directly in his widely-read blog post titled Karōjisatsu—a word combining the Japanese terms for overwork and suicide—in which he recounted the losses of talented engineers and developers to suicide. Burnout, left unaddressed, is not just a performance issue. It is a public health issue.
Why Burnout Matters Beyond Productivity
Burnout is clinically distinct from ordinary stress. Some researchers categorize it alongside conditions such as PTSD and depression. As Willis has noted publicly:
“Some researchers put burnout in the same clinical category of diseases like PTSD and depression. In some cases the ultimate effect can be death; however, more common results are health-related stress symptoms. Other work-life balance issues can arrive from unresolved burnout symptoms—for example, divorce, disconnectedness from family and friends.”
John Willis
The psychological toll of sustained overwork in high-pressure engineering environments is real, measurable, and harmful. Mugrage’s core argument is that acknowledging this reality—and taking deliberate steps to address it—is both a moral responsibility and a practical one: people who are not burned out tend to do better work.
What Teams and Managers Can Do
Mugrage was clear that professional mental health support is the most reliable intervention when burnout symptoms cross into depression or suicidal ideation. There is no DevOps practice that replaces clinical care. However, for teams and individuals who want to take proactive steps, several practical approaches were outlined in his talk.
Measure Burnout Formally
The Maslach Burnout Inventory (MBI) is a professionally designed psychometric instrument widely recognized in occupational health research as a leading tool for identifying and measuring burnout symptoms. It is available for individual use as well as through organizational subscriptions, making it practical for both personal self-assessment and team-level wellness programs.
Protect Work/Life Balance Deliberately
Good intentions are not enough. Managers must actively protect engineers from work overload, not simply encourage them to “take breaks.” This means tracking on-call burden, rotating responsibilities, and setting realistic sprint commitments.
Consider Mental Health First Aid Training
Mugrage recommended that engineering managers and team leads consider Mental Health First Aid (MHFA) training—structured programs that teach non-clinicians how to recognize early signs of mental health problems and how to respond appropriately. This is an emerging practice in some forward-thinking tech organizations.
The DevOps Effect: How Culture Can Help—and Hurt
Mugrage argued that a correctly implemented DevOps culture can directly counteract some of the structural conditions that produce burnout. The key word is correctly.
Small, Empowered Teams Reduce Helplessness
One of the recognized psychological drivers of burnout is a lack of control over one’s own work. Large, fragmented teams with unclear ownership amplify this feeling. DevOps best practice—including the widely cited “two pizza rule” associated with Amazon, which holds that a team should be small enough to be fed by two pizzas—pushes organizations toward smaller, cross-functional units where individuals have genuine agency over outcomes. When everyone on the team owns the product end-to-end, communication is more direct and less likely to break down across silos.
Shared Responsibility Creates Psychological Safety
Another burnout driver is the experience of unfairness—being blamed for failures that originate elsewhere, or carrying disproportionate risk for problems outside your control. In a mature DevOps organization, responsibility is shared and accountability is distributed. No single person is scapegoated when a deployment fails; the team owns the outcome together. Mugrage acknowledged that this model can increase the felt responsibility of each individual, but most engineers find it preferable to working in an environment where blame is passed arbitrarily.
DevOps Can Also Make Things Worse
Mugrage was honest about the limits of DevOps as a remedy. If an organization creates a siloed, separate “DevOps team” without changing underlying culture or addressing workload, it can actually compound dysfunction. DevOps practices do not resolve burnout caused by toxic company values, chronic under-resourcing, or leadership failure. The cultural transformation has to be genuine, not cosmetic.
Key Takeaways for Engineering Leaders
- Burnout is a clinical condition, not a motivation problem. Treat it with the same seriousness as any other occupational health risk.
- Measure it. Tools like the Maslach Burnout Inventory exist precisely so that burnout does not go undetected until it becomes a crisis.
- DevOps culture, done properly, addresses structural causes of burnout—lack of autonomy, communication breakdowns, and perceived unfairness—but it is not a substitute for professional mental health support.
- Team size and ownership model matter. Smaller, empowered teams with clear end-to-end ownership tend to produce healthier working conditions.
- A siloed “DevOps team” is an anti-pattern that can deepen existing problems rather than solve them.
- If you or a colleague are struggling, seek professional help. In the United States, the 988 Suicide and Crisis Lifeline is available by calling or texting 988.
Software engineering is a high-stakes profession with real human costs. DevOps, at its best, is not just a delivery methodology—it is a set of cultural and organizational principles that, when applied thoughtfully, can make engineering work more sustainable and more humane.