Only the other hand, the hero acknowledged and respected by his colleagues is in a much different position. In fact, most teams would need as many such stars, those highly excel at their craft, as possible to do something really useful. Stars can be peculiar, or indeed everyone should be unique in his or her own way - that’s a good thing as long as s/he recognizes that teamwork is there to stay and s/he can help bring about much greater achievement with the support from all others. A genius and a thousand servants may work, but a genius and a thousand partners who work along well together do much better.

I don’t know much about soccer, but if a star player is resented by his teammates then I wonder if he could single-handedly beat other teams. It’s a 11-man game, after all.

Looking forwards to hearing more from you…

I have just visited your blog and found that this post is so interesting. This is a common phenomenon for all teams, and human factor plays an important role in the success or failure of a project. Please let me tell my thoughts about “hero coder” you mentioned above.

I think hero-coder is not worth being dismissed from the team. I have witnessed one guy in my old teams, he has good technical knowledge, maybe he has strong personality, special characteristics, so occasionally he considered his ideas the best solution. He still contributed to the team. People often say that talented persons often look like nothing and sometimes are peculiar. We have to suffer this. Dismissal is not a last and best solution in this case. A good leader should drive him and transform him into a guy having teamwork mind, a part of team. How to combine all sorts of persons in a team, receive their true respects and lead them to a common goal is one of the traits that not all project managers have. However, I don’t want to defend hero-coders disregarding the team’s disciplines. Whoever you are, the first thing to care is discipline.

Let’s look out there to football teams (in some aspects, software development team and football team are the same). A football team without some stars in its line-up hardly reaches the top of the race. We still remember Platini and Maradona ? They are both the good players in their times, but only Maradona touched the gold trophy because beside his passion, he has strong will and special personality for the triumph. I give examples here just to mean that hero-coders or star-coders should be treated with special ways. It’s so boring if teams include all “yes” men.

Sorry for my telling in a lengthy way here.

Thanks,
Thanh vu

If you have good and well-managed process in place, would it save your time and effort in the interviews so you could focus on other traits of the applicants? Yes and no. A good process does make people collaborate better and leave the hero less room to play his game. But that assumes the hero is the exceptional case since a process can only be as good as the capability of the team who executes it.

Having a bunch of heroes sit together in a the code review, you might end up watching people throw tomatoes at each other. (”Hungarian style is the way to go”, “No, Pascal style is”, “You nuts, my style is.”) And let’s forget about all the fights between hero coders and QA teams. (”Me? Misunderstood the requirement?”)

Therefore, the question remained is how one would do to build up a team which can establish and execute an effective process - one that nurtures the right people and eliminates wrong people very quickly - from the first place. Process, while being absolutely necessary, should only be second thought.

Finally, talking about traits, this post is all about the 3 most important traits that developers need to possess. Others do count, but are less important.

And if some time in the middle project that you discover that the person you hired is dishonest, lacks of passion, or tends to go for one-man heroic effort, the best thing you can do for your team, and probably for that person as well, is to let him/her go very quickly.

One thought crossed my mind: how effectively do processes hinder/feed one-man heroism?

Some examples of processes/practices that ensure team collaboration: mandatory artifact review, testing, resource backup/workload sharing/shadowing

What is your experience in applying (and possibly improving) these practices and how well do they relate to teamwork?

If you have good and well-managed process in place, would it save your time and effort in the interviews so you could focus on other traits of the applicants?

Thanks

@Anders: you’re right if we’re talking about completely incompetent coworkers here. But note the phrase that I intentionally put - “in this particular area”. In other words, the teamwork guy does see both good and bad things in others, s/he knows s/he can be a star in one area but his/her colleagues in another and they are supposed to work together.

Without commenting on the rest of the article, I have to say this is really faulty reasoning. If they DO have passion and honesty they will want to create a good product which they can be proud of. If they have really incompetent coworkers, no matter what they do this will not happen. So they shouldn’t be thinking “I think I can assist my colleagues in this particular area” because that help will be to no use. Instead they should get the hell out of there…

If they want to make the project work they will happily work with those that they wouldn’t normally choose to mix with - for the project’s sake.

[...]In the last few posts on interviewing, I discussed mostly about the technical aspects of the interviewing process and some readers had raised the concern that whether technical competence alone is sufficient for doing programming job well. Well, i…