Understanding potential of mechanism design

People have been trying to model how decisions get made for a long time.  In western history, the earliest person we know of to try and model decision making was Aristotle in his studies on ethics, probably around 330BC; similar but independent models were put forward by mathematicians and philosophers in China and India. Arab scholars – who through their trade networks had access to all three bodies of work – made significant advances during medieval times, and their work was picked up by Italian and French scholars during the Renaissance.

But since the end of WWII, the study of decision making has truly exploded, giving rise to a growing number of methods and disciplines: operations research, game theory, neural networks, and so on. There is even something called the theory of elevators, which attempts to model why it is that elevators in tall office buildings tend to clump up.  Yes, this really is a thing.

This explosion of decision study was motivated in large part by the advent of digital computing, first because computers made it possible to model and simulate in ways never previously available, and second because of the desire to build systems that were capable of making high quality decisions.

One of the newest of these decision-making disciplines is something called mechanism design (MD).  It closely resembles game theory, from which it derives.  The difference is that, with game theory, you start with a decision-making model, or “mechanism” and study how people (or computers) make decisions that may or may not lead to desirable outcomes.  In MD, you start with the desired outcome, and then try to come up with a mechanism that will get people or computers to make decisions that lead to that outcome.

Why is mechanism design important?

There are many possible applications for mechanism design, and it’s something senior business leaders are paying attention to.  The idea for writing this article, for instance, was sparked by a query from Shirine Khoury-Haq, COO of the Lloyd’s of London Insurance market, who is actively interested in how Lloyd’s might leverage MD to do a better job of delivering value to its customers.

But to me, the greatest potential for mechanism design lies in the core delivery method for business transformation, regardless of industry.  Any time you change the way a business operates, you need to not only specify the new process you want a business to follow, but KPI’s to measure that process, and people to be accountable for its performance.  Coming up with KPI’s to motivate the decisions you want people to make is notoriously difficult, human intellect is notoriously bad at it, and the results of making a mistake can be notoriously disastrous. Consider the following real-world examples from recent history:

When Netflix launched its new streaming business, they quite sensibly wanted to get people to migrate to this new fulfilment channel, as it was far cheaper to operate than their traditional DVD-by-post channel.  So to set the right incentive, their head of sales was given a huge incentive target to get people to switch to the new platform.  To motivate his customers to switch, he hiked the price of their DVD-by-post business by something like 60% in 2011.  The exec in question blew out his numbers and enjoyed a massive bonus, but Netflix as a whole lost a million subscribers in that quarter, and their stock dropped 70% in that year.  Obviously they have since recovered, but it was a huge disruption.

At Bank of America, I think this was in also 2011, a new head of retail banking was incentivized to improve the per-person profitability of the mass market segment, so quite straightforwardly he instituted a monthly $5 charge for any mass market customer who used their ATM cards in that month.  The individual profitability of the segment soared, and the executive exceeded his target, but the bank as a whole lost hundreds of thousands of customers, about 30% of their value, and created a brand image they still haven’t recovered from

At a leading bank in Mexico, the team responsible for selling credit cards was, unsurprisingly, compensated based on the number of cards they sold, and had solid record of exceeding their targets for several years running, but the bank was losing money on their card business.  Unable to figure out why, they commissioned an investigation that uncovered that over 30% of the cards that were sold were never even activated, and the bank was spending an enormous amount of money producing and issuing cards that never got used

All these examples share a common chain of events.  An enterprise defines a strategic objective, and designates an executive to be accountable for achieving that objective. The executive implements a set of changes to how the enterprise sells and delivers, and these changes are hugely successful in achieving the objective the executive was asked to deliver.  Then, a series of unintended and unanticipated consequences produce adverse results far in excess of any positive benefit that might be realized from achieving the original objective.  It is worth thinking about this in the overall context of business transformation.  The generally accepted method for business transformation tends to be as follows:

Define a set of outcomes, typically measured by KPI’s, you would like a business to achieve

Make someone accountable for achieving those KPI’s

Understand the capabilities a business would need to achieve the KPI’s

Identify the changes in business process and/or technology needed in order to bridge the gap between current capabilities and required capabilities

Implement the identified changes

The important thing to note is that defining the desired outcomes is the very first step.  This means, if you get it wrong (as people did in our real-world examples), not only do you have to deal with huge set of negative consequences, but you have just spent a huge amount of time, money, and opportunity cost to achieve those consequences.  Also, it is worth noting that these mistakes were not made by idiots; the decision makers in the above examples were all seasoned executives who had reached their positions via a long track record of successful business decisions.  Designing good KPI’s is really hard, and has always been more art than science.

How can MD help?

So how would MD help us do a better job of avoiding real-world business disasters like the one above?  There are already ways of studying and modelling decisions.  Game theory, for instance, starts with the decision model itself, and then tries to predict how rational actors are likely to behave.  Behavioral economics looks at how human behavior tends to deviate from rational decision-making in predictable and repeatable ways.  MD builds on these disciplines, but rather than using the decision model as the starting point, MD starts with the desired outcome, and then tries to come up with a model in which rational (or to borrow the title of a book by Dan Ariely, predictably irrational) people are likely to make decisions that result in the desired outcome.

Of course, as our real-world examples show, the ability to come up with a great decision model is useless, or perhaps actively harmful, if we pick the wrong objective to begin with.  This is where MD really shows its potential.  Because it starts with the desired outcome rather than with the constraints of a known model, it should be possible to build MD-based test harnesses.  The idea is that using a combination of simulation and machine learning, it should be possible to actually test and identify at least some of these KPI train wrecks before implementing them in the wild.  Preventing even one of these would make the investment worthwhile.

What next?

This is a new idea; it will need to be tested and prototyped before anyone would consider trying it in the context of a real enterprise transformation.  The next step will be to identify a suitable prototype use case; one in which we could deliver measurable value from trying this idea in a tightly focused and even more tightly scoped way.

This is something that I and my company will be exploring further. If you know of someplace where this approach might prove useful, or if you would like to work with us to explore the idea further, please don’t hesitate to get in touch.

-photo courtesy of Digital Trends