Burnout Is an Architecture Problem

An engineer we know quit a job everyone thought was great. Good pay, interesting product, kind coworkers. When someone asked why they left, the answer was not about any of that. The answer was that they had been paged 340 times in a year for the same failing service, they had root caused it in month two, and the fix had been deprioritized in every planning cycle since. They did not burn out from working too hard. They burned out from working too hard on things that never stayed fixed.

We keep misdiagnosing this because we keep looking at the wrong layer.

The resilience myth

The standard advice for burnout is personal. Sleep better, exercise, set boundaries, take up a hobby. Some of that is fine advice for being a human. As a response to engineer burnout it is like telling someone to breathe better while standing in a room filling with smoke. The cause is not in the person. It is in the room.

Engineers are not fragile. These are people who happily grind through hard launches and messy migrations when the work moves forward. What they cannot absorb indefinitely is work that moves in circles. That is the specific thing that breaks people, and it is produced by the system, not by the person.

Where the burnout actually comes from

Look closely at any burned out team and you will usually find the same three mechanisms running underneath.

The first is unfixed root causes. Every incident whose underlying cause was never removed becomes a recurring tax. It pages someone at night, it gets patched, it waits, it pages again. A team carrying ten of these is doing the same work over and over, forever, and their calendar knows it even if their planning spreadsheet does not.

The second is alert noise. When a monitoring system fires on symptoms instead of causes, it pages for things that would have self healed and stays quiet about things that matter. The team learns that most pages are garbage, which means they stop trusting them, which means the one real page eventually gets ignored too.

The third is ownership without authority. Someone is on call for a service whose worst problems live in another team's code, and their only lever is filing tickets that die in a backlog. They are accountable for fires they are not allowed to prevent.

Notice what these have in common. None of them is a stamina problem. All of them are architecture problems. The on call system, the alerting design, the way fixes get prioritized, the way ownership maps to power. An individual can be perfectly rested and still be ground down by this machinery, because the machinery produces wasted work as its normal output.

Fix the loop, not the person

If burnout is generated by the system, the fix has to be a system fix, and it is refreshingly concrete.

Treat recurring incidents as debt with interest. Every root cause that stays unfixed keeps charging the team in pages, in context switching, and in quiet dread. When a planning cycle comes up, the question is not whether the fix fits the roadmap. It is how many future pages it deletes. Fixes that kill recurrence are the highest yield work a tired team can do.

Alert on causes, not symptoms. A good alert is one where the correct response is a human action and the problem will not resolve itself. Everything else should become a dashboard, a trend, or nothing. Teams that do this typically watch their page volume drop by more than half, and the pages that remain are ones worth waking up for.

Give on call engineers a path to prevention. If you own the pager for a service, you need the standing ability to fix its worst causes, including ones that cross team lines. A rotation where people can only mop is a rotation designed to churn people.

The order matters too. Killing root causes first reduces pages, fewer pages make alerting sane, sane alerting makes on call survivable. Teams that try it in the other order, with resilience training and wellness programs on top of an unchanged system, reliably discover that the retreat does not survive contact with the next quarter.

The uncomfortable conclusion

Burnout is not the price of hard engineering. It is the price of circular engineering. Nobody quits because the work was too hard. They quit because the work kept undoing itself while everyone praised their resilience.

We think the telling metric is not hours logged or even pages received. It is recurrence. How many of the problems you fixed this quarter came back. A team whose fixes stay fixed gets calmer every month without anyone lowering a bar. A team whose fixes keep coming back gets more exhausted every month no matter how many wellness perks you add. The system, not the person, decides which team you have.

Try it this week

Pull the last three months of incidents and count how many share a cause with an earlier incident. That number is your burnout engine. Pick the single worst repeat offender, root cause it properly, and fix it all the way. Then watch what happens to the pager, and to the people carrying it.