22% of Engineering Leaders Face Critical Burnout, Yet 43% Say Leadership Is Out of Touch. Is Our Feedback Loop Broken?

General
1

I had a moment last month that stopped me cold. I was prepping for our quarterly all-hands at 11 PM—my third 14-hour day that week—when a direct report’s Slack message popped up: “Hey Keisha, feel like leadership doesn’t really get what we’re dealing with right now. No offense.”

No offense taken. Just a gut punch.

Because here’s the thing: I thought I was drowning for them. Managing up against unrealistic exec expectations. Shielding juniors from layoff anxiety spiraling through the company. Translating “AI will 10x productivity” board mandates into something that doesn’t destroy my team. And somehow, despite all that invisible labor, I’d become the “out of touch” leader.

Turns out, I’m not alone.

The Data Tells a Brutal Story

LeadDev’s 2025 Engineering Leadership Report surveyed 617 engineering leaders and developers. The numbers are stark:

  • 22% of engineering leaders face critical levels of burnout
  • 43% of developers say leadership is out of touch with team challenges

Think about that gap. One in five leaders is burning out, yet nearly half of their teams think leadership doesn’t understand their reality. We’re drowning in separate oceans.

The Invisible Overtime

The Engineering Management Institute research names what we all feel but rarely discuss: the emotional labor of engineering leadership.

This work doesn’t show up in our calendars:

  • Calming anxious reports after the third “efficiency review” email from HR
  • Protecting junior engineers from scope creep disguised as “stretch goals”
  • Managing up when execs see Copilot adoption and assume 40% more capacity
  • Absorbing the fear and uncertainty so your team can focus on building
  • Playing therapist, career coach, and organizational translator—often simultaneously

According to recent research, managers are now working 12-15 hour days post-AI adoption. Not because we’re shipping more features. Because leadership expects us to explain why AI hasn’t made engineering headcount obsolete.

Why Our Feedback Loops Are Failing

I’ve been reflecting on why my team felt I was out of touch despite me thinking I was hyper-connected. Here’s what I’ve learned:

One-on-ones became status updates. “How’s the auth refactor going?” replaced “What’s making work harder than it needs to be?”

Upward feedback feels unsafe. Multiple team members told me later they didn’t want to “burden me” or “seem like complainers.” Translation: they didn’t trust that speaking up wouldn’t have consequences.

I was too busy to notice the signals. Back-to-back meetings meant I missed the Slack threads, the increasing sarcasm, the longer response times.

Remote work removed the hallway check-ins. I used to see exhaustion on faces. Now I see status: :green_circle: Active.

The AI Amplification Effect

This has gotten worse with AI tooling. Per a 2025 analysis, leadership is inflating sprint expectations by 30-40% after adopting tools like GitHub Copilot.

The logic chain goes:

  1. Company invests in AI coding tools
  2. Exec reads vendor claims: “55% faster coding!”
  3. Leadership assumes 55% more features per sprint
  4. Engineers spend 55% more time debugging AI suggestions
  5. Burnout accelerates, trust erodes, feedback stops flowing

Nobody wins.

What I’m Changing

I don’t have this solved. But here’s what I’m trying:

Skip-level “listening tours” instead of skip-level “check-ins.” No laptops, no notes, no agenda. Just: “Tell me what I’m missing.”

Public transparency about the battles I’m fighting upward. In team all-hands: “Here’s what execs asked for, here’s the data I showed them on why that’s unrealistic, here’s what we negotiated instead.”

Admitting when I’m wrong. Last month I estimated a feature at 2 weeks based on “AI will help.” Took 5 weeks. I apologized in our retro and asked what I missed. The conversation that followed was the most honest feedback I’d gotten in months.

Forcing space for real feedback. Monthly “what are we not talking about” sessions. Anonymous pulse surveys. Training myself to receive feedback, not just give it.

Questions for This Community

I’d love to hear from folks at all levels:

For fellow leaders: What early warning signs of burnout have you noticed in yourself? How do you create feedback loops that surface real challenges before they become crises?

For ICs and managers: What would make you trust leadership enough to give honest upward feedback? What’s one thing your leader could do tomorrow to show they “get it”?

