Brujo has been a programmer since the age of 10 and he has more than 15 years in the industry. He was a VB, .NET, Java and Haskell programmer until he found Erlang 8 years ago. He’s now Inaka's CTO and Erlang Solutions’ Tech Lead and Trainer. He’s an active member of the open-source community and his blog (Erlang Battleground on Medium) was the most active Erlang blog of 2016.
31 January 2017
The Hero Culture
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.
What’s a “hero”
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.
The “hero” is the only person able to solve a problem
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.
“Stop the world” rewrite
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 things clear
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.
Don’t postpone what needs to be solved now
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.
25 Jul 2016
A video exploring the potential of fast simulated...
08 Aug 2016
Gradle did come to stay with us. Although...
22 Aug 2016
Software Testing is not for Attention...
19 Sep 2016
New video from #droidconpl2015 is out!...
19 Sep 2016
Last night I attended a software testing...
21 Oct 2016
A summary of my visit from SystemD Conference...
24 Oct 2016
Up until yesterday, I had only gone...
24 Oct 2016
Updating sources (versions, revisions, tags)...
14 Nov 2016
Elixir is a joy to work with, an easy...
16 Nov 2016
A few weeks ago I attended Mobiconf, one of...
20 Jan 2017
When you can’t bang! This story...
26 Jan 2017
I have been using Ruby/Rails for 8 years and...
07 Feb 2017
I am an old Java man, I never allocated many of...
07 Feb 2017
Earlier today, Dorothy Graham presented...
07 Feb 2017
I have seen great posts about Elixir release...
22 Feb 2017
I first time I came across the term of "dark...
22 Feb 2017
You probably know...
22 Feb 2017
I am quite happy to share that I have...
06 Mar 2017
Who will find this interesting If you’re...
07 Mar 2017
A peer2peer and/or crowdfunding, blockchain...