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:
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*:
- Tom is walking home
- Tom isn’t planning to shop
- Tom notices shoes he likes with a 75% discount
- Tom then decides to buy them and enter the shop
- This is a good decision; buying a discounted pair of shoes now will make him save money in the long run
- Tom looks for the shoes and find out that they are only available in 13 and 14
- Tom decides to take a look anyway at other pairs of shoes since he’s in the shop
- This is a bad decision; he’s wasting his time
- Tom might even buy some shoes he wouldn’t have bought without that sign
- This would be a terrible decision; buying a fully-priced pair of shoes now probably means losing money in the long run (there are regular discounts after all).
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.
- the shoes example comes from this highly recommended book: Petit traité de manipulation à l’usage des honnêtes gens.
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:
- for the marketing team
- for the support team
- for the customers
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:
- It took a lot of meetings & training to get everything working
- A few strange bugs occurred
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:
-
the doc is a power point
-
you must sign a disclosure agreement to access to the API documentation
-
the API doesn’t match the documentation
-
the API just doesn’t work
-
the API is production only
-
the API returns products with negative prices (but just sometimes) - true story !
-
etc.
-
You see the red flags really fast and inform Tom about the potential issues, their costs and tell him about all the great alternatives. Usually practical and direct, Tom suddenly metamorphoses into a politician:
At that particular point the decision making is fairly rational* for Tom; he should keep the same CRM.
Pros:
- Fits marketing team needs
- Fits support team needs
- Fits customers needs
- Training has been done
Cons:
- Some bugs
- Poor quality API
- If my dentist discouraged me from using a type of toothbrush; I wouldn’t use it even though I liked it otherwise. If an essential piece of software API is buggy, you should move on to another platform, period.
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:
Pros:
- Partially fits marketing team needs
- Fits support team needs
- Fits customers needs
- Training has been done
Cons:
-
Some bugs
-
Poor quality API
-
Doesn’t support feature X via the API for the marketing team
-
You ask again Tom if by any chance he had second thoughts about this CRM but Tom remains happy with that decision.
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:
Pros:
- Partially fits marketing team needs
- Fits customers needs
- Training has been done
- Website integration partially developed and tested
Cons:
- Some bugs
- Poor quality API
- Doesn’t support feature X via the API for the marketing team
- Doesn’t support Dude feature via the API
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).
Conclusion
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.