A senior engineer pinged me a couple of years back. Just “got a sec?” with no other context. We hopped on a call.
She had been promoted to Staff six months earlier. Her review cycle was glowing. She was leading the most strategic project in the org. And she told me, in that flat tone people use when they have been rehearsing the sentence in their head for weeks, that she thought she was burning out.
I asked her what it felt like. She paused. “Different than last time.”
She had burned out before in a different company, as a mid-level IC. That one had a familiar shape: too many tickets, too few hours, weekends bleeding into Mondays. She fixed it the way most people do. She set boundaries, took two weeks off, switched teams. It worked.
This time was nothing like that. She wasn’t tired. She was hollow. The work was technically fine. The team was fine. Nothing was on fire. She just couldn’t find a reason to care about any of it, and the absence of that reason was its own slow horror.
“I thought this was supposed to get better when I got senior,” she said.
It doesn’t. It just changes shape. And almost nobody tells you that.
That conversation has stayed with me, because I’ve had some version of it dozens of times now. Different titles. Different orgs. The same confusion: why does the burnout I’m experiencing right now look nothing like the burnout I’ve been trained to recognize?
The honest answer is in a piece Daisy Auger-Domínguez published in HBR earlier this month , which I think is the most useful thing I’ve read on burnout in years. Her central claim: burnout isn’t one illness. It’s four. They look different. They feel different. They have different root causes and different fixes. And which one you get is largely a function of where you sit on the org chart.
I want to take her framework and translate it into the specific shape it takes inside engineering organizations, because the translation is where most of the useful detail lives. Engineering has its own ladder, its own incentives, its own particular way of building each variant of burnout. We also have a dual ladder, which produces a fifth pattern she doesn’t quite name.
Then I want to address the question that almost nobody else does honestly: what do you do when you are the one burning out and you don’t have the authority to redesign the work?
This will be uncomfortable. Burnout coverage in our industry is overwhelmingly about either symptoms (the seven warning signs of engineering burnout , the 10 tips for engineers) or about exhortations to leadership to “fix the system.” Both are useful, and I have spent time on the symptoms angle myself in Demystifying Burnout . But neither tells you what to do at 11pm on a Thursday when you’ve just realized you’ve been in survival mode for nine months and the system has no plans to fix itself.
So let’s talk about the five faces. Then let’s talk about the AI overlay. Then let’s talk about what to do when you cannot redesign the design.
Face one: ambiguity (the burnout of the early-career engineer)
Auger-Domínguez calls this Invisible Overload. Her description: constantly guessing what “good” looks like. Spending more time decoding expectations than doing the work. Anxiety about being replaceable.
I have watched this play out in person more times than I can count.
The pattern in engineering: a junior or mid-level engineer who, by all visible measures, is doing fine. PRs land. Standups go normally. They show up. But every conversation with them has a faint undercurrent of dread. They ask “is this what you wanted?” three times a day. They rewrite their Slack messages four times before sending them. They spend 40 minutes on a one-line code change because the meaning of the change is unclear.
They are not lazy. They are not disengaged. They are doing an enormous amount of invisible work that has nothing to do with the actual code: reading the room, decoding norms, figuring out who actually decides things, calibrating what “fast enough” means here, modeling what their tech lead actually wants when they say “use your judgment.”
In an office, this work is largely automatic. You absorb most of it from proximity. You overhear the staff engineer arguing with the PM. You see what your manager rolls their eyes at. You learn what gets praised and what gets quietly fixed by someone else.
In hybrid and remote engineering orgs, that absorption layer is gone, and we have not replaced it with anything. So the work doesn’t disappear. It moves into the engineer’s head, where it sits there draining cognitive energy 10 hours a day with no name.
Research consistently shows that lack of control and unclear expectations are stronger predictors of burnout than hours worked. The early-career engineer isn’t burning out from coding too much. They’re burning out from being asked to operate as a senior engineer (figuring out priorities, navigating ambiguity, making judgment calls) without yet having the model to do so cheaply.
The cruel part is that this burnout is invisible to managers because the work is still getting done. They’re still shipping. They’re just dying inside while doing it. By the time anyone notices, the engineer has either quit or hardened into the cynical, defensive shape that takes years to repair.
What actually helps at this layer:
- Make the implicit explicit. Write down decision rights. Say out loud who has authority for what. Tell people what “good” looks like with specifics, not vibes. The cost of explicit norms is some boring documentation. The cost of implicit ones is your team’s nervous systems.
- Cap weekly priorities at three. Not five. Not “everything is important.” Three. People can hold three things in their head and still feel like they’re winning. They cannot hold seven.
- Normalize asking. Demonstrate that asking “what do you actually want?” is a sign of engineering maturity, not weakness. Then catch yourself when you punish it.
- Real-time feedback, not review-cycle assessments. If someone is operating off the wrong mental model, the cost compounds daily. Telling them at the next half-yearly review is not feedback. It’s a postmortem.
Face two: compression (the burnout of the engineering manager)
Auger-Domínguez calls this Compression. The shape: absorbing pressure from above while protecting the team below. Working off-hours to catch up, compensating for unclear decisions. Carrying team emotion without structural support.
In engineering, this is the EM and the senior EM, and it is the single most underappreciated burnout pattern in the industry.
The EM’s job, in practice, is to translate. From product into eng. From strategy into roadmap. From the VP’s vague directive into something the team can actually execute. They are the load-bearing wall between two layers of the org that don’t quite speak the same language.
The job depends on a quiet contract: the EM gets enough authority to make decisions on behalf of their team, and the team gets enough protection to focus on the work. When the contract holds, the EM sweats but doesn’t burn. When it breaks, the EM becomes a pressure-release valve with no exhaust.
The contract breaks in predictable ways. The reorg that adds two more teams to the EM’s portfolio without adding direct reports of their own. The new VP who wants to be looped into “all major technical decisions” but won’t define what major means. The promotion that comes with a bigger budget number but no real say in headcount. The matrix structure where the EM owns the team’s outcomes but the staff engineer owns the technical direction and the PM owns the priorities, and somehow when everything goes sideways the EM is the one in the postmortem.
One survey found middle managers report higher burnout (36%) than non-managers, and 71% report being “sometimes or always” overwhelmed. That gap isn’t because EMs are weaker. It’s because the role, as currently designed, is a structural burnout factory.
I have been here. I will be here again. Every EM I respect has been here at some point. The honest version of the job sounds like this: you are paid to absorb chaos so that twelve other people can focus, and the price of doing it well is that nobody, including you, can clearly see how much you are absorbing.
The EM’s burnout doesn’t look like exhaustion. It looks like Sunday anxiety. It looks like checking Slack at 10pm because if you don’t, you’ll find out tomorrow morning that something blew up and three of your reports are in DM with each other trying to figure out what to do. It looks like decision quality slowly dropping because every decision is being made under low-grade adrenaline. It looks like the EM no longer being able to write the strategy doc, because there is no quiet anywhere in the schedule for the kind of thinking strategy requires .
What helps:
- Reduce meeting load from the top. Not as an EM hack. As an explicit executive choice. If your EMs have eight hours of meetings a day, you don’t have managers, you have meeting attendees with managerial titles.
- Clarify decision rights so the EM doesn’t have to manufacture them. “You can spend up to X without approval.” “You can make the call on Y.” “Z escalates.” Specificity is a love language for managers.
- Build a regular check-in that asks about obstacles, not status. Status updates are theater. “What is in your way that you can’t move yourself?” is the only question that surfaces compression early enough to help.
- Stop calling availability commitment. The EM who answers Slack at 10:30pm is not your most committed manager. They are the one whose role is the most broken. Reward depth, not response time.
Face three: the dual-ladder trap (the burnout HBR doesn’t quite name)
Here’s where the HBR framework needs an engineering-specific addition.
Engineering organizations have something most other professions don’t: a real, structural dual ladder. Past senior, the path forks. Some people become EMs and head into the manager track. Others become Staff, then Principal, then Distinguished, and stay on the IC ladder. Both ladders are supposed to lead to seniority and influence. In well-designed orgs, they do.
In poorly designed orgs (which is most of them), the IC ladder produces its own brutal burnout pattern that combines the worst features of two of HBR’s other categories.
The Staff or Principal engineer is asked to operate at the strategic horizon of an executive: think across the org, influence roadmap, sniff out architectural risk three quarters out, mentor four EMs’ worth of engineers. They are evaluated on impact, scope, and “tech leadership,” none of which are things they can do without authority over other people’s time and priorities. But they don’t have direct reports. They cannot say “do this.” They can only convince, persuade, model, write, and influence. And when the persuasion fails, the impact suffers, and they get told they need to “level up their tech leadership.”
This is moral injury without the title to absorb it. They see what’s wrong. They have been telling everyone for nine months. The org chooses not to act, because the org has different priorities and the Staff engineer doesn’t have the executive authority to force the issue. The codebase they’re responsible for keeps degrading in a direction they predicted. Eventually they stop predicting, because what’s the point.
I have watched extraordinarily talented Staff and Principal engineers burn out this way. The pattern looks like a slow, gradual disengagement from the organization-shaping work, followed by a retreat into deep-IC mode, followed by leaving. From the outside, this looks like “they decided they’d rather just code.” From the inside, it’s grief. They cared. They tried. They got tired of their care being treated like a free resource.
The fix the IC ladder needs is genuinely hard, because it requires the org to do something it usually does badly: give Staff+ engineers actual decision authority over the technical direction in their domain, and back them when they use it. Most orgs don’t. They give Staff engineers visibility and weight, but reserve the actual decision rights for VPs and directors who have less context.
If you are a Staff engineer reading this and any of it sounds familiar, the thing I want you to know is this: the burnout you have isn’t a sign you’re insufficiently resilient. It is a signal that the role, as your org has structured it, is not actually possible. That doesn’t mean leave. It means stop blaming yourself for failing to do an impossible job, and start having very direct conversations about what authority you would need for the role to be sustainable.
Face four: moral injury (the burnout of the executive)
Auger-Domínguez calls this Moral Injury, borrowing a term from Jonathan Shay’s research on combat veterans. The original definition: the lasting damage done by perpetrating, witnessing, or failing to prevent acts that violate one’s deeply held moral beliefs.
Inside engineering executive ranks (directors, VPs, CTOs), this is increasingly the dominant flavor of burnout. The shape: chronic vigilance. Isolation at the top. Values conflict masked as “strategy.” A sense of carrying consequences alone.
The classic example: the layoff. You are a director. Your VP tells you to cut 15% of your org. You disagree with both the number and the criteria. You raise your concerns. You get heard, partially. The number changes from 15% to 12%. You go back to your team and execute the layoff. You are the one who tells five engineers, three of whom you hired, that their roles are eliminated. They cry. One of them is a single parent. You do this on a Thursday and then chair a roadmap meeting on Friday morning where everyone pretends Thursday didn’t happen.
You did not make the decision. You disagreed with it. You executed it anyway, because that is what the job requires. And you carry it.
That’s moral injury. It is not stress. It is not workload. It is the slow, accumulating cost of acting against your own values at a scale and in a way that you can never fully metabolize. Recent research on tech leadership notes that 26% of executives report symptoms consistent with clinical depression, compared to 18% in the general workforce. The gap is not because executives have it harder. It’s because their burnout is shaped by something most workplaces don’t even have a vocabulary for.
The cruel part of moral injury is that the standard burnout fixes make it worse. “Take a vacation” doesn’t help, because the moral residue doesn’t decay with rest. “Set boundaries” doesn’t help, because the problem isn’t volume of work, it’s the content of the decisions you’ve made. “Do more self-care” lands as condescension, because the executive knows perfectly well what self-care is. They are not in distress because they’re insufficiently rested. They’re in distress because they have done things that they can no longer pretend not to have done.
What helps, and this is genuinely hard:
- Trusted peer forums. Not your direct reports. Not your boss. Not your spouse, who shouldn’t have to absorb this. Other executives, ideally outside your company, who have made versions of the same decisions and can talk about them honestly. If you don’t have this, build it. Other CTOs are your peers in a way nobody inside your company can be.
- Slow the decision pace. Most executive burnout I’ve seen comes from too many irreversible decisions made too quickly. Build in structured reflection time before high-stakes calls. The cost of waiting 48 hours on a hard decision is almost always lower than the cost of getting it wrong.
- Name the values conflict explicitly. When you are being asked to do something you disagree with, the moral cost is lower if you have named the disagreement out loud, even if you still execute. The damage compounds when you pretend, even to yourself, that you agree.
- Stop confusing composure with health. The fact that nobody can tell you are suffering is not a sign that you aren’t.
Face five: identity collapse (the burnout of the founder, and the head of engineering who acts like one)
The final shape Auger-Domínguez names is Identity Collapse, which she places primarily with founders and nonprofit leaders. The pattern: inability to rest without guilt. Personal worth tied to organizational survival. Staying in chronic crisis mode.
I want to extend this to a category she doesn’t quite cover: the head of engineering at a small or mid-stage company who has fused their identity with the engineering organization itself. The CTO who can’t take a real vacation because “what if something happens.” The VP of Eng who answers Slack from their kid’s recital. The first-engineering-hire-now-running-the-show whose entire sense of self is bound up in whether the next release goes well.
This isn’t rare. It’s the modal failure mode of the leader who built the thing they now run. The work used to be something they did. It is now something they are. When the two collapse, rest stops feeling like recovery and starts feeling like betrayal.
The signal is usually something a partner notices first. They can’t put their phone down. They go on vacation but they’re not actually there. A small production incident on Saturday consumes the entire weekend, including the part where they were supposed to be at their kid’s birthday party.
If this is you, the only durable fix is to deliberately, structurally build the org so that you are not the single point of failure for it. Not as an exercise in delegation. As an exercise in your own continued ability to function as a human. “If I rest, I worry no one will carry the mission” is a sign you have built something dependent on your overextension, and the most generous thing you can do for the mission is to make it less dependent on you.
The ladder doesn’t cure burnout. It changes its shape.
This is the implicit truth in Auger-Domínguez’s framework, and it’s the part I think more engineers need to hear out loud.
The mid-level engineer who burns out from too many tickets often consoles themselves with: “this will get better when I’m senior. Senior engineers don’t get pulled into every fire.” Then they get to senior and the fires are different but they’re still on fire.
The senior who burns out from being on call for everything tells themselves: “this will get better when I’m Staff. Staff engineers get to focus.” Then they get to Staff and discover they are now responsible for things they cannot control, and that the lack of authority is a worse burnout than the lack of focus was.
The Staff engineer thinks: “this will get better when I move into management and have actual reports.” Then they become an EM and discover compression, and Sunday anxiety, and the strange experience of having authority over people but not over the conditions of their work.
The EM thinks: “this will get better at director, when I’m shaping strategy instead of executing it.” Then they become a director and discover moral injury, and isolation, and the slow weight of decisions they cannot fully make.
The director thinks: “this will get better when I’m VP, when I have real authority.” And the VP, who has more authority than they’ve ever had, finds out that authority is the thing that creates moral injury, not the cure for it.
The ladder is not a treatment plan. Each rung is a different illness. Promotion does not heal you. It changes which symptoms you have.
This is not a counsel of despair. It’s a counsel of accuracy. Once you know the burnout you have is structurally different at each level, you can stop waiting to be promoted out of it and start actually addressing the version you have right now.
The 2026 AI overlay
I want to add one piece the HBR framework doesn’t cover, because it’s relevant to anyone in engineering reading this in 2026.
AI is amplifying every layer of the burnout map. Not equally. Differently.
For the early-career engineer, AI has dramatically increased the ambient ambiguity. What does “good” look like when 80% of your code can be generated, and the remaining 20% is the part that requires judgment you don’t yet have? “Junior engineer” used to mean “person learning to code.” Now it means “person learning to evaluate code,” which is a much harder job to learn cheaply. The decoding load has gone up, not down.
For the EM, AI has multiplied the throughput of their team without multiplying their decision capacity . PR volume goes up. Review burden goes up. The number of small decisions per day goes up. The EM’s own brain stays exactly the same size. Compression intensifies.
For the Staff engineer, AI has made the architectural risk landscape genuinely harder to model. Codebases are growing faster. Coupling is being introduced by people who don’t fully understand what the AI generated for them. The Staff engineer can see the systemic risk earlier than anyone else, but their authority to act on it has not grown. Moral injury accelerates.
For the executive, AI is the topic on which they are being asked to make the most consequential decisions of their career, with the least clear evidence, on the shortest timeline, in front of boards that don’t fully understand the technology and employees who rightly fear what those decisions will mean for them. Layoffs framed as “AI efficiency.” Hiring freezes framed as “we’ll see what AI does.” Each of those is a moral-load decision, and there are now a lot more of them per quarter.
I’m not saying AI causes burnout. I’m saying the five faces are all currently being amplified by it. Anyone diagnosing their own burnout in 2026 should factor this in.
What to do when you can’t redesign the system
This is the question almost no one writes about honestly.
Most burnout coverage assumes you have the authority to fix the conditions producing it. “Cap priorities at three.” “Clarify decision rights.” “Reduce meeting load from the top.” Wonderful. What if you’re the EM whose VP has not heard of any of this and won’t?
Here is the honest answer, in three parts.
First, get accurate about which face you have. This sounds trivial. It isn’t. Most people I’ve talked to about their burnout were misdiagnosing it, which meant they were also applying the wrong fix. The mid-career engineer trying to fix moral injury with vacation. The Staff engineer trying to fix compression with focus time. The executive trying to fix moral injury with workouts. The fix that maps to the wrong burnout is worse than no fix, because it consumes the energy you needed for the right fix and produces no relief, which then becomes evidence in your own head that you’re broken.
Read the HBR piece. Sit with it. Figure out, with as much honesty as you can, which face you have right now. If you also want a numerical read on the underlying exhaustion, the Maslach inventory I shared earlier is the standard tool for scoring it. Notice that the face you have is probably not the same one you had two years ago.
Second, do the things you can do, even when they feel insufficient. You may not be able to redesign your org. You can, almost always, do some of the following:
- Get your own decision rights in writing, even informally. “Just to confirm, I have authority on X up to Y. Anything beyond that, I’ll bring to you.” Send it as a Slack message. Save it.
- Cap your own priorities at three. Even if your boss has given you ten. You can only do three well, anyway.
- Pick one recurring meeting you can decline. Decline it.
- Have one honest conversation per week with someone outside your company who understands your role. Not advice. Witness. Burnout that is named is half its weight.
- Notice when you’re doing emotional labor that nobody asked for and nobody will reward. Stop doing some of it.
These are small. They are not transformative. They are also, in my experience, the difference between burning out in six months and lasting long enough to either change your situation or change your circumstances.
Third, accept that some roles, as currently structured, are not survivable, and leaving is sometimes the correct fix. I am suspicious of every burnout post that ends with “and so I quit and started a substack.” I’m equally suspicious of the ones that pretend you can yoga your way out of an unsurvivable role. Both are dishonest. The truth is that some roles, in some orgs, at some moments, are designed in a way that no amount of personal practice will redeem. If you have named the problem, asked for the redesign, and watched the org choose not to redesign, leaving is not failure. It’s accurate.
That said, leaving should be a clear-eyed decision, not a panic move. The job after this one will have one of the five faces too. Pick the one whose shape you can actually carry.
A final note
I started this post with the staff engineer who told me her burnout felt different this time. I want to come back to her, because I think the most important thing I told her in that conversation is the thing I want you to take away.
I told her: the burnout you have right now is not the burnout you’ve been trained to recognize. The version you have is real. It has a name. It has a shape. The fact that it doesn’t look like the kind of exhaustion you’ve been taught to spot doesn’t mean you’re imagining it. It means the map you were handed was incomplete.
Engineering as an industry has gotten reasonably good at noticing the early-career version of burnout. We’ve learned to talk about workload, hours, on-call rotation. We are getting better, slowly, at talking about the EM version. We are barely beginning to talk about the Staff version, the director version, the VP version. We have almost no public vocabulary for moral injury at the executive layer.
The five faces are all real. They are all happening at your company right now. They are all under-named, under-treated, and routinely misdiagnosed.
If you are in any kind of leadership role in an engineering org, the most useful thing you can do is learn to tell the five apart in yourself first, then in the people you’re responsible for. The fix that maps to the wrong burnout is the fix that doesn’t help. The fix that maps to the right one, even when it’s small, is the fix that buys you years.
The work is not to be more resilient. The work is to be more accurate.