For everyone: Are we systemically bad at this in tech? Or is there something about the current environment—AI hype, layoff anxiety, remote work—that’s breaking feedback loops that used to work?

Because 22% burnout and 43% disconnect isn’t sustainable. We’re building software that requires tight feedback loops while running organizations where feedback barely flows.

That seems… ironic. And fixable.

What am I missing?

2

Keisha, this hits way too close to home. I’m living both sides of this right now—burnt out as a director AND my team probably thinks I’m out of touch. The squeeze is real.

Three months ago, our C-suite came back from a conference all jazzed about AI productivity gains. Within a week, I got this email: “GitHub Copilot is live for all engineers. Expect 40% faster delivery starting next sprint.”

40%. Just like that.

I pushed back with actual data. Our pilot showed:

  • 8% productivity improvement on greenfield features
  • 23% increase in debugging time from AI-generated edge cases
  • Zero improvement on legacy code integration (our reality 70% of the time)

The response? “That’s because engineers aren’t using it right. Run more training.”

The Middle Manager Bottleneck

Here’s what I’m realizing: middle managers become the organizational bottleneck when we’re the only ones fighting reality.

When I shield my team from unrealistic demands, I’m protecting them. But I’m also hiding the truth from execs who need to see it. When I translate exec pressure into “reasonable” goals, I’m enabling the disconnect between what leadership thinks is possible and what’s actually happening.

My skip-level 1:1s revealed something painful: my team doesn’t trust me to push back effectively on executive demands. They think I’m just a messenger passing down mandates. Even when I’m in those rooms fighting like hell.

What’s Actually Working

I started two things that are helping:

Office Hours (No Agenda Required): Every Tuesday/Thursday, 2 hours blocked for anyone to book 15 minutes. No topics off-limits. No “is this worth escalating” filter. Just: what’s broken?

First week, one person showed up. Fourth week, I had a waitlist.

Transparency Reports: Monthly all-hands slide: “Battles I’m Fighting Upward.” Literally shows:

  • What execs asked for
  • The data I showed them
  • What we negotiated
  • What I lost on

Example: “CFO asked why headcount isn’t shrinking post-AI. Showed retention cost of layoffs + ramp time for new hires. Negotiated: hiring freeze instead of cuts, revisit in Q3 with productivity metrics.”

When the team sees you lose battles for them, trust changes.

The Question I’m Wrestling With

How do other engineering directors balance being a shield (protecting team from chaos) vs a mirror (reflecting reality upward)?

Because if I’m too much of a shield, leadership never sees the real costs. If I’m too much of a mirror, my team drowns in organizational dysfunction.

I don’t have this figured out. But Keisha’s right—we can’t keep burning out in separate oceans while pretending everything’s working.

3

From the team side, the disconnect feels very real. And reading Keisha and Luis’s posts, I’m realizing we’re all seeing different parts of the same broken system.

Here’s what it looks like from my seat as a senior IC:

My engineering manager pulled me into 1:1 last month. “This auth refactor should take 2 days now with Copilot, right?”

It took 5 days. Here’s why:

  • 3 hours context-gathering because AI doesn’t know our legacy auth patterns
  • 6 hours prompting and iterating to get “almost right” code
  • 8 hours debugging edge cases the AI missed (like our custom JWT refresh flow)
  • 2 hours documenting why AI suggestions won’t work for future maintainers

When I explained this in the retro, my manager said: “Well, you need to get better at prompting.”

The Trust Erosion Cycle

Here’s what happens when leadership doesn’t acknowledge the gap between AI promise and reality:

  1. Leader estimates based on vendor marketing (55% faster!)
  2. IC gives realistic estimate based on actual work
  3. Leader pushes back: “Are you even trying to use the AI tools?”
  4. IC stops giving honest estimates, just says “sure, 2 days”
  5. IC works nights/weekends to hit the unrealistic deadline
  6. Leader thinks AI is working, sets next estimate even more aggressively
  7. Burnout + resentment + broken feedback loop

We’re in step 6 right now.

What Would Actually Help

