T-Shaped Engineers Are Out, "Full-Stack Leadership" Is In - What Does That Mean?

I’ve been a senior engineer for 12 years, and I’m going to push back on this framing.

“Full-stack leadership” is a convenient excuse for understaffing.

Let me translate what I hear when companies say they want engineers who “own outcomes end-to-end”:

  • “We don’t want to hire a product manager, so engineers should do that”
  • “We don’t want to hire enough engineers, so each person should do the work of three”
  • “We don’t want to invest in management, so ICs should manage themselves”

The OP acknowledges this is “challenging for those who loved deep specialization.” Let me be more direct: it’s not challenging—it’s exploitative.

Deep specialization still creates massive value.

Know why Google, Meta, and Netflix can build systems that actually scale? Because they have engineers who’ve spent years mastering distributed systems, database internals, or performance optimization.

When everything is AI-generated average-quality code reviewed by overwhelmed “full-stack leaders,” who catches the subtle bug that causes a production meltdown? Who designs the architecture that doesn’t collapse under load?

The burnout math:

“Full-stack leadership” means:

  • Technical decisions + stakeholder communication + mentorship + shipping + architecture + code review

That’s 4-5 roles in one. Even with AI assistance, that’s a recipe for burnout. I’ve seen teams try this. Within 18 months, the best people leave for companies that let them actually focus.

My advice:

If a company says they want “full-stack leaders,” ask: “What’s the team size? What’s the scope? What’s the title and compensation?”

If the answer is “small team, big scope, IC title, IC pay”—run. They want a staff engineer at mid-level cost.