83% of Engineers Report Burnout in High-Growth Environments. AI Didn't Fix It—It Made Cognitive Load the New Killer

[vp_eng_keisha]

I’ve been sitting with some uncomfortable data, and I need to process it with people who actually manage engineering teams at scale.

83% of engineers in high-growth environments report burnout. Not the “I need a vacation” kind. The kind where your highest performers quietly start updating their LinkedIn, where your staff engineers disengage in architecture reviews, where your best people are physically present but cognitively gone.

And here’s what keeps me up at night: AI was supposed to fix this.

The Promise vs. The Reality

When we rolled out AI coding assistants across our 80-person engineering org last year, the pitch was elegant: automate the toil, free up cognitive bandwidth, let engineers focus on the creative work that brought them to software in the first place.

Six months in, here’s what actually happened:

• Task throughput increased ~26% — engineers completed work faster
• Defect rates climbed — more code shipped, less of it was deeply understood
• Context-switching exploded — AI made it easy to jump between problems, so people jumped between more problems
• “High-functioning burnout” became our invisible epidemic — people who look productive but are operating on depleted cognitive reserves

A developer on my team described it perfectly: “I used to be tired from writing code. Now I’m tired from reading, verifying, and deciding about code I didn’t write. The fatigue is different—it’s less physical and more… buzzing.”

Cognitive Load Is the New Killer

The research backs this up. Harvard Business Review named it “AI Brain Fry”—mental fatigue from excessive oversight of AI output. 96% of heavy AI tool users work evenings and weekends. They’re not doing more work. They’re doing different work, and it’s the kind that drains you without the satisfaction of having built something.

What I’m seeing in my org maps almost perfectly to what David Vass called “high-functioning burnout”—the idea that execution effort decreased, but was replaced by interpretation, verification, and decision-making effort. AI output is rarely obviously wrong. It’s partially correct but subtly misaligned, which means your brain has to do the hardest type of cognitive work: detecting what’s almost right.

The Organizational Amplifiers

But the burnout isn’t just about AI. It’s about what organizations did with the productivity gains:

1. Every minute saved became a minute available for more work. We treated AI productivity as additive capacity, not as an opportunity to reduce cognitive strain.

2. Manager span of control expanded. The average engineering manager now handles 12.1 direct reports, up from 10.9 in 2024. Research suggests optimal is 5-10. We’re moving in the wrong direction.

3. Tool sprawl compounded the problem. Product Hunt lists 30+ new AI tools daily. 5-10 are theoretically relevant to any developer’s workflow. The counter-trend is real: developers are fatigued by constant tool churn, and the tools winning are the ones that are stable and don’t change their API every two weeks.

4. Knowledge concentration increased. In 65% of codebases analyzed, only 1-2 people held critical knowledge about key systems. Bus factor of 1. AI accelerated delivery but didn’t distribute understanding.

What I’m Trying

I won’t pretend I have answers, but here’s what I’m experimenting with:

• “Cognitive load budgets” — we’re piloting explicit limits on the number of distinct problem domains an engineer works on per sprint. Not story points, not velocity—cognitive contexts.
• AI-free focus blocks — 4 hours per week where engineers work without AI assistance, forcing deeper engagement with code.
• Verification rotation — instead of the code author reviewing AI output, we rotate verification to build shared understanding (and distribute the cognitive load).
• Outcome metrics over throughput metrics — I stopped celebrating how many PRs we merge. We now track escaped defects, engineer satisfaction, and knowledge distribution.

The Question I Can’t Answer Alone

Here’s what I keep coming back to: Are we designing work for human sustainability, or are we optimizing machine throughput and hoping humans can keep pace?

The 83% burnout stat tells me we’re doing the latter. But most organizations don’t even realize it because the burnout is high-functioning—people are still shipping, still meeting sprint commitments, still saying they’re fine in 1:1s.

How are you thinking about this? Are your teams showing similar patterns? And honestly—is anyone actually succeeding at reducing cognitive load rather than just redistributing it?

I’d especially love to hear from other VPs and directors who are seeing this at the org level, not just the individual level. This feels like it needs a structural response, not just wellness programs and meditation app subscriptions.

