Hero-Driven Development

I feel like I may need to start this post by paraphrasing a song: “You’re so vain, you probably think this post is about you.”  I have had the privilege of working with some remarkable technologists during my career and the danger is that they misinterpret what I’m about to write about. Steve McConnell calls them “10X Developers“. They’re the ones who can produce code at a rate of 10 times that of the average. Every software company would like to employ them, and some believe they do.

What I’ve started to notice is what amounts to an organisational anti-pattern.

Anti-Pattern: Hero-Driven Development


Captain Squarejaw to the rescue

Problem: Whenever some gnarly problem raises its head, the Hero is sent to fix it. The team sit back and let the Hero work, maybe watch what The Hero is doing. The Hero fixes the problem (slays the dragon) and the team gets back to doing what ever it was they were doing till the problem was discovered. The Hero flies off into the sunset.

Context: The team has hit an impediment which is within their theoretical skill base but without the experience or resources to fix the problem. The person accountable for delivery is panicking. The team is thrashing and seem to be getting no closer to a solution. Someone lights the signal for The Hero who swoops in to save the day.

Forces: Every software development project is a hostage to budget and schedule. In this context it makes sense to solve the problem as quickly as possible. But this is inevitably a short term fix; depriving the team of the opportunity to learn from failure and pain means that their growth will be stunted. The team’s ownership of their work diminished. In the worst case scenario it can lead to a loss of confidence and morale. There is also the danger that over time, the threshold of what is considered a problem will decline. The perception could evolve that the Hero gets all the interesting work. And worst of all, that any work done by The Hero is immune from scrutiny.

Solution: Trust the team. This is their problem, their mess. Support them where needed, get them expert help, but make sure that the team does not lose ownership of the solution. The Hero can still step in to help the team solve the problem, but the difference is in how the help is evaluated and used by the team. This is an act of collaboration and not an act of salvation. It is vital that the Hero be seen mainly as a ‘consultant’ to the team, whose output should be mainly advice. If The Hero is writing code, it needs to be dealt with in the same way as any other developer’s code. It should meet the team’s “Definition of Done”. And ideally, it should be reviewed publically so that the team can learn from the event and hopefully improve (Inspect and Adapt). It is better as a longer term strategy to have a team of heroes than to depend on a single person to solve all your problems.

Note, I am not concerned in this post with primadonnas or those who don’t share their knowledge. This is not the true Hero. If I had my druthers, I would fire those people from any organisation I was working for. In my experience someone who is trying to make themselves indispensable in an organisation deserves to be shown the door; they are acting for their benefit and not of their team mates or company.

About these ads

4 responses to “Hero-Driven Development

  1. I wonder how relevant this is to the start up phase of a project especially those that are consist of a number of POC type tasks. It seems that team ownership might get in the way initially. This doesn’t mean that dissemination of knowledge mustn’t happen but it could be argued that there are times for a little bit of upfront heroism.

    • I think that POC type activity is entirely different from the case I was discussing. A POC is usually a risk mitigation activity that is planned for. I’m talking about finding a big bad dragon that leaps out of nowhere. Someone who is skilled in the risky area and who undertakes a planned activity (hopefully keeping the rest of the team included by at least keeping them informed) should hopefully be considered as a part of the team. I think that it would be advisable for the person doing ‘heroic PoC type’ activity should probably take a wingman on the job.

      XP uses the concept of a ‘design spike‘ – what is of interest here is that it is usually not considered appropriate for production code – meaning that the hero still needs to come back and show the ‘villagers’ how to fix the problem.

  2. Very, very good description of a very real problem. The problem is that no-one ever sees the super-hero, s/he is so fast :-)

    Collaboration is a solution. But it takes a mindset change for the hero, not the team. The hero has to realise that s/he needs to “code for friends”. It’s about their actions that affect other people. Once they figure that bit out, then they are free.

    Otherwise, they will carry all code-fixes to their death. Too much baggage is eventually slows down the fastest of super heroes.

    Take care, and keep up with the nice writing.
    – Aslam

  3. Pingback: Tales from the Scrum: No esperemos a Superman - Angel "Java" Lopez

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s