I have some empathy here. Luis, I didn’t know you were fighting those battles. Keisha, I had no idea you were working 14-hour days too.

But from the team perspective, here’s what would rebuild trust:

Code alongside us occasionally. Even just bug fixes or tech debt tickets. When my last manager spent Friday afternoons pairing on refactoring work, she stopped making impossible estimates. She felt the AI debugging tax.

Ask “what’s slowing you down?” instead of “why isn’t this done yet?” One question assumes we’re trying our best. The other assumes we’re the problem.

Admit when you’re wrong about timelines. Keisha’s retro apology? That was the first time in 8 months a leader acknowledged the gap between what they thought AI would do and what it actually does. It changed everything.

The Drowning Separately Problem

Luis said: “We can’t keep burning out in separate oceans.” That hit hard.

I get that Keisha and Luis are drowning too. I really do. But when you’re drowning separately—leadership in unrealistic exec demands, ICs in impossible timelines—nobody gets saved.

What if we were drowning together? What if when the C-suite says “40% faster delivery,” the response is:

“Our team measured 8% improvement in specific scenarios. Here’s the data. Here’s what engineers are actually experiencing. If you want 40% faster, here’s what that would require (spoiler: not AI training, maybe hiring or scope cuts).”

And ICs are in the room when that conversation happens. Or at least see the transparency reports Luis is doing.

Because right now, it feels like leadership is trying to protect us from reality. But we’re living in that reality every day. We don’t need protection. We need partnership.

4

This same feedback breakdown killed my startup.

I was the founder. I was “in the weeds” every day. I thought I knew exactly what was happening. And I completely missed the signals that our product wasn’t working until we’d burned through 18 months of runway.

Reading this thread, I’m seeing the exact same pattern that destroyed my company:

Leadership burnout → tunnel vision → missing critical feedback → worse decisions → more burnout

It’s a death spiral. And it doesn’t matter if you’re a VP at an EdTech company or a founder bootstrapping a SaaS tool. The pattern is identical.

What I Learned (The Hard Way)

My team was afraid to tell me the product wasn’t solving the problem. Not because I was a jerk. Because I was drowning.

Every 1:1 became a status update because I was too exhausted to ask deeper questions. Every concern raised felt like another thing to fix when I was already working 16-hour days.

So my team stopped raising concerns.

By the time I realized customers were churning because of fundamental UX issues—issues my designers had flagged 6 months earlier—it was too late.

Three Things That Would’ve Saved Us

1. Forced Feedback Rituals

Monthly “what are we not talking about” sessions with psychological safety guarantees. No laptops, no notes, results don’t leave the room unless the team agrees.

We implemented this in month 14 (way too late). First session, someone said: “Maya, you asked us to design for small business owners, but you keep optimizing for enterprise features because that’s where the money is. Which strategy are we actually executing?”

Gut punch. But necessary.

2. Anonymous Pulse Checks

Weekly 3-question survey:

  • What’s working?
  • What’s broken?
  • What are we avoiding?

Results shared publicly in Friday all-hands. No attribution.

The things people will say anonymously that they won’t say in person—that’s where the truth lives.

3. Feedback Training for Leaders

Everyone talks about “feedback culture” like it’s about getting ICs to give better feedback upward. That’s backwards.

Leaders need training on how to RECEIVE feedback, not just give it.

Can you sit with criticism without getting defensive? Can you ask “tell me more” when someone says your strategy is failing? Can you thank someone for hard feedback even when it hurts?

I couldn’t. Not at first. It took a coach and a lot of practice.

The Cross-Functional Blind Spot

Here’s something I’m not seeing in this thread yet: cross-functional feedback gaps.

In my experience, design teams see product problems before eng/product leadership. Customer success sees adoption issues before growth teams. Sales sees competitive weaknesses before marketing.

But feedback flows vertically (up the reporting chain), not horizontally (across functions).

Keisha, are your design and product peers seeing things you’re missing? Luis, is customer success flagging issues that never make it to your roadmap discussions?

Because if engineering leadership is out of touch with engineering teams… imagine the gap between engineering and the rest of the company.

The Meta-Problem