[eng_director_luis]

Keisha, the span of control data you cited hit home. I’m living it.

I run a 40+ person engineering org in financial services. When we adopted AI tooling last year, leadership saw throughput improvements and immediately started asking: “If each engineer is 26% more productive, can we absorb the next quarter’s roadmap without hiring?”

The answer was technically yes. The cost was invisible.

The Manager Bottleneck Nobody Talks About

My EMs went from 8 direct reports to 11-12 almost overnight—not because we planned it, but because the headcount freeze meant natural attrition wasn’t backfilled and “AI makes everyone more productive anyway.” What I watched happen:

• 1:1s became status updates instead of coaching conversations. No time for career development when you’re triaging 12 people’s blockers.
• Managers stopped doing skip-levels entirely. They barely had time for their directs.
• Performance review quality tanked. How do you write a meaningful review for 12 people when you haven’t had a real developmental conversation with half of them in months?

The irony is that AI tooling made individual contributors more productive while simultaneously making management less effective. We optimized one layer and broke the layer above it.

What the Data Told Us

We started tracking what I call “cognitive load indicators”—not formal surveys, but proxy signals:

Signal	Pre-AI Tooling	6 Months Post	What It Means
Avg PRs per engineer/week	3.2	4.8	More output
Avg review turnaround (hrs)	6	14	Review bottleneck
Oncall escalations	8/month	19/month	Quality decline
Internal transfer requests	2/quarter	7/quarter	People leaving teams
Manager 1:1 cancellation rate	12%	34%	Manager overload

The transfer requests were the canary in the coal mine. People weren’t quitting the company—they were quitting their context. They wanted to work on fewer things, with more depth, on teams where the manager had time to actually manage.

The Structural Fix I’m Piloting

I’m reorganizing around what I call “cognitive team size”—the number of distinct systems a team owns, not the number of people on it. We had a team of 6 that owned 4 microservices, 2 data pipelines, and an integration layer. On paper, reasonable staffing. In reality, every engineer was context-switching across 7 distinct systems daily.

We’re splitting that into two teams of 4 (yes, hiring 2), each owning a coherent domain. It’s more expensive in headcount. It’s cheaper in escaped defects, attrition, and manager effectiveness.

Your “cognitive load budgets” idea resonates. I’d push it further—it’s not just about limiting the number of problems per sprint, it’s about limiting the number of distinct systems an engineer has to hold in their head. That’s the real cognitive tax.

[maya_builds]

I want to push back on something—gently, but firmly.

This thread is framing burnout as an engineering management problem. And it is. But it’s also a design problem, and nobody in leadership is treating it that way.

We Designed the Tools. We Didn’t Design the Workflow.

I lead design systems, which means I spend my days thinking about how humans interact with complex interfaces. And what I see happening with AI-assisted development is a textbook example of what we’d call a usability failure in any other context:

• The tools reduce the effort of producing artifacts
• But they dramatically increase the effort of evaluating artifacts
• And nobody redesigned the workflow to account for the shift

It’s like we gave everyone a photocopier and then wondered why the office was drowning in paper. The bottleneck moved from production to curation, and the workspace didn’t adapt.

The “Buzzing” Is Decision Fatigue

That developer quote about feeling “buzzing”—I’ve heard nearly identical language from designers doing AI-assisted work. It’s decision fatigue. Not the big decisions. The micro-decisions.

When you write code yourself, you make thousands of tiny decisions as you go—variable names, error handling approaches, abstraction levels. Those decisions are cognitively embedded in the act of creation. You don’t even notice them as decisions.

When AI writes the code, all those decisions become review decisions. You have to consciously evaluate each one. “Is this the right abstraction? Would I have named this differently? Is this error handling sufficient?” Each micro-decision that was previously automatic now requires conscious attention.

That’s the real mechanism behind the burnout: AI turned implicit decisions into explicit ones, and the human brain has a finite budget for explicit decision-making.

What I’d Add to Keisha’s Experiments

Your cognitive load budget idea is strong, but I’d add a design thinking layer:

1. Audit the decision points, not just the tasks. Map every point in your workflow where a human has to make a judgment call about AI output. I bet it’s 3-5x more decision points than the pre-AI workflow had, even though the tasks look similar.

2. Design “decision-free zones.” Your AI-free focus blocks are close to this, but I’d reframe them. The goal isn’t to avoid AI—it’s to have blocks where the type of cognitive work is creation rather than evaluation. Some engineers might actually use AI productively during these blocks if the AI is doing the evaluation and they’re doing the creation.

3. Make the invisible visible. One thing that kills people about cognitive load is that it’s invisible. Nobody can see that you’re exhausted from making 400 micro-decisions about AI-generated code. Build rituals that make it visible—end-of-day cognitive load check-ins, weekly “what drained me most” reflections. Not as therapy, but as data for workflow design.

The organizations that figure this out won’t be the ones with the best AI tools. They’ll be the ones that redesigned human workflows around AI’s actual cognitive impact, not AI’s theoretical productivity gains.

[cto_michelle]

I’ve been reading this thread twice, because the first time through I realized I was part of the problem Keisha is describing.

Let me be direct: as a CTO, I’ve been in the room where we made exactly the decisions that led to this. I’ve sat in board meetings where AI productivity metrics were presented as evidence that we could do more with less. I’ve approved headcount freezes partially justified by AI efficiency gains. And I’m now watching the downstream effects play out across my 120-person org.

The Board Narrative vs. The Engineering Reality

Here’s the uncomfortable truth about why this keeps happening: the incentive structure rewards it.

When I present to the board, they want to hear about efficiency gains. “Our engineers ship 26% more features per quarter” is a story that raises your next round. “We’ve reduced cognitive strain on our engineers” is a story that gets you asked why you’re not pushing harder.

I’m not excusing it. I’m naming it. Until we can translate cognitive load reduction into business metrics that boards care about—retention savings, defect cost avoidance, incident resolution time—this will remain an engineering-internal conversation that leadership nods at and then ignores.

What I Got Wrong

I’ll share a specific mistake. When we rolled out AI tooling, I set a company-wide goal: “Reduce time-to-deployment by 30% in Q3.” We hit it. The VP of Engineering (someone with Keisha’s role at our company) came to me two months later with escalating attrition data and said the team was burning out.

My initial reaction was: “But we hit the deployment target.” That reaction—optimizing for the metric instead of the system—is the core failure mode.

What I should have set was a balanced goal: “Reduce time-to-deployment by 30% while maintaining engineer satisfaction scores and keeping escaped defect rate flat.” The constraints matter as much as the objective.

The Structural Response That’s Actually Working

Luis’s point about cognitive team size is exactly right. But I’d add the layer above it: you need executive-level ownership of cognitive load as a first-class organizational metric.

At our company, I’ve now made three changes:

1. Cognitive load is on the engineering dashboard. We measure it through proxy signals (similar to Luis’s table) and I review it monthly with the same rigor I review uptime and deployment frequency. When the indicators trend red, we treat it like a production incident—it gets an owner, a timeline, and an executive review.

2. AI tool consolidation, not proliferation. We went from 7 AI tools across the engineering org to 3. The consolidation wasn’t popular initially, but the reduction in tool-switching overhead was immediate. Maya’s point about decision fatigue applies to tool selection too—every new tool is a new set of micro-decisions about when to use it, how to interpret its output, whether to trust its suggestions.

3. Mandatory buffer in capacity planning. We now plan at 75% capacity instead of 90%. The 15% buffer isn’t slack—it’s cognitive recovery space. Engineers use it for learning, documentation, refactoring, or simply working at a sustainable pace. It’s expensive in the short term. It’s the cheapest retention investment we’ve ever made.

The Real Question

Keisha asked whether we’re designing for human sustainability or machine throughput. I think the honest answer for most organizations is: we’re designing for investor narratives, and human sustainability is a nice-to-have that gets deprioritized every quarter.

Changing that requires CTOs and VPs who are willing to have uncomfortable conversations with their boards about the true cost of AI-driven productivity. The 83% burnout rate isn’t a people problem. It’s a strategy problem.