What Creates an Arrogant Programmer?
No matter what I write, I will be criticized so rather than taking an absolute stand please read anything I write today as a generalization even if I use absolute terms. We all know how easy it easy to inadvertently generalize (see I am doing it already).
For the root cause we need to look at the difference in education from Liberal Arts and STEM majors. I am not picking on the Liberal Arts in fact if I had to do it over again I would have gone the LA route in college. With that said, however, there is a fundamental difference in the education. STEM majors are educated on the bleeding edge and come out of school with top knowledge in their field. In the Liberal Arts, however, graduates leave the University with a limited understanding of a field so complex that it takes a lifetime of studies to become an expert. For the most part Liberal Arts majors graduate with the skill of continued learning, whereas STEM is learned. Because I like graphs that over simplify things let’s look at the graph below that generalized a continuously learning Liberal Art’s graduate and a typical learned engineer. (A say typical because many engineers stop learning in their mid twenties)
What we see is that a STEM major has their most valuable high-tech skills early in their career. This confidence in ability and difference in age creates friction in other professions. You may even notice that a lot of STEM majors switch from hands-on engineering in their thirties. I hope my graph isn’t to blame.
Imagine the scenario of the young developer, let’s call him Chris, at a small company, eager to help, approaching a mid-thirties accounts manager, let’s call her April, as a peer.
Chris is a master of his technical domain and he knows, with absolute certainty, he can help April evaluate her job. Eager to please, Chris approaches April as a peer and offers to help automate her workflow. He is surprised and taken aback when April is offended and tells him off. He just wanted to help and apply his engineering skills where they could benefit everyone. Only an idiot would rebuke free help, April must be an idiot.
April is a hard-working accounts manager. She interned after college and worked her way up through the ranks mastering the relationships and the functional requirements of this job. She is just now getting a complete handle on things. April is a smart, hard-working individual, and now this kid comes to her office. He is twenty-three and he thinks he can do my job better than I can? April has been doing this for 10 years how could some kid possibly know how to do it better? She is going to put him in his place, he needs to learn the ropes like everyone else. Shortcuts are not the way to do things.
Who is right and who is wrong? Ah, trick question, they are both right. The problem lies in the miscommunication. April interpreted Chris’ offer as a mastery of her skill and not an offer to combine his skill with her skill. The result created a feedback loop that is present in a lot of lives of young developers.
Something very subtle happens with this type of communication, something so subtle that it easy to miss. When humans work together as a team our brains release Oxytocin. Oxytocin is one of those crazy chemicals in our brains that triggers love, loyalty, and group behaviors. When an individual is altruistic and attempts to bond with the group by sharing and is rebuked the individual does not get the release of Oxytocin. Without Oxytocin long term group bonding cannot occur. So what does the developer do? He, unknowingly, performs behaviors that stimulate Dopamine releases, the instant gratification hormone instead.
What are these instant gratification actions? One example is performing work exceptional fast. Every work item completed is a release of Dopamine. Furthermore, since the group does not share in the accomplishment the developer is forced to openly brag about the accomplishment, again more Dopamine. This cycle of behavior rapidly does two things:
- It creates arrogance in an otherwise altruistic individual
- It further ostracizes the developer from the group dynamic
Great information but what can I do with that? This doesn’t happen to all developers so clearly there has to be some defect in the developer that can be addressed. Well, perhaps. Remember my graph above there is nothing scientific about it. Every individual has their own level at different ages. My guess is that the problem occurs when outliers work together during formative periods. For example, a brilliant young developer paired with a sub-par mid-career professional. I don’t think this happens over one or two interactions but a pattern of behavior from an entire group or groups lend to creating this environment.
Is There a Solution?
Yes. If you are an Enterprise company or do not want to deal with the developer fire her.
If you are a small to mid-size company or truly want to create a human workforce then here are a few suggestions.
“The needs of the many outweigh the needs of the few,” states Commander Spock. The first action item on every software development manager’s mind when attempting to coach and reform an arrogant developer is to directly address the developer in question, this makes logical sense. Fixing one person is so much easier than fixing a group. Certainly, any flaw must exist within the arrogant developer because the rest of the teams and the rest of the groups are functioning just fine.
I disagree. The feedback loop that was created is a dysfunction of the team not the individuals involved. Because of this we need to find a way to fix the feedback loop. But before looking into that we need to understand a little bit about social dynamics. Remember, earlier, when I mentioned about Oxytocin and Dopamine? Because of these different hormones there is a very strong likelihood that your arrogant developer is not part of any group within the office. Her safety net is her arrogance. With your other team members, however, there is a huge social network at the office mitigating any loss. When we move to make a change in people and directly alter their behavior we need to be certain that we are not actively destroying the only thing a person has.
Have you ever watched an action movie where the protagonist and antagonist square off and the good guy offers to stand down. He does not need the battle. In movies, and in real life, the person most willing to stand down is also the person with the largest social support group. Ever notice that villains, in the movies, only have henchman and not companions while the good guy has family, friends, work, and usually a dog? Look at your arrogant developer for a moment. We have already established that he is ostracized at work. What about home? I don’t know about you but after college I moved to Florida which meant I was developing, completely anew, my entire social group at work and at home. Is your arrogant developer alone at home and work? If so, would you like to know what will happen when you confront her directly about her behavior and tell her to shape up? You will destroy her.
Is this what we want? Of course it isn’t that is why so many software development managers choose to terminate an arrogant developer. It is a lot more humane than directly confronting the truth. But instead we have another choice.
Back to the social groups, remember April? She is, based on research, extremely open to compromise. At work April has a solid social group and team that values her contribution. She knows that a compromise does not make her look unqualified and in the most extreme case a forced compromise can be tolerated because she also has her personal social group to rely on. With this knowledge we can address the Aprils in the company.
Confidentially inform them of the issue and get them on board with the goal: “developing a better team player from the arrogant developer”. What do the Aprils in your company need to do? Bite their lip and deliver real gratitude for the help. This will be extremely difficult, especially if this has gone on for a while. Arrogance only seems to grow and it takes a really strong and comfortable individual to thank an arrogant individual for her hard work.
Teams need to invite the arrogant developer in for collaboration and directly feed the ego of Chris (Chris was my sample arrogant developer, right?). This invitation and thanks is hard to describe and approach so I will leave it to the reader to discover how, just know it is an important step. We need to create an environment where Oxytocin can be delivered and team building can occur.
This is critical, if you have performed Step 1. Arrogant individuals are by nature insecure. Arrogance is a defense mechanism. Because of this, after about the second week, your arrogant developer, Chris, will be suspicious that something is happening. We need to confront the suspicion directly and create a platform to help hold Chris together. Obviously, every individual is completely different but we can just tell him.
“Chris, I called you to my office today because I wanted to let you know I had a talk with the team. I have noticed you have been doing a lot of hard work around here and have been a great asset to the company but you were not getting a lot of credit for your work. I spoke with the team and they were surprised because they thought you knew how good you were doing. They agreed to be more open with their enthusiasm for your hard work.”
Is this a white lie? Not really. If Chris, the arrogant developer, had been slacking off or doing poor work you would have fired him a long time ago. This truth will leave your arrogant developer walking on a cloud. You will have just created an ego bomb but you will have also stimulated a massive Oxytocin release starting a positive feedback loop.
Unfortunately, you will notice that this will not eliminate the arrogance. To be honest, the next few weeks may be the absolute worst that you have ever experienced. Don’t be surprised if Chris shows up to work with a crown, scepter, and a Segway. You are now ready for Step Three.
Now that Chris has more than just ego at work it is time to negatively reinforce bad behavior in a positive manner. As a software development manager you need to examine the behaviors of your arrogant developer to see which ones are easiest to help correct. I cannot enumerate them all but I will give an example or two.
Example One: Arrogant Developers barge into offices unannounced and demand impromptu meetings. I am not talking about the occasional walk-in when something important needs to be addressed. I am talking about the old engineering habit of whatever is on the engineer’s desk is the most important thing in the world. Your arrogant developer likely walks straight into offices unannounced and demands attention for work at hand. Let’s try and correct this in a safe manner.
*Chris barges into April’s office*
“April, I need to understand how you want to format the TPS reports”
“Oh, Chris, I am so sorry. I would love to help. I am completely swamped. I know your time is valuable but I really need to get this out. Is there any way you can possibly schedule a meeting with me on my calendar so I can get this out today.”
What did April do? Played to Chris’ ego (valuable time), appealed to team building empathy (I need help by you rescheduling), and yielded power to Chris. Before you puke in your mouth with how difficult it would be to act like this to an arrogant developer we need to try and keep in mind we are attempting to retrain Chris’ behavior. You can’t beat your dog and expect a different outcome. This conversation and others just like it will stimulate team building behavior in Chris.
*Chris actually brings a Segway, Scepter, and Crown to the office*
This is a bit more challenging. But we need to also remember that corrective action need not be passive.
Software Developer Manager: “Chris, I have noticed you brought in a Segway, scepter and a crown to the office. This behavior is not acceptable. If you do it again you will be terminated”.
Why do I suggest this approach? The S,S &C is not related to work performance, work relationships, or home social relationships. Your developer is just testing boundaries. Set them. However, you need to be careful here. You have to set the boundaries when the infraction occurs not on the third week when the behavior has just been too much. You will need to use your judgment but if the behavior is completely unrelated to work, squash it.
*Chris calls an individual incompetent for making a mistake*
Remember back a thousand words ago or so when we first introduced Chris and the arrogant developer? The root of the arrogance is not malice but altruism. Chris is likely attempting to correct another individual’s behavior without the appropriate skills and is using direct tough love. Because of the hurt feelings we may actually miss the fact that Chris is showing leadership, just misdirected. Every article on the Internet (generalization) writes about how we need more leaders so we want to be doubly careful here to encourage leadership without encouraging hurting feelings.
My choice: a meeting with Chris, William (the hurt individual), the SDM, and maybe HR.
“Chris, I believe you hurt William’s feelings this morning when you called him incompetent. I know where you were going but we want to try and find positive ways to encourage people. Can you think of a more positive way to encourage William?” Ok, I admit, this sounds grade school childish and sounds like I am about to suggest hugs, kisses, and making up. I am not, what I am encouraging is a safe dialogue in a team environment. But, if it is too patronizing for you then you can try other safe communication techniques instead. We want to encourage Chris to make positive suggestions not criticize him for a poor choice of words and we want to do it in a team setting to encourage team behaviors.
You are still reading this? Wow. Where was I? Step four. We need to start removing the special privileges from the arrogant developer. But we can’t do that just yet because we don’t want to create a situation where the negative feedback loop takes hold again. Step four is about creating a social work group for the arrogant developer. This is much easier in large companies. In large companies pools of developers all go out to lunch together and complain together, there is a knitting pool, every Thursday sales takes the afternoon off to golf, Wednesday is a lunch and learn, and on and on. Large companies are full of social group activities with something for everyone. Unfortunately, small and mid-sized companies may only have one developer. If that developer is your arrogant developer, man you have it tough.
We need to find a way to include our arrogant developer into a social workgroup. Step four is not necessary for an older, established individual with strong community ties but it can’t hurt. Word of warning, however, this is direct meddling. As a manager we try not to meddle in the personal and social lives of our reports. It is one thing to be a part of your team’s personal lives it is another to control it. Recognize that Step Four skirts a very fine ethical line.
Why do we want to establish a work social group for the arrogant developer? Easy, we want our arrogant developer to be more like the protagonist in the movie instead of the villain. We want it to be easy for the arrogant developer to compromise because nothing is being lost. We want to create a safe environment to vent. In short, we want to make sure that when we move to Step Five and start treating the arrogant developer like everyone else that he doesn’t revert.
What is the best way to do this? I am not even going to attempt to try and write it. There are just too many variables. Do you have a method? Reply in comments I would love to read them. The only advice I will offer is to aim for small groups where the arrogant developer can participate in 15% of the conversations. We don’t want large groups because they can be socially difficult for new comers and we don’t want a group were the arrogant developer is dominant. We want a comfortable, social, setting that better rounds out the individual.
Slowly peel back the special privileges. Not all at once and don’t be brutal about it but get it moving. We want to be careful that we haven’t created any more animosity than is necessary. People hate special treatment (for others) and will soon start feeling neglected. If you are revoking a special privilege also use this as a time to evaluate the privilege. Are you a suit and tie office that allowed the arrogant developer to wear shorts? Maybe it is time to compromise and allows business casual for all? Remember, we are building a team hear.
That was hard work
You are a manager. It is your job to support and sacrifice for your team. The hard work you do know will pay enormous dividends in the future.
Unfortunately, there is a trend these days to create working managers with up to 80% functional requirements. How in the world can you expect to lead, manage, and support your team when you are also working to create a deliverable as an independent contributor as your primary responsibility? You may need to find a way to spend more time leading and less time programming.
If you don’t like my advice, remember I told you that you can just fire the arrogant developer. It takes a lot less time.