We obsess over feedback loops in code (CI/CD), product development (user research, A/B tests), and marketing (analytics, conversion funnels).

But feedback loops for leadership effectiveness? Crickets.

Alex is right: we don’t need protection from reality. We need partnership in facing it.

And that means building the same rigorous feedback systems for organizational health that we build for code quality.

5

Reading this thread as a product leader, I’m realizing we (product/business) are often the source of the pressure that creates this burnout cycle. Let me explain.

The Pressure Starts at the Board Level

Here’s the chain reaction I’ve witnessed:

Board: “AI is a 10x productivity multiplier. Show me 10x results or explain why we’re investing in these tools.”

C-Suite: “We’re spending $200K/year on GitHub Copilot and Cursor. Engineering needs to deliver proportional value. That means more features, same headcount.”

Directors (like Luis): “Sprint commitments need to increase 30-40% to justify the AI investment.”

ICs (like Alex): Working nights and weekends to hit unrealistic deadlines while leadership says “you’re not using AI effectively enough.”

Result: 22% of leaders burnt out, 43% disconnect, eroding trust, broken feedback loops.

Everyone in this chain thinks they’re being reasonable. But each step amplifies the dysfunction.

The CFO Question

Two quarters ago, our CFO pulled me and our VPE into a meeting: “We’ve invested heavily in AI tooling. When does engineering headcount start decreasing?”

Not “when do we see productivity gains.”

When does headcount decrease.

That’s the quiet part said out loud. Leadership sees AI as a people replacement strategy, not a productivity enhancement. And when engineers don’t magically become redundant, the conclusion is: “They’re not adopting it fast enough.”

Product’s Role in the Dysfunction

I’ll be honest: PM roadmaps make this worse.

We present quarterly plans with aggressive timelines. Engineering pushes back. We say “well, Copilot should help, right?” Engineering feels pressure to say yes even when the answer is no.

Then when delivery slips, we point to “engineering estimates were off” rather than “our roadmap assumed AI magic that doesn’t exist.”

We make engineering leaders the “bad guy” who has to say no. And when they say yes to protect their teams or their credibility, we set them up for burnout.

What Actually Changed the Dynamic

Six months ago, I started including our VPE in quarterly board prep. Not just to present metrics—to co-author the narrative.

When the board asked about AI productivity, our VPE showed:

  • Technical debt tax: 30% of sprint capacity consumed by legacy system maintenance
  • AI debugging overhead: 15-20% time increase on AI-generated code for complex features
  • Ramp time reality: New engineers take 3-4 months to be productive regardless of AI tooling

The board’s response? They reset expectations.

Instead of “why isn’t AI reducing headcount,” the question became: “what investment in technical debt reduction would unlock more value from AI tools?”

The narrative shifted from replacement to enablement.

The Business Case for Sustainable Pace

Maya’s right: we obsess over feedback loops for code and product, but not organizational health.

Here’s the business case for fixing this:

Burnout has measurable costs:

  • Attrition of senior engineers (recruiting + ramp time = $200K-500K per departure)
  • Degraded decision quality (burnt-out leaders make reactive, not strategic choices)
  • Loss of institutional knowledge (when experienced people leave or disengage)
  • Reduced innovation (survival mode kills experimentation)

Better feedback loops have measurable benefits:

  • Earlier detection of delivery risk
  • More accurate roadmap commitments
  • Reduced thrash from late-stage scope changes
  • Improved team retention and engagement

When I frame it this way to our CEO, it’s not “be nice to engineering.” It’s “protect company value by optimizing for long-term output, not short-term optics.”

Questions for This Community

For engineering leaders: What metrics would help product/business understand the real cost of unrealistic expectations? DORA metrics? Burnout surveys? Velocity trends?

For product folks: How do you create roadmaps that assume realistic AI impact without looking like you’re “not innovating fast enough” to leadership?

For everyone: How do we make the business case that sustainable pace is a competitive advantage, not a luxury? What evidence would move your board/execs?

Because Alex is right: we need partnership, not protection.

And that means product, engineering, and business leadership building feedback loops together instead of each function optimizing locally and burning out separately.