Skip to main content
Research
Opinion6 min read

You Do Not Have a Burnout Problem. You Have a Workload Honesty Problem.

The company sends engineers to a mindfulness workshop after a quarter where the team worked 60-hour weeks to hit a deadline that was made up. The problem was not the engineers' resilience. The problem was the deadline.

AuthorAbhishek Sharma· Founder, Fordel Studios

The engineer burned out. They were excellent — one of the best on the team. They shipped consistently, responded to incidents reliably, and mentored juniors effectively. They also worked 55-hour weeks for eight months straight to keep a product on track that was perpetually behind a deadline that kept moving. They left. The company scheduled wellness sessions for the remaining team members and updated the all-hands slides to include "engineer wellbeing" as a priority.

The workload did not change. The deadline setting process did not change. The capacity planning process did not change. The wellness initiative was offered to people who were experiencing the same conditions that had just produced the burnout. The company treated a workload problem as a resilience problem.

···

What Burnout Actually Is

Burnout is not a personal failure of resilience. It is a predictable response to sustained resource depletion — when the demands of the work consistently exceed the capacity of the person doing it, over a long enough period, the person degrades. This is not a psychological edge case. It is what happens to everyone, with some variation in timing based on individual factors.

The conditions that produce burnout are well documented: sustained overload, lack of control over work conditions, insufficient reward for effort, breakdown in community, perceived unfairness, and values mismatch. Engineering organisations create all of these conditions regularly: impossible deadlines, random priority changes, compensation that does not track contribution, teams that are too large or too disconnected, decisions that engineers experience as arbitrary, and product directions that conflict with engineers' sense of what is right to build.

Burnout is the engineering equivalent of a system under sustained load beyond its designed capacity. The solution is not to make the system more tolerant of overload. It is to reduce the load.

Why the Wellness Response Fails

Mindfulness, mental health benefits, and wellness days are valuable. They help engineers manage the stress that is an unavoidable part of difficult work. They do not reduce the workload that is the primary driver of burnout. Offering a meditation app to an engineer working 60-hour weeks is like giving aspirin to someone with a broken bone — it addresses the symptom, not the cause, and it signals that the organisation has diagnosed the wrong problem.

The wellness response also has a political function: it allows the organisation to say it is addressing engineer wellbeing without changing any of the processes that create unsustainable workloads. This is more convenient than honestly examining deadline-setting culture, capacity planning, and the way that ambitious commitments made in leadership meetings become mandatory overtime in engineering teams. The honest examination would require change. The wellness initiative requires a vendor contract.

What Fixing It Looks Like

Fixing burnout requires honest capacity planning: how many hours of focused work can a person realistically do per week, sustainably, over a year? The answer is not 60. For most knowledge workers, it is closer to 35-40 hours of high-quality productive work, with natural variation. Commitments should be made against this capacity, not against a fantasy of what the team could do if fully optimised under continuous pressure.

It requires deadline honesty: distinguishing between dates that are real constraints — customer commitments, regulatory deadlines, competitive windows — and dates that are managerial preferences dressed up as constraints. The former cannot be negotiated. The latter should be. It requires that the people setting deadlines understand the downstream cost of the deadlines they set, including the real probability that the engineer who misses it is not slow but overloaded.

Loading comments...