Close

June 14, 2012

Don’t overdo that MECE thing – independent and collectively exhaustive

For those of us discovering the MECE concept (mutually exclusive and collectively exhaustive), it can be oh-so-attractive: finally, a way to organize my thoughts! It’s simple and elegant. The acronym is even catchy. Why didn’t I hear of this before? This is it! Douglas Adams was wrong: 42 isn’t the answer, MECE thinking is!

And, to be fair, forcing your thinking to be MECE usually is an extremely useful tool. But not always. In fact, many times, when we say MECE, we really mean ICE (independent and collectively exhaustive).

Usually you want your answers to be independent and collectively exhaustive, not MECE

ME stands for mutually exclusive; CE stands for collectively exhaustive. The spirit of the guideline ‘think MECE’ is: ‘no overlaps (ME), no gaps (CE)’. In this context, ‘no overlaps’ is a measure of efficiency: if you’ve already thought about something once, don’t consider it again because it is a waste of effort.

Now, strictly speaking, events are mutually exclusive if the occurrence of one precludes the occurrence of another. But in most cases this preclusion isn’t what you should be after. Consider the standard example of increasing the profitability of your company:

MECE vs. ICE – Increasing revenues and decreasing costs are independent—rather than mutually exclusive—actions

MECE vs. ICE – The initial breakdown of a profitability issue tree / issue map shows two independent (rather than mutually exclusive) options

This is the school-case illustration of a MECE-thinking pattern trumpeted by management consultants across the globe. Yet, strictly speaking, it isn’t MECE.

Of course increasing revenues is one way to increase one’s profitability; so is decreasing costs. In fact, they are the only two ways to do so, so this framework is CE.

But it isn’t ME: you can attempt to increase revenues while also attempting to decrease costs. Doing one usually doesn’t preclude you from doing the other—for instance, you can look for new clients and reduce your production costs all at once. So these branches aren’t mutually exclusive, they are independent.

(Here we don’t mean independent in a probability-theory meaning way—two events are independent if the occurrence of one doesn’t affect the probability of occurrence of the other. We mean it as ‘distinct’: elements of branches don’t appear in other branches.)

Now you might object that with limited resources you might be able, at any given time, to pursue just one avenue, which makes your elements mutually exclusive. That’s fine, but that’s just a technical limitation; it shouldn’t be a philosophical standpoint of yours, because what should interest you isn’t only solutions that would each require all of your resources.

To be sure, let’s think of a truly MECE framework to think about how we can increase our profitability.

A truly MECE breakdown for profitability

The elements of issue trees / issue maps can be forced to be truly mutually exclusive

By adding ‘only’ in my branches, I’m bringing the preclusion aspect: if I choose one, I can’t also pursue the other. As a result, these branches are indeed truly mutually exclusive, not just independent.

Now is this issue tree really better than the first? What have we gained from adding this preclusion clause? Not much. In fact, I’d contend that we’ve lost something: we’ve lost the ability to solve our problem with a combination of elements coming from both branches.

The spirit of  ‘be ME’ is ‘no overlaps’. But you achieve that with independent branches, whether they are truly ME or not. So you don’t want your thinking to be MECE, you want it to be ICE, or, well, rICE—really ICE.

Sometimes you want to be ‘non ME’

“We need a team with a MECE skill set.” No you don’t. Again, there’s no problem with the CE part. It’s the ME part that clashes: so if someone on your team speaks one language, will you preclude anyone else that also speaks that language? How are you going to communicate? You certainly don’t want people with mutually exclusive skills.

Quite the contrary. You would hope that everyone spoke the same language. Likewise, if your team is a bunch of people building a bridge, you’d hope that more than one person knows about engineering, so that they can, for instance, check each other’s maths. Redundancies can be desirable, or, indeed, necessary.

Take the late Berkeley professor Martin Landau’s particularly colorful example: he once sat on a plane that was forced to make an emergency landing. After they landed safely he asked the pilot what happened. It turned out that the rudder was defective. So Landau asked how the pilot managed to land the plane. “He replied that […] he had been able to compensate for the impairment of the rudder by utilizing additional features of the aircraft. There were, he said, safety factors built into all planes.” (See Landau, Martin. “Redundancy, Rationality, and the Problem of Duplication and Overlap.” Public Administration Review 29(4) (July-August 1969): 346-358.)

And that brings us to a favorite saying of my boss, professor Paula Sanders: (paraphrasing) we like redundancies, as long as they’re intentional.

So, in summary, while consultants speak about MECE thinking, what they mean is ICE thinking. But the difference is only technical, so use whichever acronym works better for you (ICE, of course, is cooler). And recognize that in some situations, MECE/ICE isn’t desirable.