Why do software engineers’ elite teams also fail?

One of the biggest lessons I have learned over the years in my career is that the most prominent developers’ minds always tend to make the most significant mistakes, maybe because, often, the best engineers are the ones who work on the most complex problems. Still, experience has shown me that there is a hidden truth affecting elite team performance.

In this article, I will expand on the term that I call predominant team biases (PTB), what it is, and why I think diversity is the most important feature that enhances and optimizes the performance of any software engineering team.

I have been a software engineer for over a decade; during this period, I have worked in more than nine companies in four different countries, and more than five times, I have seen the same event happening in one of these companies; the best software engineer (yep, the guy that writes code that no one else can read) was fired.   

For years, I have been impacted by those moments in such a way that I’m even planning to write a book about it (I will expand on that in another article).

The uncomfortable feeling of seeing you or one of your teammates being pushed away from his chair as I was convicted to jail has never been forgotten.

Several times, history has shown that elite teams, while often lauded for their high performance and achievements, can also fail, and when they do, they fail big. The reasons can vary, but a common principle prevails, and I harvest it for myself, understanding with a peculiar title: Predominant Team Biases.

We are all susceptible to biases, but I have found from my own career experiences that when you put a group of brilliant (and I define brilliant as the best of the best) software engineers or developers in the same room without specific guidelines and effective leadership, the creativity, performance, communication, and productivity are hardly damaged.

When the best work possible is expected as an output, which is common in high-performance teams, the same bias patterns show again and again; these patterns tend to prevail in each team event; this can be easily identified in team meetings, feature estimations processes, accomplishment analysis, and team communication rhythm.

Biases have been understood thanks to many years of research and the Implicit Association Test (IAT), one of the most famous tests in psychology.

Psychologists have created this extensive list of biases that are presented in all of us, but from this entire list, there are five that are the most important for this article since it is often shown in elite teams:

Confirmation Bias

Confirmation Bias Wikipedia

In-group bias

In-group Bias Wikipedia

Affinity bias

Affinity Bias

Attribution bias

Attribution Bias Wikipedia

Conformity bias

Conformity Bias Wikipedia

It’s important to note that these biases, in most cases, are not intentional; they can often be unconscious glitches presented in building or maintaining great and highly cohesive teams at a high level of performance.

I have experienced that more than being aware of these biases and trying to mitigate them with strategies like open communication, objective criteria decision-making, and unconscious bias training is needed when trying to minimize their impact.

In my opinion, diversity is the best strategy to mitigate such problems; highly efficient software engineer teams are those that include:

Diversity on expertise level:

Junior and Senior software engineers with the right bridge of communication and self-enhancement process can guarantee an accurate level of feature delivery, time estimations, and a different level of code performance and architecture design perspectives.

Diversity in expertise:

This, of course, depends on the product or project type, but to expand on this item with a simple example, I prefer to have front-end, back-end, and full-stack engineers when building a web system. I prefer team members with different experiences from different industries and types of systems instead of developers with the same skills or expertise.   

Diversity of nationalities:

This is not mandatory, as the two mentioned earlier, but I have noted that teams that include different nationalities and ethnicities tend to work the best if a good environment is granted for them; the reason for this might be because past experiences tend to influence our most predominant biases, and the environment we lived plays a significant role on the predominant biases we as person develop in our subconscious mind.

Creating elite high-performance teams is an arduous and challenging process that requires the best people in the field, an evolvable and equitable environment, a data-driven goal-achievement process, trust, and outstanding leadership.

Including these dependencies in the same source code takes work. Still, paying attention and understanding the predominant biases your team presents is an excellent assessment every software engineer should do to help improve their system and environment.

Ultimately, building it with a great team is always better no matter what product you are developing.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *