Burnout in IT is an architecture problem, not a personality problem

A Mac admin took a support call at nine on a Friday night, from a senior executive's assistant, while his kids were partway through a movie. It ran until eleven.

He was the only person at a large organization who genuinely understood the Mac side of the fleet. That part has a cause, and the cause is not him.

Nobody else had been trained up, and there was no room in the week to train anyone, because every hour of his workday was already spent being the only person who could answer.

So the reason there was no backup is the same reason there was no time to build one. An org chart drew that circle.

I have heard versions of this story from a lot of admins, and the shape barely changes: a load-bearing individual, an escalation path that exists only on paper, and someone in the next room waiting for the film to be unpaused. Then we respond by sending the individual a link about resilience.

Three design choices that produce a 9pm phone call

No escalation path. When no tier can resolve anything on its own, your most senior person becomes the whole company's help desk. Every issue routes to them because routing anywhere else has no destination. That manufactures round-the-clock demand out of nothing but topology.

"Always reachable," never defined. Almost nobody writes this expectation down, which is what makes it expensive. An unwritten expectation cannot be met, so people meet it continuously, in case.

After-hours availability that is free to the employer. No time back means the organization pays nothing for a 9pm call, and anything free gets consumed at the rate free things get consumed.

Those are decisions. Somebody made them, or inherited them and declined to revisit them. None of the three is a character trait or a failure of grit.

Resilience training for individuals is a way of not fixing an escalation path. It is cheaper than headcount and it moves responsibility from the people who designed the system onto the people absorbing it. I have watched an org roll out meditation licenses in the same quarter it eliminated the only other person who could do FileVault escrow recovery.

The work has no edges

On-site IT has a boundary built out of bodies. People stop walking up to your desk, you go home, the day ends.

Systems and remote work have none of that. As one practitioner put it, the work happens in the background rather than on the front lines, so nothing visibly tells anyone else it is happening, and nothing tells you when it should stop. He worked until nine or ten most nights, not because anyone asked, but because there was work he knew had to get done and he struggled to turn it off.

Then there is the version that eats family time in small bites. A boss pings during dinner promising five minutes. Forty-five minutes later, dinner is cleared and the toddler is already in the bath.

Nobody in that story did anything wrong, which is exactly what makes it worth naming.

Text-based teamwork adds its own tax. Short replies written mid-task read as abrasive, so tone has to be manually softened all day. Run that across two hundred messages a week and it is a second job nobody costed.

Distributed reporting lines make it geometric. One manager had direct reports across a three-hour gap in one direction and an eight-hour gap in the other, which meant, in his words, up early, up late, and up in the middle of the night.

Some of the load is self-imposed. Chronic over-preparation, being mentally ten steps ahead of everybody in 99% of conversations, lands disproportionately on people trying to preempt every objection before it arrives. It reads as competence in a review and as depletion at home.

Loneliness belongs here too, as a design problem. One admin realized he had gone a full week after relocating for remote work without leaving the house or seeing another adult. The fixes are unromantic: shared video rooms where people work independently and talk when they feel like it, enough personal context shared that distributed colleagues register as known people, a weekly call with no agenda, a low-stakes channel for wins.

Warning lights, as distinct from a bad week

Everyone is busy. Busy is not this.

Sunday-night dread, arriving reliably, whatever Monday actually holds. No hour of the week belongs entirely to you, because logging off never fully happens. Withdrawing from teammates usually reads as professionalism, which is why it survives so long.

Losing enthusiasm for the technical work itself is the one I trust most. "If I have to look at another script, I will lose it." Craft is normally the last thing to go, so when the interesting part of the job stops being interesting, the tank is empty.

A spike in irritability counts. One person spent six months being short with almost everyone before tracing it to undiagnosed ADHD amplified by burnout. Naming it let him flag early warning signs instead of grinding through and apologizing later.

Then the one managers should care about most: output quality declines before output volume does. Documentation gets sloppier. Problem-solving gets less creative and more rote.

The first capability to degrade is the capability that would have prevented the next crisis. Ticket counts look fine right up until the runbook nobody bothered to write properly costs you a Saturday.

The far end of the curve is not subtle. An IT manager at a healthcare startup, running dozens of simultaneous clinic buildouts on tight deadlines while his wife was late in a pregnancy, stopped eating and sleeping and sent a distress message to his boss from an emergency room waiting area. A team pulled 19 straight days of 16-hour shifts during an emergency remote-deployment push, and stopped only because a manager forced a week off, reasoning that everybody else knew what to do by then. A solo admin learned he was burned out because his dentist asked whether he had been grinding his teeth at night.

Your body will file the ticket for you if you don't.

Tactics that survive contact with an actual Tuesday

