Thinking about picking up a technology because it’s well suited to your product requirements? You might be wrong.
The Choice
The scenario: The team needs to make a technological choice by introducing a new event broker. There is none at the moment. The two contenders are Kafka and Pulsar.
Developer A has significant experience with Kafka in real life situation. They mention the complexity of Kafka operations at scale and vouches for Pulsar. Developer B is a proponent of Kafka, as it became a standard in the industry and has strong support overall. They have little experience working with Kafka though. Both agree that we only have basic requirements with no change in workload for the foreseeable future and these two solutions would both fit the bill. The rest of the team is less opinionated.
After hours of meetings and point-by-point comparisons against a technical criteria grid, Kafka is chosen. Everybody agrees it’s perfectly sound decision-making, the rationale behind the choice is documented, and the team proceeds with the implementation.
But are the true motivations of this choice ever evoked?
Humans Are Difficult
In fact, behind the engineering rationale, there are personalities. Humans are complex machines with a familiar yet totally unruly operating system.
We think decisions are taken (or should be taken) according to a rational process, but the reality is that decision-making is clouded by immediate or anticipated emotions.
For example, it’s a well-known fact in marketing that we buy on emotion and justify afterward with logic.
Some argue that non-rational arguments are a source of unwanted bias and need to be properly regulated. Others maintain that feelings play an adaptive role in decision-making and benefit personal wellbeing.
What is certain is that sometimes we first decide on emotions and then justify with logical reasons. We are even masters at persuading ourselves of the absolute objectivity of our choices.
It is the duty of everyone in the team to recognize these emotional or psychological biases for what they are and to turn them into something useful. Let’s review our introductory example with a more intimate perspective.
Decision Process Reviewed
The scenario: Developer A is a talented generalist. They favor the breadth of knowledge instead of its depth — a Jack of all trades, master of none. They are quickly bored with working on one subject. Naturally, when a technological choice arises, they tend to favor everything new.
Developer B is more conservative. They are really enthusiastic about a few technologies and want to master them. They tend to choose what is familiar to them. They are also not really assertive, and while they may be really passionate about technology, they have a hard time speaking up and conveying their thoughts.
Both of them are also building their prospective careers, one as a generalist and the other as a specialist. Picking up technology or a new way of doing things is a little nudge in their career direction.
All these factors weigh a lot in the decision but are not usually evoked or recognized in the decision-making process.
So what should you do?
Making the Invisible Visible
Simply put, you should consider these not-so-rational criteria in your technological choices. Although you can’t expect everyone to express their inner feelings, you should encourage people to evoke their preferences by introducing new criteria in you decision making.
We start with a basic grid with our technological criteria, each with a maximum rating according to our constraints and priorities (for costs, a higher rating means less expensive):
"Criteria", "Max rating","Tech 1", "Tech 2"
"features", 100, -, -
"security", 100, -, -
"ecosystem", 50, -, -
"setup cost", 30, -, -
"maintenance cost", 150, -, -
"license cost", 150, -, -
"interoperability", 50, -, -Basic stuff. Then we add subjective items to the mix. You should propose and discuss these new items with the team to ponder their weight.
"Criteria", "Max rating", "Tech 1", "Tech 2"
"Career Interest", 30, -, -
"Popularity/Trendiness", 50, -, -
"Familiarity", 30, -, -It’s only an example, of course. They should be tailored to the team aspirations. These criteria may be understood as such:
- Career interest is self-explanatory, it’s how the technology fit with my career plan.
- Popularity is the craving for novelty, the buzz factor of this new cloud-native technology that everyone is speaking about in meetups.
- Familiarity is how comfortable I am learning this technology that I may be unfamiliar with beforehand.
You then rate your candidate solutions with the added bonus to better understand everyone's motivations. Every team member should individually fill in the grid before sharing it with everyone.
Let’s be clear: They may not be the best criteria. Some of them may seem laughable or downright heretic to you, but that’s not the point here. We only want to convey what people have in their minds that may influence their choice.
The Right to Disagree
Obviously, the final choice may not follow the cold arithmetic truth — especially if the scores are tied. In these situations, the leader of the group typically makes a final call on the direction to take.
It’s only natural that a team member may have a strong conviction for another choice and be bummed out. You need to acknowledge this disagreement.
In fact, a leader's duty is to encourage disagreement.
A classic story from Peter Drucker sums it well:
“Above all, disagreement is needed to stimulate the imagination.” — Peter Drucker
Encouraging disagreement is the only way to prevent the consensus trap. But in the end, people should disagree and commit. This phrase was made famous by Jeff Bezos in one of his letters to the investors:
“Use the phrase ‘disagree and commit.’ This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, ‘Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?’” — Jeff Bezos
But why would people proceed with a decision they don’t agree with in the first place? Simply because everyone had the opportunity to speak their mind and be listened to. Importantly, they had the chance to express not only their logical arguments but their aspirations as well.
This way, the final decision is well articulated and easier to accept for everyone.
Takeaway
You should consider a more human-centred framework for evaluating technologies. Behind the cold rationale of engineering, you have to take into account human psychology and aspirations. Recognizing them makes everyone happier and creates a strong alignment on common goals.