François Constant logo

Decision making trap & bad technology

January 2019

When developing a website for an organisation, you’re usually directly exposed to its IT infrastructure and to its internal organisation / politics. In most cases, it’s all fairly coherent; sometimes, it makes no sense at all. In some cases, a piece of software is being used while every single person using it hates it. How did that happen and what can we do about it?

Escalation of commitment

Most terrible technical decisions are usually the result of an escalation of commitment. If you’ve never heard that term before, here is the definition from Wikipedia:

Escalation of commitment is a human behavior pattern in which an individual or group facing increasingly negative outcomes from a decision, action, or investment nevertheless continues the behavior instead of altering course. The actor maintains behaviors that are irrational, but align with previous decisions and actions.

Without getting into something as complex as an organisation IT system. Let’s see how an escalation of commitment might trick us into buying shoes*:

I’m sure you’ve experienced something similar in the past. Shops keep up their discount ads as long as possible. If more people enter the shop thanks to the ad in the vitrine, more people are likely to buy something. It’s very basic statistics & very basic manipulation.

The reason for people to buy something isn’t the ad itself, it’s not their exposure to the products either (they can see them from the vitrine anyway), it’s their decision to have a look. We somehow often carry on with our decisions even when new evidence prove us wrong.

In the above example; the decision to buy a pair of shoes is first taken for a good reason: the shoes Tom likes (and usually buys) are 75% off. Then, when exposed to evidences that this is a bad decision (it’s 75% off for basket ball players only), Tom should change his mind and get back home straight away. Somehow, Tom persists and still has a browse in the shop.

This happens when shopping. This also happens when people picks IT services such as: CRMs, web hosts, payment providers, image managers, etc.

Escalation of commitment in IT

Step 1: the initial decision

Tom didn’t just buy unnecessary shoes, he also picked a CRM a few months ago, got the team to start using it, and, wants you to integrate it in his organisation’s website (he wants full integration: contact synchronisation, contact form, payment logs, everything you could possibly think off). Tom and his team had decided to use the amazing Customer Management Super-daddy Enterprise Edition as their CRM. They have chosen it because it checks all the boxes:

Step 2: the practice

After the testing phase, everyone at the organisation has been using this CRM and it’s been clear that this CRM has some issues:

Tom and his team have considered changing it but the same might happen with the competition and the training has already been done (this should should sound familiar !).

Step 3: under the hood

As a Web practitioner (UX, dev, design, etc.) you get a different perspective on tools. You don’t only use them, you also have to integrate with it and get all edge-cases covered.

Tom wants you to integrate this CRM into his organisation’s website. You take a look at the CRM API and one (or many) of the following happens:

I hear your concern but you must understand that […]. Considering the current […]. You know better than me how […] is important in today’s […]. Therefore we’ll u-n-f-o-r-t-u-n-a-t-e-l-y have to stick with “Customer Management Super-daddy Enterprise Edition”.
Quote from someone who clearly doesn't have to code

At that particular point the decision making is fairly rational* for Tom; he should keep the same CRM.



Step 4: prototyping phase

You get going, build a quick prototype to figure out what’s feasible, test all the assumptions; prepare the full UX on paper and show both (quick demo and UX) to the customer. During that phase, you’ll likely find more issues and find things that simply can’t be done with the current state of the API. You’ve taken this into account in the UX preparation you’ve done.

Tom now has mix feelings. On one hand, he’s excited to see things working that fast: he can go on staging, do something and see the results in the CRM backend. On the other hand, he’s a bit disappointed about the missing feature for the marketing team.

At that point, the decision to carry on with this CRM isn’t that obvious for Tom:



Step 5: staging phase

After agreeing on various UX details, you go on and build the full integration. You find other smalls issues on the way, inform Tom and update staging.

Tom is really happy with your hard work. It’s all working and he understands the tweaks you had to do to work around the API. He asks you for a few tweaks and send the demo link to everyone.

Step 6: the drama

Tom has been preparing this for months. Surprisingly, some random dude from the board (who’s been following the whole process) informs Tom about a crucial feature that can’t be launched without - let’s call it Dude feature. That crucial feature was obviously never mentioned to Tom (or anyone else to that matter).

Tom asks you about it; you check the API and - well - this isn’t possible. Let’s get back to the decision sum-up:



Clearly at this stage, another CRM should be used. Somehow, Tom and his team insist on using it. They ask you to build that specific feature no matter what. Something isn’t right. This is completely irrational but they stick to their decision.

What happened?

A massive escalation of commitment happened and you even became a part of it - congratulations. The result of the unfortunate initial decision means that the team will deal with ongoing issues, both on an organisational level and on a technical level. New team members will need training to use the CRM. The CRM will sometimes break. The API will make future debugging and updates difficult. The more it’s used the deeper the issue grows and migrating to a different CRM will become harder.

This is a very common decision pattern and it gets very hairy in IT because the wrong decision often involves many hours of development and testing. Changing our mind is costly and involves discussions with many people from different teams. On top of that, technology choices are quite stressful. Indeed, most people don’t fully understand what they are deciding on and the implications plus the vast amount of choice is often overwhelming.

What can we do about it

As mentioned in the introduction, as an IT practitioner you’re usually directly exposed to an organisation IT infrastructure and to its internal organisation / politics so you can quickly see its incoherences. It’s obviously not your role to try to fix everything but mentioning specific IT issues which stand out is important. I believe that this should be done in writing (by email, in a ticketing, etc.) and I believe that you should be very specific. Writing things down and being specific is always important but in this case it’s even more so. You want the customer to read it on their own, have time to think about it and come to the conclusion that a change would be better on their own.

Therefore, you should write down in plain English what’s the issue is and what its impacts are. For example: “the API returns products with negative prices, we can ignore these products but we cannot possibly sell them on the website when this happens. We have to add extra code to handle these. This wouldn’t happened with the competitors X, Y and Z. etc.”.

Informing is great but insisting is pointless. As much as I think it’s important to inform your customer as much as possible; I don’t think you should keep insisting once the decision is made. If you were to insist you would force Tom to defend the CRM (and help him finding reasons to do so).


Being self-aware of this pattern is very important to avoid the trap yourself. It works with everything; study, work, relationships, etc. It often comes to the same very simple principle. At first, with the evidences at hand, it looked like a good idea. Then, when proven wrong, you persisted. Persistence is a quality, but sometimes it’s dumb; the line is very thin.