Set a hard stop time and carve out exceptions only for genuine emergencies, with "emergency" defined in writing by someone other than the person on the phone. Build a fixed decompression ritual immediately after logging off, something that marks the transition: a walk, cooking, twenty minutes with a dog or a kid.

Turn notification badges off entirely instead of muting them. The reasoning is honest: "if I see that it's there, I'm going to want to look at it." As a boundary of last resort, do not install the chat app on your personal phone at all.

Redirect off-hours contact to email rather than chat. A chat notification vanishes and gets forgotten, while an email will still be there in the morning, which protects the sender's request as much as the receiver's evening.

Use focus profiles that auto-silence after a set hour. Use scheduled-send after hours, so you are not training colleagues to expect instant replies from anybody.

Block lunch and focus time on your calendar as protected, because people will smash your time, and any open availability they're going to take. Keep an A/B/C priority list (must do this week, important but not critical, can slip for weeks), re-sorted continuously rather than heroically.

Set an auto-reply and snooze rule that states your working hours and names exactly one person who can reach you outside them. Run standing office hours: an open room, set times, drop in with anything. Defend deep-focus blocks the rest of the week, and block two or more hours weekly for quarterly strategic work, or it will not happen in any quarter.

Force hallway interruptions into tickets. One team stopped fixing anything raised by physical ambush and made everything go through intake. It annoyed people for about two days and became one of the biggest time savings they had.

An analog version of all this exists. One admin's spouse sealed his phone inside a potato chip bag on vacation, the foil lining being a serviceable Faraday cage. I am not recommending it. I am noting that someone reached for it, and that it worked.

Documentation is the exit, and it is boring

Every tactic above depends on one person's discipline, which is the weakness of all of them. Discipline is a workaround. The structural fix is writing things down.

Documentation converts individual expertise into organizational resilience. A good runbook lets a help desk person resolve something without escalating, which gives the specialist back their afternoon and makes them replaceable in the good way rather than a single point of failure.

The uncomfortable corollary: being irreplaceable is a bad career position and a worse life position. You cannot be promoted out of a job only you can do, and you cannot take a real holiday from it either.

Open source documents this failure mode publicly. One maintainer in his sixties, 15 years into a project, has spent years trying to hand off institutional knowledge and has not managed it. Substitute your tenured admin, minus the public repo anyone could inherit.

This next part is where I changed my mind. Broadcasting your own completed work is a survival skill rather than bragging: tell leadership, help desk staff, and clients what shipped, in chat, in meeting headlines, wherever they actually look. I found that distasteful for most of a decade. Then a COO messaged me over lunch asking when we could build a feature that had shipped in February, and I understood that invisible work does not stay merely unrecognized. It gets re-requested, and you pay for it twice.

A short audit for managers

Each item has a test you can run this week and a change that costs less than backfilling a resignation.

Escalation path. Pull last month's ten hardest tickets and count how many touched the same person. More than three, and you have a routing problem wearing a staffing costume. Change: define what tier one is equipped to resolve alone, then fund the runbooks that make it true.

On-call definition. Ask two people to write down your after-hours expectation separately, then compare. Change: publish hours, name one designated contact, define what counts as an emergency.

Compensation. If after-hours availability costs the org nothing, it gets spent like it costs nothing. Change: time back in the same week, on the calendar, or a real stipend. Gratitude in a channel is not compensation.

Visibility. Name three things your systems people shipped last quarter, without looking them up. Change: a recurring five-minute slot where infrastructure work gets read out to whoever controls budget.

Quality as the leading indicator. Compare a runbook your team wrote six months ago with one written last week. If the newer one is thinner, you are watching burnout in its earliest legible form.

Org shape. Four shapes, four failure modes. Solo IT has no backup and everyone calls directly, so buy even part-time contractor coverage, document relentlessly, and accept good enough. Corporate IT inside a large company gets decisions made without it, so build allies and push non-urgent contact out of hallways and phones into tickets. A large IT team shares load, then sits blocked waiting on other sub-teams. Delegate, push back, spend energy only on what you control. Managers discover that people problems eat more hours than technical ones. Delegate again, and model the boundaries you want your reports to keep.

What the queue is actually for

A mentor once told an admin that treating a ticket queue as something you defeat by getting it to zero is the dumbest possible goal, because tomorrow's queue is never zero. The work is inexhaustible by design. If that is the nature of the job, endurance was never the thing to optimize. Pace was.

So here is the position I actually hold. If your recovery plan depends on one person's discipline, you do not have a plan. You have a volunteer, and volunteers leave.

There is an enormous amount of published advice for the person taking the 9pm call and almost none for the person who designed a system with exactly one name in it. That asymmetry is a design choice too. It just keeps getting made by people who never have to answer the phone.

---

Foqal builds conversational ticketing for IT teams in Slack and Microsoft Teams, including the structured intake and routing that keeps every escalation from landing on the same person.