The problem of arrogance

This post was written by jimrobson on March 12, 2014
Posted Under: General Interest, Software Development, Teamwork

A little over two weeks ago, my father-in-law sent me an article entitled, Why Google doesn’t care about hiring top college graduates.  The article is excellent (as is the NYT article that it’s based on), but what particularly got my attention were the things that Google’s Laszlo Bock had to say about what he calls, “intellectual humility.”

Bock’s comments prompted me to start thinking again about something that has troubled me for years: arrogance among software engineers. Happily, none of my current team members seems to suffer from this particular weakness, but that has not been the case with other teams I’ve worked on, so I’ve seen firsthand the kind of damage that can be done when influential team members have oversized egos. They hurt the team, they hurt the project, and ultimately, they hurt themselves.

Some years ago, while I was working as a senior engineer on a fairly large, geographically-distributed team, I phoned a junior engineer to see how she was doing on her current task. I’ll call her “Mary.” Mary was despondent, and did not feel confident about completing the task. I knew she was perfectly capable of completing it; she was not a rock-star programmer, but she had implemented requirements of similar or even greater complexity in the past. As we spoke, it became evident that she was feeling down about herself because of something another team member, who I’ll call “Mark,” had said about her work during a meeting.

“Mark thinks my code stinks,” Mary said.

I was angry. I had not been in the meeting, but I had already heard about Mark’s performance. And this was far from the first time that he had tried to embarrass and humiliate people by calling out their errors in front of others. This time, however, he had picked on a particularly vulnerable team member, and his comments had done damage. I did not let Mary know that I was angry. Rather than make a big deal of it, I wanted Mary to be able to shrug it off, so I responded matter-of-factly, “Mark thinks everyone’s code stinks.”

“That’s true,” she replied, and I knew it had worked. We talked a bit more, and it was clear that she was ready to put Mark’s comments in perspective and move forward with her task.

I have obviously not forgotten the incident. Mark’s callous remarks had rendered a valued team member unable to progress for several hours, and then required me to spend some of my time to get her to refocus. And this was not an isolated incident. There is simply no way to calculate the negative effect that Mark’s conduct had on the team’s morale and cohesiveness. This, of course, adversely impacted our ability to hit our targets.

Besides draining the team of enthusiasm and camaraderie, arrogant individuals hurt the projects they work on in other ways as well. For example, their high-handed approach to other members’ code often generates more bugs and drains other engineers’ time. I have seen multiple cases where a presumptuous engineer failed to understand the code, and thereby assumed that the code was poorly written and made no sense. As a result, when he (it’s usually a “he”) implements a change request or bug fix in someone else’s code, he casually dismantles the code he has deemed “stupid” and thereby introduces a new bug. Then, another engineer needs to go back in and undo the mess. As a result, two engineers’ valuable time has been wasted: first the arrogant one, who wasted time breaking something that was working just fine, and then the other one, who had to re-create what the first one had destroyed – and often had to re-code the first one’s “fix” as well.

There is much more that could be said about the damage that arrogance does to teams and projects, but I’d like to close this already-long post with some thoughts about the damage that arrogant people do to themselves. This brings us back to what Google’s Bock said about the importance of intellectual humility:

Without humility, you are unable to learn. Successful bright people rarely experience failure, and so they don’t learn how to learn from that failure. They, instead, commit the fundamental attribution error, which is if something good happens, it’s because I’m a genius. If something bad happens, it’s because someone’s an idiot or I didn’t get the resources or the market moved.

Arrogant people frequently have difficulty seeing the value in opinions or strategies that differ from their own – especially when those opinions or strategies originate with people whom they deem to be inferior. Most of us recognize that we can learn a lot from people who are junior to ourselves, as well as from our peers and superiors. By being open to the ideas of others, we learn and grow, not only professionally, but personally, in that we learn to appreciate other people more. People who are blind to this fact cheat themselves of so much.

Reader Comments

I couldn’t have said it better myself. Arrogant team members can be one of the most derailing influences on a team. I have been fortunate to work with staff who are not driven by ego and with staff who carry huge egos (and are arrogant). There is nothing like a very sharp developer who can critique code in a way that creates a learning opportunity for the individual whose code is being reviewed. No one is harmed, one or more people learn in the process, and the code is improved. All is good. Having worked with you I know that you are one of those people!

On the other hand, arrogant staff seem to take these opportunities to build their egos at the expense of others. There is no learning, no team building, only ego.

Written By Jerry DiPalma on March 26th, 2014 @ 11:16 am

This is a very well written recount of a specific, but I find unfortunately, common problem in my experience in working with software engineers.

It is so prevalent that software management books have categorized an anti-pattern for it: “Intellectual Violence”. One book I read on workplace personality types has two categories “Mark” falls under and, unfortunately, I think many software engineers do as well. They are the sniper” and the “know it all”. A sniper’s specialty is making you feel foolish, either in public or in private. A “know it all” is seeking attention by going out of their way to show others their intellectual superiority. The combination of the two personality type is a bully who simply can’t be reasoned with, even if they are competent and often correct.

I’m not so sure that “Mark” or others with these characteristics are arrogant per se, but rather are motivated to constantly be reaffirmed by others that they are very smart and competent. Their sniper and know it all actions are, I think, delivered with the underlying intent to not be mean per se, but rather to ironically have everyone else think they are the best (which obviously backfires).

I myself was on the receiving end of “Mark” in a conference where he amazingly was able to demonstrate both traits in a matter of minutes. He pulled a sniper tactic by blasting code I written with rolled eyes as if to say: “yeah, my dog could probably have done better, but he doesn’t have opposable thumbs.” I agreed his idea was better, but described what the rationale was behind it because of during the original design, there was a potential customer requirement that warranted this. I might as well have said nothing because he did not acknowledge my response because as a “know it all”, no matter what I said was irrelevant; I was clearly an idiot. His “know it all” response was that just “following the design patterns like a monkey gives a better solution.” (well not in those exact words, but basically).

I’ve learned to deal with these people in two ways:

1) Ignore them because ultimately they’ll be fired or phased out since no one wants to work with them.

2) For the sniper, the trick is to bring him out of hiding. While everybody knows the sniper’s underhanded, sarcastic comments are basically saying “You’re an idiot, and I’m smarter than you,” the sniper is ironically not smart enough to realize this. The key is to bring him out of hiding. In response to sniper’s underhanded comment, I would without hesitation nor emotion provide a line of questioning to get them to admit their intent. Example: “When you’re saying that the code I wrote was horrible, what are you really trying to say?” The sniper will never be direct, so now you’ve got him cornered; a typical response from the sniper would be: “Nothing! it’s just a joke,” To which I’d respond, I don’t get that joke, I’m still not understanding what you’re trying to say with your comment that my work is horrible.”

As for the know it all, I also just often ignore them with the intent of distancing myself from them, but if that’s not an option (i.e. I have to work with this person), the two tactics I’ve learned are: a) point out to the know it all that the comments are not of any value add to to the point. E.g., “Mark, I might have misunderstood the point of this meeting; I thought you were going to provide your expert opinions on how to improve our code moving forward. I look forward to your opinions as I know you are extremely talented. I don’t quite understand, however, how pointing out that some code was clearly made because of incompetence helps us move forward. Unless you think pointing out incompetence will help us achieve the goal of improving our code, I’d rather hear your opinions on what we should change and why so we can improve our code.

I just ignored “Mark” and did not choose to take either of these tactics because I just decided I wouldn’t work with him again.

Written By Chris Finlayson on March 30th, 2014 @ 3:24 am