# Friday, March 5, 2010

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.

Technorati Tags:

Bookmark and Share
Monday, March 8, 2010 5:50:25 AM (Eastern Standard Time, UTC-05:00)
So true! Even if the person is not as arrogant as in the case you describe, trying to overachieve (and be a star) can sometimes bring bad karma to the project.
Also, this is also the reason that the best developers almost NEVER make the best managers.
Vladimir Milev
Monday, March 8, 2010 10:14:19 AM (Eastern Standard Time, UTC-05:00)
I once knew a guy that loved apples. He was a jerk. Therefore all people that love apples are jerks
Monday, March 8, 2010 1:42:44 PM (Eastern Standard Time, UTC-05:00)
Hi Stephan,

Overall, and I think you know this deep down: It was a lose-lose because of both of you. John might have been a Prima Donna, but the facts are that you couldn't get him to cooperate the way you wanted to, tried to explain things to him and convince him to be a team-player, you admitted that he disagreed with your logic, and he ultimately moved on, without you to a better paying job. He admitted to you that he was wrong, which I don't know if he really feels that way or not, since I don't know John, but you've accepted it as validation for the fact that you both had a lose-lose together. Being kind of like John and in a similar situation many, many times, you didn't exploit John's unique gifts the way he wanted you to, and he had control in different situations, which he exercised much to your chagrin because, hey, you're supposed to be the one in charge. John is probably very rational, doesn't care about 'position.' as most gifted software architects don't. He only sees things in terms of power, what he get away with, and what he can't. Not his fault you see position as buying you anything--you obviously never had the influence. My only hope is that you move forward and take responsibility for your part, because I am pretty certain, he doesn't feel like he is the only one to blame.
Monday, March 8, 2010 5:09:57 PM (Eastern Standard Time, UTC-05:00)
Hi Stephan..

I actually lay blame on you. The vp of marketing should have never went to the developer directly, and went through the proper channels first. You should of made it clear to your team and business people that requests and changes in schedule or development should of gone through you. You should of took responsibility and either had better communication on what people are working on, or let the vp know the proper way to request a feature.
Monday, March 8, 2010 7:53:08 PM (Eastern Standard Time, UTC-05:00)
Another great blog post! I like the cow analogy; good thinking. I especially enjoy how your entries or so accessible to us non-computer people.
Comments are closed.