Reading time: 4 – 6 minutes
The McKinsey Mind: Understanding and Implementing the Problem-Solving Tools and Management Techniques of the World’s Top Strategic Consulting Firm by Ethan M. Rasiel
My rating: 4 of 5 stars
Worth reading. Especially if you are in consulting. I like the beginning of the book especially, and will be turning back to some of those pages for reference.
Thinking logically
The book starts strong by introducing “MECE: Mutually Exclusive Collectively Exhaustive.” I use it often in my teams. Think of it as building a decision tree, where you cover every option, and none are overlapping. Each branch in the tree also has more MECE sub-branches. When deciding or investigating something, draw the tree on a whiteboard, and walk everyone through the options, and sub-tree options until you have a decision, or clear actions to take. Very logical. Be sure to encourage other people to contribute to the branches, and if you are leading it, ideally you team will volunteer the branches, and then they have more commitment to the options.
Or, as Wikipedia says:
[MECE] says that when data from a category is desired to be broken into subcategories, the choice of subcategories should be
1. collectively exhaustive — i.e., the set of all subcategories, taken together, should fully characterize the larger category of which the data are part (“no gaps”)
2. mutually exclusive — i.e., no subcategory should represent any other subcategory (“no overlaps”)This is desirable for the purpose of analysis: mutual exclusivity avoids the risk of double counting information, and collective exhaustion avoids the risk of overlooking information.
Two areas for MECE thinking are in logic-trees and issue trees.
Logic trees help you identify components of a problem. Start at the 20,000 foot view and move progressively downward. You may want to build multiple trees, for instance by business unit (organizational hierarchy) and functionally (production, sales, marketing, etc.) to see which leads you to the next step, the hypothesis.
Form a hypothesis of what component of the logic tree may be causing the problem. Run it by the Quick and Dirty Test: ask what assumptions you are making that must be true. Are any false? If it passes the QDT, gather data and do analysis to disprove it. This is the same as the scientific method. If you fail to disprove it, you may be on to something. Predict what could happen if the identified root cause was changed.
Issue trees let you rigorously test the hypothesis. They are different from logic trees. Logic trees are a hierarchical grouping of elements. Issue trees are the series of questions or issues that must be addressed to support or disprove a hypothesis. It becomes you roadmap for analysis.
Presenting
Present with the conclusion at the start. This was a good lesson. Do not use inductive reasoning to build up from details into a specific conclusion for your audience. They may already agree with it. You would then waste their time. Instead make you conclusion, and progressively drill into details, broadly covering each level before drilling down further. Stop/skip forward if they do not need the convincing. (A refresher on inductive/deductive reasoning).
Presentations are all about getting buy-in. It is important to “pre-wire” the meeting so that there are no surprises, and people already know your conclusions. The act of pre-wiring will identify gaps you need to work on, or build allies for you proposal.
Interviewing clients/stakeholders is a common activity I have done at ThoughtWorks. The authors advised scheduling time with people, and sending them an agenda. This lowers their apprehension of why consultants want to talk to them. Also at the end, during small talk before you walk out, ask “is there any thing else we did not cover that you think we should?” You’ve built rapport by now. Their answer can uncover important, previously unmentioned issues.
Note: as a software engineer, I appreciate the MECE thinking style for its logic. Also, it is the exact way we approach performance tuning an application. Think about the logic tree of slow spots. Build a hypothesis. Test it by profiling the running program under load. Let the data of time spent in each component show the root cause.