SaaS is in a rough stretch. Companies are cutting, consolidating, fighting to keep the lights on. The Saaspocalypse is being felt at varying stages depending on the market. And when organizations are under pressure, something deeply human kicks in: they start hoping for a hero.

Not necessarily a specific person. Just someone — from engineering, from product, from anywhere in the company who steps up, goes on a building spree, finds the killer feature, and helps the company get to the next level — or at least live another day. It’s the miracle play. And it’s understandable, because sometimes the miracle play feels like all you’ve got. Therein lies the trap.

The Old Version

Everyone in tech knows this story. The 10x developer stays up all night, fixes the impossible bug, saves the release, builds a new thing for the client to win the deal. Everyone celebrates. The org even builds a mythology around it. We all know someone who has done this at some point.

Then the inevitable happens. The hero picks a new project, takes a vacation, or worse, burns out or leaves. And then everyone discovers just how much that person was carrying. Nobody else knows how their systems work, what decisions were made and why, or what they were planning next for this wondrous new thing. The organization was standing on fragility the whole time. It just couldn’t tell because the hero was heroing.

The AI-Accelerated Version Is Worse

Hero dependencies have always existed. Organizations have always had people who carry more than they should. AI didn’t create that pattern. It removed the constraints that used to keep it contained. The old hero could overextend on one thing. The new AI-enabled hero can run three or four projects in parallel. They understand the codebase, they know how to prompt effectively, and they’re shipping faster than entire teams used to. One person, moving at the speed of what used to take five. This looks like a superpower. It is, and it’s also multiplied fragility.

Knowledge concentration compounds. The hero built four things. Who else understands how any of them work? With traditional development, knowledge concentration was bad but bounded — one person could only build so much. AI removes that bound.

Things may not get handed off fully or at all, but they just keep running. Not every project ends in a clean handoff. Some things the hero built just … continue. They work. Nobody else touches them. Nobody else understands them enough. They don’t get the love, attention and maintenance that they need to exist properly. They just sit there (accumulating risk) until something breaks and now another hero someone needs to step in and perform CPR.

The hero can’t focus. When you’re carrying four things, you can’t give any of them the attention they need. The hero isn’t just at risk of burning out — they’re at risk of being pulled to hero something else while the thing that actually needs focus goes neglected. The company thinks it has coverage, but it’s just continuing to operate on momentum. Meanwhile, the hero is slowly getting more run down from operating beyond their own cognitive horizon.

The natural speed limit is gone. Manual development used to create a built-in buffer. As systems were written, the rest of the team had time to review, discuss, and build a shared understanding of what was happening.

AI removed that buffer. Now one person can move faster than the organization’s collective processing time. Without that thinking window, nobody else builds a mental map of the system. This doesn’t just matter when things break; it makes the system harder for anyone else to extend.

Now Multiply This Across the Org

One hero is a risk. But one hero is manageable. You can see the dependency and you can plan around it.

The real danger is when you have multiple heroes across multiple products, each one carrying their own expanding surface area of things only they understand. Each hero individually creates one or more of every problem above. Together, they create something exponentially worse: an organization where critical knowledge is fragmented across several people who are all overextended, all building things that, without a proper handover, are effectively unmaintainable. Not because the capability isn’t there, but because everyone else has their own work and no one was brought along for the ride.

And here’s the thing about crisis mode: when a company is fighting to survive, heroes feel essential. Someone stepping up and shipping looks like exactly what you need. So you encourage it. You celebrate it. You get more heroes. Each one saves the day on their front.

But without structure underneath them, you’re not actually surviving. You’re prolonging the inevitable. Every hero adds capability and fragility in roughly equal measure. At some point, the weight of all that unshared knowledge, all those under-maintained systems, all those potential single points of failure, collapses in on itself. The heroes didn’t save the company. They just delayed the reckoning while making it worse.

It’s always been true that you need to survive long enough to win the war. That’s always sitting in the back of everyone’s mind. But if your survival strategy is “more heroes, faster,” you might win every battle and still lose the war.

The Hero Isn’t Who You Think

Here’s what makes this even harder: the new hero isn’t necessarily an engineer.

AI lowers the barrier to entry for technical debt. A product person, an executive, a champion from outside of tech — someone who couldn’t have built anything on their own two years ago — can now spin up tools, prototypes, or workflows. That’s genuinely powerful. I’ve written about finding and empowering those champions because they’re essential to adoption.

But they create the same hero-shaped dependencies. Maybe worse, because they often don’t have the engineering context to recognize what they’re creating in terms of a maintenance burden, integration assumptions, or operational debt. They built a thing that works. They’re (rightfully) proud of it. And now it’s on the leaders to explain, without killing motivation or enthusiasm, that “works” and “is sustainable” are different states of being.

This isn’t their fault. It’s a leadership responsibility. If your organization doesn’t have structure around how things get built, handed off, and maintained, then every empowered builder — engineer or not — is a hero-in-waiting. The problem isn’t that they step up; it’s that our systems don’t let them step back down.

The Leader’s Job

To be clear: there’s nothing wrong with heroics. When someone steps up — stays late, takes on the hard problem, builds the thing nobody else could or did — that’s a signal that they care. They care about the product, their job, the company, the people around them. Whatever it is that they care about, they care. That’s something you want to see and something you want to encourage.

The problem was never the heroes. It’s the cost of the heroics.

Your job as a leader isn’t to stop people from stepping up. It’s to build the right support structure so that stepping up doesn’t mean burning out, hoarding knowledge, or becoming a single point of failure. You want to lower the cost of heroics so that the people who care the most aren’t punished for caring.

There’s an old proverb: “If you want to go fast, go alone. If you want to go far, go together.”

AI lets individuals go very fast. That’s empowering, real, and can be incredibly valuable. But without systems to support those individuals, you’re just creating more people going fast alone — and the organization isn’t going to get far together.

Your job as a leader is to recognize that this new world enables heroes in ways that weren’t possible before, and to build the structure that keeps hero-shaped dependencies from forming in the first place. That means investing in the things that feel like they slow you down: communication cadences that move information without requiring any single person to be present. Handoff processes built into the structure, not bolted on when someone leaves. Knowledge sharing that doesn’t live in one person’s head. Explicit protocols that don’t assume “everyone just knows.”

I’ve written about this at length in Treat Your Organization Like a Distributed System. The full framework is there. But the short version is simply: systems aren’t overhead and shouldn’t be treated as such. They’re the infrastructure that lets everyone move together, not just the heroes.

Yes, this means making people slow down at times. That’s hard to do and even harder when the business is in crisis mode, when speed feels like survival. But slowing down is how handoffs actually work. The only place where both parties are at a full sprint during the exchange is an elite Olympic relay — and that takes a lifetime of practice. In business, slowing down is how someone other than the hero can pick up the thing when the hero is pulled elsewhere. It’s the difference between surviving today and being able to survive tomorrow.

That’s why when I see AI-enabled development creating hero-shaped dependencies, I stop and map the problems so I can reinforce systems around them. Not because systems are fun to build (though I do enjoy it). But because without them, every hero you empower is also fragility that you’re creating.

The Point

Your job as a leader isn’t to be the hero, and it’s not to find one — though both might be necessary at times. It’s to make sure the heroes you have can do their best work without the organization paying for it later.

See where the dependencies are forming. Put structure around them. Lower the cost of heroics so your best people can keep caring without it breaking them or the org.