Why the hero on your project is dangerous

by Curt 13. February 2010 07:04

The ‘hero’ is that one person who swoops in and saves your project from imminent doom.  They have these unique super powers that make them such a critical person.


Critical production bug…  BAM!  FIXED!
Slow server response time….WHAM!  SPEEDY!
Obscure technical question…  POW! ANSWERED!


Why heroes are a threat


As much as the hero is reveled in your organization, few realize the risk they pose.  Yea, they get things done that other staff would struggle with.  But often times they perform their marvel and rarely communicate or document the solution. 

Why should they?...  Most heroes have this amazing capacity of knowledge and instant recall of information.  …and why do we care anyway?...  The hero has averted our disaster and they’re busy saving other citizens.  We shouldn’t burden them with such tedious knowledge transfer tasks.


The hero could be gone tomorrow


As the rescue missions continue, the hero’s name eventually gets out both internally and externally.  This could lead to the hero getting sucked off on to another project.  Worse yet, their unique powers make them more apt to find a job.  They’ll likely be sought by your competitors and generally have opportunities that don’t include working for you.


Protect your project


You’ve got to minimize the risk of losing the ‘hero’ by getting them to share some of their greatness.    Have them mentor other team members, but without making it so formal by calling it ‘mentoring’.  Do this, by getting the hero to perform code reviews or do some limited pair programming.

In addition to mentoring, the next time the hero pulls you out of a crisis get them to document their solution.  You’ll no doubt get resistance for this, but just have them jot a few bullets down on how they alleviated the problem.  A corporate or project Wiki is great for this kind of stuff.


Is there a bigger problem?


As you try to minimize the risk of the hero disappearing, also consider that your reliance may point to a bigger problem.  If you’re constantly forced to deal with crises then you should take a good look at your team, your process, and how you deal with change.


  • Is the team heavily weighted with junior staff?  If so then start training existing staff or hire more experienced staff to act as a mentor.
  • Are the ‘fires’ really just the project managers inability to say ‘No’?  If so, then develop a more formal change request procedures.
  • Do you have any process?  It doesn’t matter which ‘flavor’ you choose, as long as you can point to some form of repeatable sequence of events that have some planning.


Management | Risks

About Me

I'm a software project manager in the Boston area. More...

    Contact Me
    Knols I've written
   My Linkedin profile