While delivering the Agile Seminars in Pune, India and Taipei, Taiwan over the last week, the question of the development team came up. What started out as a discussion of Team Velocity, ended with a discussion of “Heroes” or “Rock Stars” on the team.

Too many managers think that you need a team of super human coders to get the job done. I think that while a team should have the most talented, motivated, and hard working members it can find, teams should avoid adding the “rock star developer” at all costs.

At the seminar I told the story of a real life story of a team I managed a number of years back. It was a team of good developers and one rock star. Let’s call our rock star developer John. John coded faster than all our team members, some tasks he could do two or three times faster. His code was usually pretty spot on, decently commented, and well thought out. Shouldn’t the entire team be made up of John clones?

Well while the number of lines of code per day developed by John was high, other things did not add up. At code reviews John would argue with other developers about the direction they took. When those developers were not around, John would check out their code and make small changes.

What really got me to my breaking point was John’s inability to see the big picture. Once someone from the business side came over and asked John to make a small change to the online shop by the end of the day. It was a Friday of a three day weekend and the marketing guy thought that he can push this change out and help our sales over the weekend. This change was not in the product backlog (well this was almost 10 years ago, it was more of a project plan back then) but John said he can sneak it in today. John was assigned other tasks that day, but figured that if he skipped lunch and stayed a little late, he could do both and be the hero.

It did not turn out that way. John bypassed our build and qa and production upload process and somehow managed to push his change to production without telling anyone. He figured that the business people would be happy with IT and life would be good. The problem was that this took him longer than expected (it always does, even for rock stars) and he had to skip is regular tasks.

The rest of the team was at a local bar we hung out at watching the Mets-Yankees game on TV. (I remember it was a rare occasion where the Mets beat the Yankees.) John was noticeably not there and we just thought he went home. Then my cell phone beeps, it was the founder of the company asking me why the online shop is down. I said I had no idea and would look into it immediately. I asked a dependable programmer  to come with me and we went to the office to see what was up. Back at the office, the other programmer and I discovered John banging his head against his desk. After some heated words, the other guy and I reverted the site back to the original state. John pleaded and pleaded that he needed just 15 more minutes and that he was a “better coder than me.” While that may have been true, I said that my code always goes through QA. Against his wishes, I sent him home. John would have done better if he called in sick that day, by overpromising, he not only caused a problem with the site that caused two of us to fix, but he did not do his assigned tasks, making him behind in his work.

The next day I get an angry phone call from the VP of Marketing asking why the change was not pushed to production as he was “told by IT” it would be. The VP said that an email campaign was to be sent out telling customers about the change and it would be expensive to cancel it. I told the VP that I don’t care and to cancel it.

Needless to say the next week there were some fireworks at the office. I told John that he was like a cow who produced two buckets of milk while all the other cows produced only one bucket. But he also knocked over other cow’s buckets when he walked by. John thought he was right and I was wrong. That did not go well for anyone.

After the annual raise and bonus season went by and John was not “taken care of” in his mind (he was given the same modest raise and bonus the rest of the team received), he quit and took a job getting paid far more. He asked me what I would say when he used me as a reference. I told him:

“John is an A+ developer. Smart and fast. He is an F- team player. Overall that makes him a C+ developer.”

John never used me as a reference.

Rock stars have no place on a high performing team. Don’t confuse a rock star or “hero” with a very talented developer. A rock star is someone who, while talented, thinks that they are the ultimate guru and that everything should be done their way. Avoid them like the plague!

PS, about 5 years ago John asked me to lunch. It was the first time we spoke in many years. We made our peace and he admitted that he was wrong that day and looked forward to working together one day. I told him that if anyone asks for a recommendation today, I will let them know about our past difficulties and that he has evolved from a “Rock Star” to a great developer with perspective.