Absolute vs. relative decision-making

In negotiation, your “BATNA” is your “Best alternative to a negotiated agreement.” It’s what your alternative is if the negotiation falls through.

The simplest example of a BATNA is when buying a car. If you don’t have a car currently, or if your car’s just broken down and you’d have to spend $3000 to fix it, you have a pretty poor BATNA: you need a car, or you’re walking/taking a taxi home. This puts you in a very weak negotiating position.

Or, on the other hand, my grandparents used to go to car dealerships when there were free lunches. They had a perfectly functioning car. When it came time to negotiating, they had a great BATNA: a well-functioning car that didn’t need to be replaced. This put them in a great negotiating position, and at least once it resulted in them getting a deal that was very poor for the dealership (due to the dealer’s poor BATNA, e.g. without a deal then their end-of-quarter sales numbers would be unacceptable).

In IT, technical people tend not to be aware of BATNAs, and focus on absolutes instead. Do any of these sound familiar to you?

  • We cannot implement this identity management tool because we don’t have a unique source of truth. Users need to create a data governance board first and guarantee unique IDs.
  • We cannot upgrade our building network connectivity to 10 gig Ethernet because the total possible demand would exceed our pipe to our upstream network provider. First we need to replace our network backbone and run fiber and implement QoS.
  • We cannot proceed with incident management because our Help Desk is not ready to be the single point of contact for all user needs. First we need to train everyone in ITIL, replace our ITSM tool, and rebrand our Help Desk as a Service Desk.

All these responses are what I would call “cool-down” responses–responses that remove energy or motivation for improvement–or sometimes they even generate FUD.

One question to ask in each of these situations is, what is our BATNA? What would the world be like if we did not do anything? As examples:

  • (Identity management) Although it’s true there is no unique source of truth currently, if there’s not any identity management tool then identity information will continue to proliferate to the point that security is unmanageable. Having a tool, even one with lots of data problems, will also create an incentive to improve the data.
  • (10 gig Ethernet) Total possible demand is not the same thing as average daily use. Improving building network connectivity will help people on campus using on-campus services, and it will increase the likelihood of people being interested in funding an improvement to our network backbone.
  • (Incident management) If we don’t proceed with incident management now, we will never have the time to do anything with our Help Desk. They are overwhelmed and would not have time to go to ITIL training. Although replacing the ITSM tool would be very helpful, it is not strictly necessary for an incident management improvement and in fact implementing incident management may help people see why we need to improve our ITSM tool.

I think of this type of thinking as “absolute vs. relative thinking.” In absolute terms, sure–it would be great to have the technically superior option. But we don’t live in an absolute world. What can we do now to improve incrementally?

Another way I think of absolute vs. relative thinking is in terms of the “hill-climbing algorithm.” The hill-climbing algorithm points out a danger of relative thinking: incremental improvement may keep you from noticing a radically more effective way of doing things. The hill-climbing algorithm is part of why it’s still really important to pay attention to alternatives outside your way of thinking–but still thinking in terms of BATNA. Sometimes you need an interim incremental improvement as you start to work on a longer-term reinvention.