A foundational strategy pattern for analysis: MECE

As lists are the raw material of strategy and technology architecture, MECE list-making is one of the most useful tools you can have in your tool box.

By Eben Hewitt
October 25, 2018
Architecture Architecture (source: Pixabay)

MECE, pronounced “mee-see,” is a tool created by the leading business strategy firm McKinsey. It stands for “mutually exclusive, collectively exhaustive,” and dictates the relation of the content, but not the format, of your lists. Because of the vital importance of lists, this is one of the most useful tools you can have in your tool box.

The single most important thing you can do to improve your chances of making a winning technology is to become quite good at making lists.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Lists are the raw material of strategy and technology architecture. They are the building blocks, the lifeblood. They are the foundation of your strategy work. And they are everywhere. Therefore, if they are weak, your strategy will crumble. You can be a strong technologist, have a good idea, and care about it passionately. But if you aren’t practically perfect at list-making, your strategy will flounder and your efforts will fail.

That’s because everything you do as you create your technology strategy starts its life as a list, and then blossoms into something else. Your strategy is, at heart, a list of lists. Thinking of your work from this perspective is maybe the best trick to creating a sane, organized, productive context for your work. Let’s talk about lists for a moment.

There are two parts to a practically perfect list: it must be conceived properly, and it must be MECE, which we will define in a moment.

In a properly conceived list, two things are crystal clear:

  • Who the audience is

  • Why they care

You can determine who your audience is by asking the following key questions:

  • Upon reading this list, can the audience make a decision they could not make before having the information in the list?

  • Upon reading the list, can the audience now go do something they could not have known to do before?

These are the two reasons to bother creating any kind of information in a strategy. In this context, there is little point, time, or patience for a document that merely helps a general audience “understand” something. Your lists must be lean. That means making them directive toward work that someone will go and do, or providing the data that allows a decision-maker to decide the best course of action. The RACI (responsible, accountable, consulted, and informed) chart is a list. It answers the question for the project team of who is assigned to what role so that everyone knows who is in charge of what, who is the decision-maker for what, and who is doing the work, and if someone sees his name on the list with an “R” by an item, he can go do that work. The stakeholder list is primarily for the project manager. It lets him decide whom to include in what meetings and whom to contact for certain questions. But if these, and all the many other lists you create as part of your technology strategy, are not MECE, your building blocks will be weak and your strategic efforts will crumble. Let’s look at some examples to make this clear.

This formula is MECE:

Opportunity Cost = Return of Most Lucrative Option – Return of Chosen Option

This formula is MECE:

Profit = Revenue – Cost

Revenue – Cost = Profit is MECE. That’s because together those three items make a complete thought, divide across lines that don’t overlap, and nothing is left out. All of the parts of the money are accounted for within the same level of discourse. It is nonsense to leave out “Revenue” and simply state “– Cost = Profit.” There are only two ways to increase profit: increase revenue or decrease costs. Recognizing the formula as MECE can help remind you to address both the cost and the revenue aspects in your strategy.

This list is MECE:

Spades, Diamonds, Hearts, Clubs

This list is MECE:

Winter, Spring, Summer, Fall

Each entry in the list is mutually exclusive of every other one. There is no overlap in their content. Winter ends on a specific day of the year, and then the next day is the start of spring. Every date on the calendar is, with certainty, part of one and only one season. There is no card in the deck that is part Spades and part Diamonds.

The elements in the list, when taken together as a collection, entirely define the category. No item is left out, leaving an incomplete definition. Thus, the list is collectively exhaustive.

This is not MECE:

North, South, West

It’s not collectively exhaustive. It fails to include East, and is therefore an improperly structured list.

Consider the following list:

Revenue – Cost = Profit. Free Cash Flow.

This is not MECE because “free cash flow” is not at the same level of discourse as the other items. It is true that free cash flow is an important part of any public company’s earnings statements. But that is unrelated to this equation, even though they appear to all be in the category of “stuff about money in a company.” That’s a weak category for a list because it’s not sufficiently directed to an audience for a goal.

What about this one:

Internal Stakeholders, External Stakeholders, Development Teams

This isn’t MECE because “internal” and “external” divide the world between them. Development teams are a subcategory of internal stakeholders for a technology strategy.

Elements that are subcategories of other elements must not be included. Consider this list:

North, South, Southwest, East

This is not MECE because it leaves out one of the elements, West, and so is not collectively exhaustive. It also includes Southwest, which is not topologically on the same plane as the other elements. It dips into a lower level of distinction, as in the “free cash flow” example. Southwest is contained within the higher level of abstraction of South. So, the elements on this list are not mutually exclusive.

These examples are straightforward (obvious) in order to illustrate the point. But they share an attribute that precious few lists in the world have: they are enums by definition. It is clear what goes on the list and what doesn’t. Most things in life are not this simple.

Consider the following list of departments or job roles in a dev shop:

  • Software Developers

  • Architects

  • Analysts

