False Heroes and Heroes Revisted

In late March, Twitter was alive with a collection of the Thinking Testers debating the "no heroes" theme which bubbles up from time to time.  I suspect that if you follow a collection of people on Twitter or by reading their blogs, you may have seen some of this.

You may have seen some aspect of the "no more heroes" discussion.  This is the argument that a frighteningly large number of people, many of them manager types, reward "heroes" who "save" a project - even if these same "heroes" are the ones who created the need for heroic behavior.  The oft-cited, and sadly true observation that people will act in which ever behavior is rewarded is painfully true from my experience.

If bosses make a point of rewarding those who regularly "step up and save the project" without looking into why the projects are in trouble, or even looking for trends in whose projects always need saving - then that is what they get - people "saving" projects. 

I truly have no idea why people, bosses in particular, don't see the pattern.  Then again, maybe they do.  Maybe they see it but they just don't want to see it and so pretend that they don't see it because... Yeah.  I think you get it.

One shop I worked at, there was one guy who perpetually did this.  There was always plenty of time to work on whatever the "big" project was.  So, "little" stuff that "needed" to be done tended to get inserted.  These tended to be cool, kinda fun in a geeky sort-a-way.  If the "real" project was really boring, or really uncool, the tendency was to increase these "side projects" that needed to be done even more.

So, what was the response?  All the rank and file developers, testers, PMs, BAs - everyone recognized this pattern.  Everyone knew what would happen.  Everyone had seen it so many times, it was predictable.

SOME code would be delivered close to the "code complete" date.  But it never would be on time.  And the first build never worked.  Instead, testers would get a lecture on how late this guy was up the night before "finishing" the stuff that was delivered.  He considered us ingrates.

When confronted with the cycle of behavior, he, and his manager, would simply fall back to a series of set responses.  "Other stuff was needed right now and he was the only one with the bandwidth to do it."  Except if he really had the bandwidth, the project code would have been delivered on time, and with the promised unit testing done.

Instead, he got praise in meetings for "stepping up."  No.  He did not step up.  He created the situation then stepped into it.  He wasn't a hero.  Sorry.

Michael Bolton made a really important point in the twitter discussion I mentioned above that made me think a bit more on this idea.  It is similar to my own general thoughts, but somehow, he said it much better.

"It seems, when you say "hero", you mean "self-aggrandizer", or "enabler", or... something. But not /hero/."   (@michaelbolton on Twitter, 22 March)

This, I think, is the core problem.  In earlier posts, I talked about "False Heroes" - I've met true heroes and worked with some.  These folks are not heroes.  I think from this point on, I simply will use one of Michael's terms. 

People doing outstanding things in extraordinary circumstances, behaving admirably while those around them falter.  What does it take?  Find a real hero and ask them.  

Note:  I began working on this before the events of 15 April in Boston.  You want to see what a hero looks like?  Scores of them visible in the videos from there.  Heroes contribute because it is the right thing to do, not for the praise and recognition that some are heaped with later.

Hold Fast. #BostonStrong