Skip to content

No capes, we shouldn't aim to be heroes

Published: at 10:29 PM

No capes

The glamour of being a hero

We all someday have met that rockstar developer or Hero developer that appears so solve most of the problems it’s faced with. This developer is usually assigned all the hairiest problems of the team and solve them quickly, kinda like a single person S.W.A.T. team. You might look at this person and also think, I want to be this person, be important and become the reference in a way. Being a hero has its glamour, and usually its related to status among the engineering team and usually management team as well.

Not so glamorous side

In the Pheonix Project book - I recommend 1000x times this book, Brent Geller its a known engineer in the IT sector that have a really deep understanding of the system and usually solve the most complex problems of the company. He is known for his efficiency and domain knowledge that makes him a focal point for other business areas when requesting things and getting stuff done with IT. BUT as you can imagine he cannot be the only person to solve all IT problems, so this became a problem because most of the hard problems “had” to go through him. This dependency on Brent caused all critical projects relying on him to become delayed and led to his burnout.

Stop Comparing Your Behind-The-Scenes With Everyone’s Highlight Reel

Heroes and knowledge concentration

When a team has heroes, these individuals often face complex challenges that either require learning or tap into their extensive knowledge. While this approach can quickly solve hard problems, it has a downside. Relying on heroes as the default solution prevents newer team members from encountering and learning from challenging situations. This imbalance can limit the growth and skill development of other team members. So facing a problem, it’s good to try to make room for new people to learn about it or even lead while being supported by a more senior engineer. This will bring more knowledge and also boost the team’s autonomy and confidence.

Personality treats

Heroes in the workplace often emerge not just due to their technical skills, but also because of their personality traits. Outgoing and more verbal individuals tend to be more frequently acknowledged as heroes within a team or organization. Their ability to communicate effectively, articulate their achievements, and engage confidently with others makes them more visible. These individuals are often quick to volunteer for challenging tasks or speak up in meetings, drawing attention to their contributions. This can lead to a wrong perception of value within the team, potentially overshadowing the equally important contributions of more introverted team members who may not be as adept at self-promotion.

Heroes might fall into a state of exhaustion

Being a hero is hard. As mentioned, the hardest problems usually fall to this person, who needs to solve them on time—sometimes juggling more than one at the same time. This can quickly lead to exhaustion or even burnout if not managed well. This way, heroes usually have an expiration date; they need rest or just get tired and start to perform less than usual, which is understandable. It’s important to avoid this at all costs because these same magicians who solve the most complex problems are the most capable of teaching others to do it too!

Having 1 people handling all its bad for the business

So heroes have knowledge, get tired and probably someday will leave, either to another team or another company. Many of us have been in a situation like this:

Eng A: How does this work?

Eng B: I don’t know. We need to check with John. He made it, and only he understands it.

or

Eng A: How does this work?

Eng B: I don’t know. When I joined, the guy who made it had just left, so I have no clue. Maybe let’s rewrite it? 🤔

We often talk about architecture decisions that lead to a single point of failure, but we rarely consider this on the human and team side. We need to make our team fault-tolerant and, most of all, confident to accept new challenges. Tools like documentation, pair programming, andd even just designing together solutions can help a lot with this knowledge silos that can be a big problem to the business in the future.

Conclusion

So, NO CAPES! Trying to be a hero or endorsing heroes in the team might give a sense of productivity and delivery, but the team as a whole is not growing. This is especially important for management and technical leadership to keep in mind in order to create strong, diverse, and effective teams!