People tend to glorify confidence. In interviews, we tend to think more of the person who expresses themselves loud and bold, with their held head high. This tendency is especially true among Americans, the most obvious evidence being the current President of the United States, Donald Trump. After all, most psychologists agree he is profoundly full of himself. Despite his failures in business and real estate, he continues to believe he is the smartest man on Earth. Unfortunately there are many fields where people like Trump get promoted and software engineering is no exception.

I wish that the tendency didn’t extend beyond politics, but it does. Entitled, loud, and opinionated engineers get promoted faster than their more subdued peers, regardless of actual skill level. Managers without technical knowledge have no other way to evaluate the skills of these developers. So they end up judging engineers the same way they judge managers.

I’ve seen this first hand in the six different programming jobs I’ve had thus far. It was difficult for me to gain any significant respect in the companies I worked at because I was not outspoken. Over the years I’ve learned that I need to open my mouth more. I’ve gotten better at self advocacy, but it still bothers me that silence is mistaken for a lack of competence.

Here’s something I want any manager reading this right now to consider. What if the quiet engineers are not incompetent, or shy, or lack social skills? What if they are just being careful to speak up because they want to verify accuracy? What if they feel intimidated?

When you are starting out as a developer, especially if you are underrepresented in tech, it’s difficult to speak up about things. Even if you know someone is saying something patently false, its easy to hesitate about correcting another developer. They might get angry and hold a grudge against you, who knows? Getting the confidence to confront another developer can take months, even years. Some developers never gain that confidence at all, even if they are competent.

I’ve had this happen on a number of occasions. The most memorable was when I was discussing a UX issue with a backend developer who tended to dominate all of the conversations. Despite knowing nothing about UX, this developer consistently argued with me about every choice I advocated for. When I pointed to research and specific examples from my classes, this developer would fire back. He argued he saw the UX choice in interfaces that he had personally used (like JIRA – yes, JIRA). It became quite heated on several occasions.

The promotion of loud engineers is a problem because the more those loudmouths get promoted, the more people are afraid to challenge them. Since they were prone to interrupting other developers even before they were promoted, the problem gets a lot worse when their ego grows.

The other problem with promoting such engineers is that it validates a certain communication style. That is one of blurting out the first thing you believe to be correct, without proper investigation. Over confident developers are notorious for jumping to conclusions. If your team sees that the loudmouth engineers are the ones who get promoted, they are more likely to adopt this communication style themselves. Is it helpful to blurt out the first idea that comes to your head? In brainstorming situations, sure. But when you are trying to fix a difficult bug it can derail the problem solving and send the team down the wrong path.

To be clear, I don’t want to sound like I am demonizing anyone who leans toward the chattier side and likes to talk. A team of engineers that over communicate is better than the opposite. The problem lies specifically in the situation where one overzealous and egotistic engineer drowns out the other voices on the team.

Now that the new year has started, it’s the perfect time for companies to reevaluate their promotion strategies and consider fresh approaches. Sometimes quiter developers need a little bit more encouragement. They might not be sure if they can train people or be confident enough to lead a team. That doesn’t mean that they would automatically make a worse leader than the engineer who is always talking.

Is it possible the loud developer who thinks they are a genius will leave the company if they aren’t promoted? Certainly. But the rest of the developers will be grateful, and happier at work. They are more likely to go to the modest leader for questions, and learn more. It will also be easier for them to explain what they are struggling with without feeling stupid.

There’s one more thing. Maybe you are reading this and going: okay, but what if my loudest engineer really IS a genius? Maybe they have a PhD in physics, or four masters degrees, or they wrote their own game engine and sold it to Bethesda. Even if that is the case, consider deeply if their personality is really good for leadership.

Ask the following questions. Are they the kind of person who is willing to delegate tasks, or do they think they can do everything themselves? Might they become a bottleneck in the future if given too much control? Are they actually good at explaining technical concepts to juniors or do they like to overcomplicate things to make themselves sound smarter?

I know not everyone reading this is going to take my advice. Maybe it’s not practical, and there are too many other problems to deal with. My goal with this article was to highlight why these patterns in promotion are not as great as they might seem at first. Even if only a small fraction reading this actually change their promotion practices, I will feel like it was worth it to write this. As a developer myself, I know that having a positive relationships with my manager and lead engineer makes a world of difference.

If you enjoyed this article, consider following me on Twitter @nadyaprimak or if you need more tips on breaking into the tech industry, you can read my book “Foot in the Door”in paperback or Kindle now.

The post Your Loudest Engineer is Not a Genius appeared first on www.nadyaprimak.com.