The hero syndrome and how to deal with it

Alex Payne wrote in his blog, in 2010, a post about the hero syndrome. However, even though some people are aware of it, we sometimes face some heroes and they end up harming the development process. Therefore, we are here to expand on what Payne said in his post, and try to convince you that being a hero is not healthy for your body or work.

Definition

Let’s start with the definition of hero. To define it, we use here a part of Payne’s post:

The guy or gal eager and willing to pull all-nighters, work weekends, and take over on-call duty when nobody else wants to.

So, what is the problem with heroes? We divide it here health-wise and work-wise.

Health

Well, we are not doctors here, but it seems that there is enough information out there on why working too much may harm your body.

The health problem is directly related to some of the hero’s actions: usually he/she sleeps too little and works too much. There are tons of information on the internet and even in academia that show what workaholism and sleep deprivation can do to our bodies. To list some of them, here is a short list:

Besides those, the hero will probably not practice proper physical activities and will likely have a poor nutrition.

And if you are thinking, “oh, I drink coffee… So I can deal with many of the problems that they list”, here is some extra information on coffee overconsumption:

Work

Ok, so you are part of the YOLO people and don’t actually care about your health as long as it is worth it. Well, here is the deal: you are actually harming your project/product/work by acting as a hero.

First of all, usually heroes are not needed if you plan your project correctly. I mean, no one, while planning a project, accounts for a programmer working 12 hours per day. So, what happens is that you probably didn’t predict well the effort and time needed to complete the project. We have some blogposts talking about metrics and how to predict the completion date of a project:

Secondly, when a team contains a hero, the other teammates may have two different behaviors:

  • They may think that the hero will do all the hard work, so they can stop working as hard as before and just handle the easy tasks.
  • They may start to work overtime to try to get to the same level of workaholism as the hero, so their image is not blurred by the hero’s shine.

Either way, your team will be affected in a bad way. It may seem good at first, since things may get done faster at the beginning, but then your productivity and quality will fall again and your team will be soon overstressed.

Moreover, there are other nonbehavioral consequences that may affect your team:

  • A hero in the team will generate more work to his colleagues. There will be more code to review, more features to test and so on. To put it short: more WIP (Work In Progress).
    • It may reach an unsustainable state of system overload;
    • The non-heroes may be perceived as not-as-committed-as-the-hero, since they are always overwhelmed with work;
  • Depending on the architecture, the “extra code” may impact the existing code or active pull requests.
    • It may demand more work to resolve the conflicts;

In addition, a study from the London School of Economics and Harvard, “Innovation in the collective brain“, talks about the importance of collective work on great innovative ideas. Not even people that are considered “heroes”, like Einstein, Steve Jobs and Darwin, did it alone. A summary of the study can be seen on Inc’s post: The Heroic Inventor Is a Myth: Great Ideas Are Group Efforts.

Handling heroes

First let’s say you already noticed that a person in your team is a hero. What to do about it? Well, the first thing is to talk to the manage, or the person that recognizes effort, and show him/her the problem. Explain how it affects your team and try to encourage the manager to stop rewarding the hero for its workaholism and actually prohibit unnecessary overtime.

Secondly, if you don’t have a hero yet, please do the best you can to forecast a deadline that will be doable and not impossible to reach. Base your decision not only on estimates but also on numbers, simulations and history. If you see you made a mistake on your forecast during the project, redo it and adapt your deadline. Not all deadlines are immutable, so work hard to make sure the team is comfortable with the time they have.

What about you? Are you the hero of your team? Have you ever worked with one? How was it? Leave your comments below!


Download: Forecasting software project through Monte Carlo simulation (FREE spreadsheet)
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Comments are closed.