Do we need one?

When I talked about difficult conversations at Agile Yorkshire last week, the subject of "Hero Programmers" (HPs) came up. What is a "hero programmer"? Lets give ourselves a working definition. A Hero Programmer is someone who:

  • Is deferred to by all the other programmers
  • Has deep technical knowledge of the product/system.
  • Very busy, he works long hours, he pulls all-nighters for the good of the company – hey, he’s a HERO.
  • Widely regarded as indispensable by other people in the company.
  • Rarely takes holidays.

Sounds great. A hard-working, highly-skilled and very valuable member of the team. So what’s the problem? Well, there can be a few problems. Here are some other possible features of the Hero programmer.

  • Makes big technical decisions without consultation (i.e. changing the implementation language for the entire project).
  • Saves technically difficult work for himself rather than distributing it through the team.
  • Decides what features get worked on next
  • Regards himself as the architectural (or even moral, aesthetic) guardian of this system. And regards these ideas as higher than any mere “business” goals.
  • Refuses to pair program (often suggests code reviews as an alternative, though they rarely actually happen).
  • Rejects as a "waste of time" or a "fad" any of the basic technical improvement practices suggested by Agile: continuous integration, refactoring, Test Driven Development and even sometimes source code control.
  • Is DEEPLY suspicious of consultants.

Do any of these sound familiar? Is this you?


When I talked at Agile Yorkshire the subject of "Hero Programmers" (HPs) came up when I was talking about issues around identity. I talked about 5 identity dimensions which I got from this book - "Beyond Reason":

  • Appreciation
  • Autonomy
  • Status
  • Affiliation
  • Role

And when you think of Hero Programmers in line with these identity dimensions you can see how difficult it is to budge an HP. Along each of these dimensions, our HP is strongly rewarded. They get lots of appreciation – bosses, project managers, customers are grateful when they finally get the functionality that they want. Because the HP is the only one that can do a lot of the trickier bits of development they have the autonomy to decide what gets done, in what order. In the company and sometimes also by customers the HP is regarded with high status.

Very often, the HP's affiliations are not to the team that he works with. He may also feel an affiliation to an international band of coding gurus whom he talks to daily online and sees at conferences. To him, what they think of what he does is far more important than his work colleagues. And this brings us to his role as he sees it – keeper of the pure flame of the architectural (or sometimes even artistic, ethical) integrity of the project.

He probably gets very sniffy whenever anybody talks about money.


So, along 5 different measures of positive identity, the position of HP buries the needle. No wonder HP’s don’t want to change. From the HP’s point of view, the only direction is down. If he changes the way he works, if he gets promoted, he moves away from things that he knows (software development) to things he doesn't know (business, team-leading, management).

Do you have a problem with an HP? Here are some things you might try that I know have worked elsewhere. Most of these suggested approaches involve increasing the HPs status and autonomy rather than attacking and restricting them, which is what the usual (and greatly feared) move into team-leading and project management threatens:

  • Reduce the work load for the HP: Insist that he take his holiday. When he is at work, he shouldn’t be max-ed out, he should be given time to teach others what he knows and think strategically.
  • Turn the HP into an internal consultant – whose job is to roam between projects and solve the really hard problems.
  • Turn the HP into a "fellow" who's job is to think great thoughts and come up with new ideas.
  • Get him to talk and teach, write books, to your staff and on the conference circuit. It will be worth the travel expenses.
  • Turn the HP into an external consultant, hire out his specific, excellent skills to other companies.
  • Turn the HP into an open source guru – put some aspect of your project out in the public domain and give your HP the task of leading it.
  • Turn your Hero Programmer from a Code Geek into a Business Geek. A friend of mine used to write the software for the hedge fund that he part-owns, but now he involves himself far more in the minutiae of the tax laws and the mechanics of limited liability partnerships.

One thing that occurs to me is that if you keep seeing the same situation again and again, it must be a "stable" situation – what John Nash would call an "equilibrium". There are powerful the drivers are to keep somebody in this role (run through the identity list and think about the role of project manager – why would anybody want to be one?). The trouble is that it's a local equilibrium that prevents any kind of positive change. If a team that has formed around a "hero" programmer, out of frustration with this stability and stuck-ed-ness, very bad things can happen.


Yeah, yeah, he's a life-saver, but you don't have to work with him


If the HP is a founder they can be ousted in a coup by other board members. Or if the company finds finance, or is taken over, they are swiftly removed (VC’s have developed the sharpest skills for dealing with HPs through sheer necessity). Often the team or the company around the HP just evapourates, the juniors get less junior, read the writing on the wall and walk away. But these are actually good outcomes compared to the most likely outcomes in the short term.

Things carry on as they are.

139 views and 0 responses