Leadership & Management Execution & Scaling

The Hero Pattern: How Rewarding the Person Who "Holds It Together" Creates Leadership Debt

The people who look like the strongest leaders during a crisis are often quietly compensating for the exact problem they’re being praised for solving. That’s the hero pattern, and it’s one of the most common ways leadership debt forms inside engineering organizations.

What the Hero Pattern Looks Like

Overfunctioning Engineering Managers are usually the ones getting praised. They jump into code when things get tight. They absorb pressure from above and below. They make fast decisions to keep delivery moving, and they stay late to “just handle it.” From the outside, that looks like leadership. Inside the system, it’s fragility, because every time a manager compensates for unclear priorities or a real capacity gap, the organization learns the wrong lesson. It learns that the system works, when really the manager is the one adapting while the system stays exactly the same.

I’ve seen this play out directly, including on a team where nearly half my engineers were repeatedly pulled into “higher priority” initiatives elsewhere. The roadmap never shrank to match, so I stepped in myself, taking on more system design, documentation and coordination just to keep delivery steady. For a while it worked, and from the outside nothing looked broken. That’s the trap. It looked like leadership. It was actually how leadership debt forms.

My Own Experience Being Rewarded for It

Earlier in my management career, I fell directly into this pattern while leading a major project with a lot of visibility at one company I worked for. Things kept getting stuck, so I stepped in everywhere, working long hours for months to help push the work forward, because I believed that was what good managers did. From the outside, it looked like success. The project kept moving, leadership noticed, and I received praise, a bonus and a raise.

That part felt good. But by then I was already seeing the downside. The system had quietly become dependent on me stepping in to keep things moving, and the more I helped, the less it learned how to operate without that pressure being absorbed somewhere. That experience is what first pushed me to ask a different question: how do you lead without becoming the hero or the blocker?

I Watched the Same Pattern From the Other Side

Later in my career, I saw the same pattern repeat at another company I worked for, where the CTO would frequently call out the people who “saved the day” during difficult stretches. Those people worked incredibly hard. They jumped into every problem, put in long hours and kept things moving when things got chaotic. But the system wasn’t improving underneath them. Instead of spreading knowledge and strengthening the teams around them, the hero pattern kept repeating, and the organization kept rewarding the people holding the system together instead of asking why the system needed to be held together in the first place.

Why This Counts as Debt, Not Resilience

Most Engineering Managers caught in this pattern aren’t underperforming. They’re overcompensating, and the signs are consistent once you know what to look for. The same person gets pulled into every escalation. Roadmaps never actually shrink, they just get absorbed. Managers retreat into code whenever ambiguity spikes. Directors struggle to articulate what “good” actually looks like beyond pointing at whoever is currently holding things together. High performers burn out while being praised the entire way there.

That’s not resilience. That’s concentration risk, and it doesn’t resolve on its own. It just keeps compounding until the person holding it together burns out, leaves or finally gets pulled onto something else, and the stability everyone assumed was structural turns out to have been personal the whole time.

What Changes When the Role Is Made Explicit

When leadership infrastructure becomes explicit instead of implicit, the pattern actually changes. Escalations decrease because decision rights are clear enough that teams don’t need to route everything upward. Capacity tradeoffs get negotiated instead of quietly absorbed. Managers stop proving themselves through visible output and start designing leverage instead, and initiative increases because ownership is distributed rather than concentrated in whoever is willing to carry the most. Directors can finally articulate leadership standards without pointing at an individual as the example.

The difference isn’t personality. It’s structure, and that’s exactly what the Engineering Manager Mentorship Program is built to install. It defines what the role is accountable for, clarifies where leverage actually comes from and aligns expectations across levels so managers stop needing to be heroes to be seen as effective. If you recognize this pattern in your own organization, or in yourself, Engineering Manager Mentorship is built around replacing it with something that scales.