It’s not exhaustive: we left out testers, and other roles depending on your organization, such as release engineers, database administrators, project managers, and so on. To test if our list is MECE, we must ensure we have pushed ourselves to think of all the relevant components that make up that category.

Remember the first rule: know your audience. Your longer, more detailed lists should be kept for your private analysis to help you reach your conclusion, or reserved for lists of things to be done in the project, such as a work breakdown structure. But you don’t want long lists when working with executives because they have executive ADD. Even though you’ll worry that you’re leaving out crucial things, just give them the summary, but make it MECE. Then you can reveal only the headline: the impactful conclusion that makes a difference to your audience.

Consider this list of age groups:

  • 0–5
  • 6–10
  • 11–15
  • 16–25
  • 26–35
  • 36–45
  • 46–54
  • 55–65
  • 66–75
  • 76 and above

This list is technically MECE. None of the categories overlap, and the sum of the subcategories equals the whole category. It might be OK for a data scientist doing customer segmentation. But probably not even then. It’s too fine-grained and low-level, so it’s not very good for strategy work. You need to keep your visor higher; look more broadly to horizons to distill the few things that really make an impact and drive change. It’s more analysis and art than science. So, even though the list is technically correct, you will lose your audience with details like this, and you can find ways to cluster and consolidate them better, along the contours of a real difference or divergence, depending on your own organization’s products, services, and markets.

Let’s look at a quick example of how to apply this idea of MECE lists.

Applying MECE Lists

Imagine you’ve been enlisted to create a recommendation to the CTO for a new database system to replace your legacy system. If you merely state the single database system you want to buy, any responsible executive will reject your recommendation as heavily biased, poorly considered, and potentially reckless.

So, we want to first consider our audience, with empathy, and always ask: who is this for, and what do they need to know either to make a decision or to do the thing in question?

Your deciding audience wants to know they have been given a clear, thorough, thoughtful, unbiased proposal and that they are not being manipulated. In our empathy, we realize everyone has a boss, and that no one in a company of any size just makes a decision in a vacuum. It’s not the CTO’s money. So your CTO must in turn answer to his bosses for the system he selects, and is accountable for its success. Your recommendation will be successful if you give your deciding audience a list of MECE lists.

But the list of database system choices is potentially in the thousands. It is impossible to include all of them, and impractical and unhelpful to include even 20 of them. Being ridiculous is not what is meant by “collectively exhaustive.” So, first we’ll create a list of criteria to help us make our final list MECE. Include three or five factors on which you will base your selection and write those down, as they become part of your recommendation, too. You’re showing your audience how you came to your conclusion, just like showing the long math in school: you’re not just giving the answer, but providing the steps by which you arrived at it. This helps the audience follow your story and agree with your conclusion.

Then we’ll perform a survey of the landscape, including systems that meet the criteria. Include open source alternatives as well as commercial vendors. We might have a few of each. If we recommended only the one we already wanted, we would miss the chance to perform the analysis, squander an opportunity for learning that might change or augment our view, and lose confidence in our choice and ability to execute. Including only our one recommendation would certainly and immediately invite considerable skepticism and questioning about the alternatives and how we considered them.

So make a MECE list of options. The list is exhaustive according to your chosen criteria. Say you have 8 or 10 options in your list of “all the database systems considered.” Say so in your recommendation. It shows you’ve done your homework and suggests less bias and a more data-driven, analytical approach. Then say you narrowed it down to five options to present. That list includes two you reject and state why. You have a list of three options remaining.

For each element on your list of remaining recommended vendors, create another list of lists: “advantages, disadvantages” (that’s a MECE list itself). The elements in each list should be something about the technology, particularly: 1) the functional requirements such as key features that distinguish it from the competition, and 2) nonfunctional requirements such as performance, availability, security, and maintainability (that’s a MECE list, too). Consider these systems also from the business perspective: ability to train the staff, popularity/access to future staff, ease of use, and so forth.

Then from the list of acceptible candidates, present them all, ranked as good, better, and best. (The good, better, best list is MECE too, because you wouldn’t improve its MECE-ness by adding a “horrible” option: the category or name of this list is the acceptable options, which presumably does not include “horrible,” and therefore unusable ones.”)

The good option might be the one that is acceptable to you, and is low cost but not optimal. The best one might be the most desirable but highest cost, and so on.

Organizing your list this way makes an executive feel more confident that you have an understanding of the entire landscape, aren’t too biased, and show your reasoning. That makes your recommendation stronger.

Getting good at quickly checking if you are thinking in lists and then making sure they’re MECE has the pleasant side effect of helping build your powers of analysis. Think of MECE as a lens. Every time you make a list, immediately test if it is MECE. Use it as a heuristic device with your team: inspect your list with the team as you’re meeting, be sure to ask if the current list you’re working on is MECE, and then refine it. Your team may groan at first, but they will gradually start to see the value, and then they will not be able to imagine how they ever lived without it.

Make your work lists of lists, and make those lists MECE. Your recommendations have a better chance of getting accepted, supported, and executed upon. And you will create more power for your organization and your team.

Post topics: Software Architecture
Share: