Are Cocky Developers Worth It?

by Eric Spiegel
http://itmanagement.earthweb.com/features/article.php/12297_3771746_1

I was sitting down with one of our most productive software developers for his annual review, trying to carefully craft my words. You see, Tyler had produced some amazing results that year in tackling our most difficult assignments. Praising him was easy… almost too easy.

My conundrum over word phrasing was a direct result of the way he worked with the rest of his peers on the team.

How did Tyler’s teammates perceive him?

The descriptive words I can print were brash, arrogant, overbearing and even cocky. It’s important to consider that these other developers were not in his league, at least not when it came to solving the most difficult technical challenges.

I actually believe the majority of the team was intimidated by Tyler’s technical prowess. To help understand their viewpoint, let’s examine his impact on overall team cohesiveness.

One of the more productive project management tasks this team participated in were peer to peer reviews. In these reviews, Tyler dominated the feedback. He never hesitated to express his opinion, although some might have even considered his views as mostly subjective and sometimes overly aggressive.

I had no problem with this because these code reviews were meant to challenge and enlighten the team, bringing to light alternative approaches. As long as the attacks weren’t personal and everyone acted like professionals, lively discussion produced improved results.

What I was concerned about was that when Tyler participated, the others would clam up. Why? Because Tyler was quick to shoot down their ideas and rarely accepted, let alone objectively considered, opposing opinions.

Tyler almost always prevailed in an argument and when he didn’t, well, it wasn’t with grace. He would generally respond with a tone of snickering like “Fine, do it the stupid way, but don’t blame me when load testing fails.”

And you could be sure if it did, there would be an “I told you so” loud and clear, usually through an email to the team where Tyler would bask in the glow of his triumph – at the expense of team morale.

I had originally decided that as the team manager, I shouldn’t attend these code reviews. This turned out to be a double-edged sword. On the one hand, I wanted the developers to feel free to constructively criticize each other’s work without being afraid of how their manager would react to their honest feedback. On the other hand, when Tyler participated he ultimately had the same undesired effect of shutting down the open expression of ideas.

Finally, I reluctantly decided to sit in on code reviews. This was met with a sigh of relief from all the developers, even Tyler, but for very different reasons.

The majority of the team hoped I could temper Tyler’s aggressive style, while Tyler was happy to show off his talents to the person in charge. Almost immediately, a debate broke out over memory management in a C# application. I believe my presence encouraged a couple of the others to speak up. When Tyler started to snidely cut them off, I decided to step in and stated that everyone should have a chance to finish their points.

Tyler, being a C++ guru, felt strongly that using manual memory management techniques was the most effective approach to ensure unused memory was released. The others weren’t comfortable with this approach and felt just as strongly that automated memory management (i.e., garbage collection) was a more efficient approach for this project because it was written in C#.

There were merits to both approaches. Not every developer on the team had the skill to correctly implement manual memory management, and C# handled garbage collection just fine, under most circumstances. However, for high volume processes that required close to perfect memory management, it made more sense for someone with Tyler’s skill to implement a manual approach.

I digress, because the technical details aren’t as important as the way Tyler approached his fellow developers on this issue. Instead of insisting that he was correct and effectively calling the rest of them morons, there should have been more of an objective approach. An approach that considered the skill set of the team, the importance of memory management for this particular module, and the ability to set standards that the majority of the team could follow.

We were all able to agree that garbage collection was our project standard, and that manual memory management was the exception based on need. Even Tyler acquiesced. I praised him afterward.

You know what his response was?

“Hey man, not a problem. I realize that my skills are on another level. You can’t clone me, right?”

So maybe this wasn’t quite the step forward I had hoped.

The Review

Perhaps you can now better appreciate my careful consideration of wording as I prepared to deliver Tyler’s review. In my mind I said “Tyler, you are an excellent software developer, but you need to be more respectful of your teammate’s opinions.”

In reality, the words that came out of my mouth were “Tyler, you are a great developer, but frankly your peers think you are cocky.”

He smirked and said, “I like to think of myself as confident, not cocky.”

Okay, not a bad retort.

I asked him why he felt so self-assured. Tyler said “Look, I’m usually right. The others don’t have my experience with true, hardcore development. I don’t rely on automation; I rely on my mad skills.”

Mad skills? I heard this term used by the six-year-olds I coached in soccer, so I got it…but geesh!

After considering his response, I said “I’m okay with you feeling good about your “mad” skills, but there is a difference between confidence and cockiness. As a good teammate, you can use your confidence to share your vast experience with the team in peer reviews. The difference is, if you belittle someone, you are being cocky and frankly not helpful. We need the team to be confident, and you can lift the team up by being more respectful of their opinions and taking a mentoring approach, instead of dictating your opinions.”

Tyler simply nodded in response and was actually quiet through the rest of the review. I must have struck a nerve, perhaps positively or maybe I simply ticked him off.

Over time he still had his brash moments, but he also made attempts to teach his points. Certainly he disagreed many times, but instead of thumbing his nose at everyone when his point was vindicated, he actually talked civilly to the dissenters and discussed why his position ended up being validated.

Sometimes it’s better to be direct with “cocky” developers who might appreciate being called out on the carpet. You just may end up with a more confident and productive development team.