Engineering Growth: Being a Hero Isn't Always Good
Why solving everything yourself is holding you back
There’s a pattern I’ve seen play out in almost every team I’ve worked with. Something breaks, or even worse, something is vague and nobody fully understands the problem yet. And then someone on the team goes quiet. They disappear into the code for a few days, heads down, completely silent. And they come back with a “Fixed it.” PR.
On the surface this looks like initiative. It looks like exactly what a senior or staff engineer should do. Take the hard problem, own it, and deliver the solution. And honestly, the person doing it genuinely believes they are helping. In their mind, the best thing they can do is dive in headfirst, figure it out alone, and come back with a complete answer so the team doesn’t have to struggle with it.
But here’s the thing. The team learned nothing. The context of that problem now lives in one person’s head. Nobody else got closer to understanding the system, the failure mode, or the reasoning behind the fix. And that person just became the default for every scary, ambiguous problem. Not because they built something sustainable, but because they trained everyone around them to wait.
The Hero Fallacy
This is a fallacy that a lot of engineers fall into, especially when they are trying to level up from senior to staff. I fell into this myself. I remember times when I thought the fastest path to demonstrating impact was to take the hardest thing on the table, disappear, and come back with the answer. It felt productive. It felt like accountability.
The fact is, it wasn’t.
Accountability means you own the outcome. It means you care about the problem being solved well and that the team is better for it. Hero mode forces you to focus on the spotlight. You care about being the one who solved it. These two things feel identical from the inside, which is why the fallacy is so common. You can genuinely believe you are being accountable while actually operating in hero mode. The difference only becomes visible when you look at the impact on the people around you.
Being Proactive vs. Being a Hero
Let me be clear. I’m not saying in any way that you should stop taking on hard problems or being proactive.
My favorite quote of all time is by Thomas Jefferson
“I'm a great believer in luck, and I find the harder I work the more I have of it."
Those are great qualities, and every team needs people who see problems early and act on them. The distinction is in how you act.
Being proactive means you identify a problem before it becomes critical, you raise it with the team, and you help create clarity around what’s happening and what needs to happen. You might lead the effort to solve it, but you bring people along. You share context as you go. You make the problem visible and solvable by the team, not just by you. In fact, I wrote about this before:
But hero mode is different. It means you see the problem and you absorb it entirely. You don’t share context because you’re still figuring it out. You don’t bring people in because it feels faster to do it alone. And when you come back with the solution, the team is grateful but also a little more dependent on you and a little less capable of handling the next one.
The proactive engineer makes the team stronger. The hero makes the team more reliant. Both look like leadership from the outside, but only one of them actually is.
Being a Multiplier, Not a Solo Force
The shift from senior to staff (and beyond) is fundamentally about becoming a multiplier. Your value is no longer measured by how much you can personally deliver. It’s measured by how much you enable the people and systems around you to deliver.
Hero mode is the opposite of being a multiplier. It’s being a solo execution force with extra drama. You might ship the fix, but you didn’t debug the org. You didn’t uplift anyone. You didn’t make the system more understandable or the team more capable. You just solved one problem and set yourself up to be the only one who can solve the next one.
The engineers who I’ve seen grow the most at senior and staff plus levels are the ones who resist the urge to disappear and come back with the answer. Instead, they do the harder, slower, less glamorous work of pulling people into the problem, creating shared understanding, and letting the solution emerge from the team. Sometimes that solution is messier. Sometimes it takes longer. But the team is better for it every single time.
There are exceptions, though!
I don’t want to pretend that there’s never a time for it. Production is down, customers are affected, and you need someone to jump in and fix it now. In those moments, hero mode is the right call. You don’t need a collaborative learning experience at 2 AM during an outage.
But those moments should be the exception, not the default. If hero mode is your default operating mode, that’s a sign that something deeper is broken. Either the team doesn’t have the context to engage with hard problems, or you haven’t invested in building that context, or you’re optimizing for personal visibility without realizing it.
The best engineers I know treat those emergency moments as signals. After the fire is out, they go back and ask, Why was I the only one who could fix this? What context was missing? How do we make sure more people can handle this next time? That’s the difference between a hero and a leader.