Top 3 Biases in Developers and Tech Teams

Top 3 Biases in Developers and Tech Teams

Decision-making and collaboration are invaluable components of effective technical teams. How we arrive at the decisions we make, what factors we consider, the available evidence to support our choices, and maximizing conflicting objectives can be a really daunting process. This article aims to highlight the top 3 biases I believe affect developers and tech teams as a whole often without realizing it.

Overconfidence Bias

This is a tendency to overestimate ourselves and our abilities. This manifests in our perception of ourselves, our cognitive abilities, professional experience, and our teammates. A very typical example is the question most developers have had to answer at some point:

How long do you think this feature will take? How soon will it be done?

You're probably having flashbacks to the last time you answered this question and how it actually took almost triple the assigned time.

It's just a simple page with some animations. I should be done in 2 hours. It's just a simple crud endpoint, I've written thousands before, It would only take a day.

It's easy to think of tasks in their most basic form and overlook the extent to which things rapidly get complicated. This has to be the most common bias and it manifests itself in so many ways. Sometimes it's in the form of people thinking they have extraterrestrial abilities to solve complex tasks and other times it's the fundamental things. It's important to take a step back, shun the egotistic voice and re-assess situations.

Confirmation Bias

1_MRPl_SNuRGJchb6eOAnkSA.jpeg

Photo credit @jwcaroll
To understand confirmation bias, I'll paint a picture of two developers arguing on which frontend framework/library to use for a project. Yeah, we've all been there right. The first developer claims React is the best as its component-based architecture is ideal for the task while the other argues that Angular's well-architected framework would serve them better. Both are due to present their views before the team to make a decision.

In preparing for their presentations, both developers do the one thing developers do best, Ask Google. However, what's interesting to note is that each developer specifically looks for resources that support their assumptions about the framework strength and also the preconceived weaknesses of the opposing choice. In doing so, they've failed to approach the problem from a rational standpoint and as such limited their finding to resources that 'confirm' or validate their choices. Thus introducing a confirmation bias.

When not checked, confirmation bias makes us approach problems from an emotional point of view rather than a balanced and logical standpoint. Hence, it might spell disaster sooner or later.

Commitment Bias

This is sometimes referred to as Escalation of Commitment. It is an increased commitment to a decision despite increasingly negative information or outcomes. It represents an illogical optimism that a previously made decision will come good despite everything pointing otherwise.

Remember the earlier description about the two developers arguing about the framework to use. Imagine, they eventually agreed on one of them, and a few months down the line, the selected framework only seems to be complicating the problem. In an attempt to avoid shame, to preserve a high reputation, or for any other reason, the developer continues to insist that the framework is the best choice despite the clear and numerous obstacles. In doing this, a commitment bias has been introduced into the decision-making process and the eventual outcome would only get worse unless a reassessment is done.

It's important to realize that decision-making and strategy formulations are iterative processes and it's impossible to always get them right. So, on those occasions when it's clearly gone south, don't be afraid to drop your pride and carefully retrace your steps.

Conclusion

Identifying and understanding these biases and their impact on our daily activities goes a long way in making us better engineers and in fact better people. So, hopefully, the next time you're asked to estimate the time completion of a project or presenting your views on a subject matter, you take into consideration these biases and mitigate them effectively.

Thank you for reading. Don't forget to like and share.

Credits

Background Image by Artur Szczybylo