|
|
||
|
Last week, Moshe Vardi gave a talk called “Graduate Students, Marshmallows, and Academic Jobs”. Cute title, I thought, but the marshmallow part wasn’t just there for cuteness, it was an integral part of the talk. Vardi was referring to Walter Mischel’s 1972 Marshmallow experiment at Stanford: take a kid, offer them a marshmallow, and tell them that if they resist the temptation of eating it until you come back in the room, you’ll give them a second one. Repeat with another kid, and another. Related Posts:If you spend any time on this site, you know I’m pretty big on engaging others into solving problems. That’s because, in my experience, teams are smarter than individuals. But there’s also value in thinking about how you compose your teams. While experts are really helpful when you’ve already made some progress in your analysis (i.e. on the right side of your logic trees), they are not so helpful at the beginning. That’s because they’re not ‘dumb’ enough. Related Posts:Jonah Lehrer writes a thought-provoking piece in this week’s New Yorker. Here are my take-aways from it. Don’t work by yourself: enlist othersLehrer’s conclusion is similar to ours: you’ll be more creative if you enlist other. In his words:
Don’t be afraid to criticizeWhile brainstorming remains the de-facto group creative technique in most organizations, it is flawed. Here is Lehrer again:
When Charlan Nemeth, a professor of psychology at UC Berkeley organized teams of students in various groups to tackle the same issue, she confirmed this:
Nemeth continues:
And furthers:
To drill down into the value of free association, which, in essence, is what brainstorming fosters, Lehrer turns to David Palermo and James Jenkins:
By “tweaking” the mechanism, you can get significantly better results:
In the end, you just can’t focus on not criticizing. In the words of MIT’s celebrated linguist MorrisHalle:
Work with people you are familiar with and that have a different skill setSo, if focusing on positive interaction doesn’t do the trick, what does? Lehrer turns to Brian Uzzi, a sociologist at Northwestern, who has spent his career trying to find what the ideal composition of a team would look like:
Lehrer continues:
Connect with your teammates oftenSo, successful creative teams mix people with different skill sets that have some levels of affinity. But that’s not enough. Lehrer cites Isaac Kohane, a research at Harvard, who looked at the impact of groups on the quality of publications:
Kohane continues:
This echoes Steve Jobs’s belief that the best meetings happened by accident, in the hallway or parking lot.
In the end, focus on interacting often and with the right people, not how positively you interactLehrer then makes an argument for the better physical layout of teams:
And he concludes:
Related Posts:My former advisor and good friend Pol Spanos has a great saying: “intuition is a good servant but a terrible master”. It’s not because you’re good somewhere that you’re good everywhere Sometimes your knowledge and skills will transfer from your subject of expertise to another. Just like the aerobic capacity that, say, a cyclist develops on the bike might serve him to also run well, our use of logic and other tools for solving problems, for instance, will transfer well from one subject matter to another. Related Posts:Whenever you’re facing a new, complex problem to solve, step back and reflect on your general approach from a philosophical point of view: are you aiming at solving it completely straight from the beginning or are you integrating a learning curve? Perhaps the most complicated problem ever solved was to put a man on the Moon, and maybe we can learn something from NASA’s approach. Related Posts:Issue trees, logic trees, “how” trees, “why” trees, decision trees, fact trees, hypothesis trees… Your favorite consultancy has its own terminology and so does the rest of the world. Unfortunately, they don’t coincide, so here is an attempt at making things clearer.
The short answer is that there isn’t a clear nomenclature that everyone uses. At Accenture, we called both “why” and “how” trees “issue trees”. That’s because both types raise and answer questions or issues—we used the two terms interchangeably. McKinsey talk about “logic trees” in the same way.
Then you’ll hear people talk about hypothesis trees and fact trees or data trees. The first ones are useful to uncover the root causes of a problem and the other two help identify potential solutions. But that, in my opinion, is misleading: indeed, both hypotheses and facts are present in all types of trees, so calling a tree by the type of elements it contains doesn’t really help. Instead, I think it makes more sense to call them by what they do.
Call your tree what you want it to doSo here is what I think makes the most sense:
1. There are two types of trees: “why” and “how”. A “why” tree is a diagnostic tree: its objective is to identify the root causes of the problem. A “how” tree is (almost) a decision tree: its objective is to identify various ways in which one can solve the problem. (A “how” tree is not entirely a decision tree because, these, usually, end up with the expected value of each branch; that is not a common feature in a “how” tree.)
2. Both types of trees are logic trees or issue trees. The aim of both types of trees is to bring logic in the problem, helping us be MECE, so it makes sense to call them logic trees. But both types of trees are also question- (or issue)-based, so it makes sense to call them issue trees as well.
3. Both trees raise questions and include hypotheses. Furthermore, both trees spell out the analysis needed to test these hypotheses and uncover facts. When asking “how do I get from NYC to London?”—which is a “how” tree so, one would think, a fact/data-tree—I need to make hypotheses. By plane, by boat, by submarine, swimming, etc. are all possible solutions and, indeed, must be included in the tree but until I have validated that they are indeed potential acceptable answers to my original problem they remain hypotheses.
4. You can’t mix “why” and “how” questions in one same tree. Because a tree’s functionality is either to understand the root causes of the problem or to identify potential ways to solve it but not both at the same time, you can’t have both types of questions in the same structure. I am not saying that you should answer only why or how questions in your analysis; indeed, in general, a complete analysis requires to first develop a “why” tree and then develop a “how” tree. I am saying that both these types of questions are important, but they don’t come at the same time in the analysis. So, first, you understand the real problem (e.g. do I have a headache because I’m dehydrated, because I have brain cancer, because of another reason) then you solve it (e.g. I’ll take an Advil vs. I’ll start chemotherapy).
 Use the right type of tree for the right action. Related Posts:You can approach most complex problems from various angles. Each one might give you an approximate answer; by comparing these you can estimate the overall answer. Approach your problem from different anglesWhen I interviewed to join Accenture, I went through a series of case interviews. If you’ve heard of strategy consulting, you’ve most certainly have heard of these: the interviewer asks you a seemingly complicated question and wants you to show him/her how you get to the answer. Traditional case questions include: how many golf balls can you fit in a Volkswagen? How many gallons on white paint are sold yearly in the US to paint residential houses? How much does it cost to run a (successful) presidential campaign? Etc. Related Posts:Say “root cause analysis” in any cocktail party and you’ll hear back “Ishikawa diagram”. Ok, that might work only with cocktail parties that cater to engineers, but an Ishikawa diagram is the de-facto tool of many to diagnose a problem. So let’s look how it differs from our de-facto diagnosis tool: the “why” issue tree. Related Posts:
Tom and Ray Magliozzi—the Tappet Brothers—are MIT-educated mechanics that take calls from listeners and help them solve their car issues while making jokes about themselves, the caller, and others. The premise is straight-forward: callers describe the symptoms of their automotive issues and the hosts attempt to diagnose the malfunction and recommend solutions. Related Posts:We’ve talked about how thinking in a mutually exclusive and collective exhaustive way is central to effective problem solving. But this is such an important concept that we should talk about it more. First, be CEME, not MECE. In fact, be CEME-CEME-CEME To solve a problem in a MECE way you need to consider all possible solutions exactly once. To do that, it is usually simpler to first think about all possible solutions and then to arrange them so that you only consider them once. So it’s really about being CEME rather than MECE. Related Posts: |
||
|
Copyright © 2012 Powerful Problem Solving - All Rights Reserved Powered by WordPress & Atahualpa |
||
