When looking up “hero” in the dictionary, I found the following definition: “A person, typically a man, who is admired for their courage, outstanding achievements, or noble qualities”. The idea of this post is not to talk about this kind of hero, but about the ones that we can find in almost every software company.
If you have ever worked in a software company, is very likely that you already worked with a “hero”. If that’s the case, you will remember how hard it was to work together. It might happen that you are (or were) a “hero”, but don’t loose hope, this post will try not only to discuss the problem, but also put some light on how to solve it.
A “hero” is someone in the company that is able to do whatever he/she wants, even if that (negatively) affects other teams/people. It might affect only a few people, but it has the potential to be harmful and affect the entire company.
You commonly find a “hero“, as someone that “move fast” and “is the only person that can solve that”. Managers tend to love them, because there is no limit, “heroes” will deliver the new feature/fix doesn’t matter what is needed, in a record-breaking time. They are fast, they are bold, and no one is able to keep up with them.
People find it hard to work in a “hero friendly” culture. It has a toxic effect of forcing others to follow the “hero way”, since it is the only way to be recognized in the company. Sometimes people just give up and leave, once they are not willing to work “the hero way”.
The problems don’t affect only the technological side of the company. Business gets used to get things “fast”. In a “hero culture”, “moving fast” is not a good thing as you might think, it is often the cause of some the problem, which will bite people in the future. It doesn’t mean that a company needs to be slow in order to be good. It means that a company/team needs to find the right rhythm, where quality and speed walk together, and people are aware that quality matters.
Here you will find a few symptoms that help to identify if a company/team has a “hero” and who they are.
A catastrophic problem is found. People start getting nervous and have no idea about what to do. Then the “hero” finds the solution and everyone celebrates. Once again, the company is back on rails.
The “hero” communicates that he/she is going out on vacations. From that moment on, everyone start to get anxious. People start wondering “what if something breaks and he/she is not here?”. It’s not uncommon to make an urgent call to the “hero“, begging for help during the time he/she is out.
The software gets too complicated, developers don’t agree about how to solve issues anymore, teams are unable to push new features, and the business starts to be affected. The only solution that the company finds is to stop everyone and start a huge rewrite, that “will solve all the problems”. If that is not an exception, there is something fishy going on.
Hidden-secrets are specific details that are necessary to get a software/system fully operational, but are not documented or explained. The “hero” is the person that people reach, when they are not able to find the information and get stuck. The only reason the “hero” knows the secret, is because he/she has introduced it him/herself.
Hold on, you might think that the only solution is to fire people that show the “hero” symptoms. Don’t do that! There are some things you can do to improve that.
Make sure everyone in the company understand that is not OK to act as a “hero”, and they won’t be praised. Ensure that “hero” actions will be pointed out and not encouraged. Celebrate high-quality work created by teams, not “quick wins” delivered by individuals.
Hiring is one of the most important aspects of a company, but it is usually overlooked. This post has no intentions on defining “the hiring process”, it is completely out of the scope, but I would like to highlight one simple thing: Let the entire team interview candidates.
The team spends lots of time together, working, talking and thinking. It makes sense to hear the members’ opinions before deciding if a candidate is a good fit for the company/team. Ensure you hear experienced and non-experienced people from the team, and decide after considering their opinion.
Never get into the situation where only a tiny group of people is familiar with the details of your product/system/architecture. Improve the way about how information is shared among people in the company and focus on getting everyone on the same page. Everyone needs to be aware about what to do when things go wrong.
Pair-programming is a great tool to enable knowledge sharing. It can be extremely useful when doing rewrites, big changes, new architecture planning and critical bug fixes. Enable a culture where people enjoy working together and knowledge sharing will be natural.
It’s incredible how a “hero“ is able to proliferate tech debts. It’s important to enable a culture where problems are solved the right way, without shortcuts. It’s common to see 2-years old comments in code like: “It is temporary, need to fix”. If something is hurting the team (or company), solve it right away.
I hope you might find this post helpful. In case you detected the symptoms in your company and would like to know more about how to attack it, feel free to contact me.
You invested thousands of hours learning Rails and how to master its features to build web applications. This book will help you to learn Phoenix, using the knowledge you already have.Get the book