Home > Poslovno svetovanje > Management > Ethan M. Raisel: The McKinsey Way


McKinsey-ites call their assignments or projects “engagements”. On an engagement, a McKinsey team will search for the “key drivers” in their quest to “add value”.

The root of all management consulting is the application of objective analysis by dispassionate outsiders.

The Mckinsey Way of Thinking about Business Problems

Building the Solution

McKinsey exists to solve business problems. The consultants who succeed at McKinsey love to solve problems. A part of you is always asking, “Why is something done this way? Is this the best way it can be done?” You have to be fundamentally skeptical about everything.

When team members meet for the first time to discuss their client’s problem, they know that their solution will be:

  • Fact-based  
  • Rigidly structured  
  • Hypothesis-driven

Facts are the bricks with which you will lay a path to your solution and build pillars to support it. Don’t fear the facts. Facts bridge the credibility gap. Hiding from the facts is a prescription for failure — eventually, truth will out.

MECE (pronounced “me-see”) stands for “mutually exclusive, collectively exhaustive” and it is a sine qua non of the problem-solving process at McKinsey. MECE structures your thinking with maximum clarity (hence minimum confusion) and maximum completeness. When you think you have determined the issues, take a hard look at them. Is each one a separate and distinct issue? If so, then your issue list is mutually exclusive. Does every aspect of the problem come under one (and only one) of these issues — that is, have you thought of everything? If so, then your issues are collectively exhaustive.

A good McKinsey issue list contains neither fewer than two nor more than five top-line issues (of course, three is best).

Solving a complex problem is like embarking on a long journey. The initial hypothesis is your problem-solving map.

The initial hypothesis (IH), the third pillar of the McKinsey problem-solving process, is the most difficult to explain. The essence of the initial hypothesis is “Figure out the solution to the problem before you start”. When generating an initial hypothesis, you don’t need all the facts, just enough to have a good overview of the industry and the problem.

Trying to confirm a hypothesis you can use what McKinsey calls the issue-tree. In other words, you start with your initial hypothesis and branch out at each issue. When you’ve completed your issue tree, you have your problem-solving map. That’s the easy part. The difficult part will come when you have to dig deep to prove your hypothesis.

So, when your team meets to come up with an IH let a thousand flowers bloom. Everyone should have his or her own ideas and initial hypotheses. Everyone should be prepared to push a teammate’s thinking and test each new idea.

Sometimes a business problem will land on your desk and you will be told to solve it. Fair enough. But before you go rushing off in any particular direction, make sure you’re solving the right problem — it may not be the one you were given.

Developing an Approach

McKinsey, like every other consulting firm, has developed a number of problem-solving methods and given them fancy names:

  • Analysis of Value Added,
  • Business Process Redesign,
  • Product-Market Scan,
  • and so on.

We made frequent use of an analytical framework called Forces at Work. The technique involves identifying the client’s suppliers, customers, competitors and possible substitute products. We then list all the changes occurring in each of the four categories. What impact — positive or negative — could these have on our client?

The tools may be the same from problem to problem, but you have to apply them. Even though your initial instinct may be — and probably is — right, take enough time to verify your gut with facts.

Avoid the temptation to view your initial hypothesis as the answer and the problem-solving process as an exercise in proving the IH. Keep an open and flexible mind. Don’t let a strong initial hypothesis become an excuse for mental inflexibility.

No matter how brilliant, insightful, and original you may feel your initial hypothesis to be, you must always be prepared to accept that the facts may prove you wrong. If they do, adjust to the facts. Don’t try to pound them into your framework like square pegs into round holes.

If I can do only three things, I’ll do the three biggest.

As a consultant, you bear the responsibility for knowing the limitations of your client; if your client is your own employer — or your own business — that responsibility is doubled.

An initial hypothesis is not a prerequisite for successful problem solving. Having one will help organize and forward your thinking, but if you can’t come up with one, don’t despair. Put together enough facts, combine them with some creative thinking, and you will come up with a solution.

The road of problem solving is often strewn with obstacles. The biggest obstacle — the troll guarding the bridge — is politics. Businesses are full of real people. When you look at the boxes on an organization chart, you are really looking at people. When you move those boxes around, you change someone’s life. Sometimes, however, one powerful faction in an organization calls in McKinsey against the wishes of another powerful faction. That’s when trouble arises, as we found out.

Several options to pick from when confronted by a problem that seems too difficult to solve. Redefine the problem. Tweak your way to a solution. Work through the politics. To work through the politics, you must think about how your solution affects the players in an organization.

80/20 and Other Rules to Live By

A number of rules that McKinsey consultants have found useful when trying to solve problems.

80 percent of your sales will come from 20 percent of your sales force; 20 percent of a secretary’s job will take up 80 percent of her time; 20 percent of the population controls 80 percent of the wealth.

“How do I boost my profits?” “Where do your profits come from?”

DON’T BOIL THE OCEAN Work smarter, not harder. There’s a lot of data out there relating to your problem, and a lot of analyses you could do. Ignore most of them. “Don’t boil the ocean” means don’t try to analyze everything. Be selective; figure out the priorities of what you are doing.

Engineers learn something called the Square Law of Computation. It states that for every component of a system — for every additional equation in a problem — the amount of computation required to solve the system increases at least as fast as the square of the number of equations. In other words, if the complexity of your problem doubles, the time it takes to solve it quadruples — unless you make some simplifications.

Focusing on the key drivers means drilling down to the core of the problem, rather than picking the whole problem apart piece by piece, layer by layer.

Syntactical foibles aside, “key drivers” is a very powerful concept. It saves you time. It saves you effort. It keeps you from boiling the ocean.

THE ELEVATOR TEST Know your solution (or your product or business) so thoroughly that you can explain it clearly and precisely to your client (or customer or investor) in 30 seconds. If you can do that, then you understand what you’re doing well enough to sell your solution.

PLUCK THE LOW-HANGING FRUIT Sometimes in the middle of the problem-solving process, opportunities arise to get an easy win, to make immediate improvements, even before the overall problem has been solved. Seize those opportunities! Don’t wait! Solving only part of a problem can still mean increased profits.

MAKE A CHART EVERY DAY During the problem-solving process, you learn something new every day. Put it down on paper.

HIT SINGLES You can’t do everything, so don’t try. Just do what you’re supposed to do and get it right.

“Don’t try to knock the ball out of the park. Hit singles. Get your job done — don’t try to do the work of the whole team.” Very few people have the brainpower and energy to be a one-man show all the time.

At McKinsey, it is said that you are only as good as your last study. If you have one “bad” engagement, all your hard work before that doesn’t matter.

LOOK AT THE BIG PICTURE Every now and then, take a mental step back from whatever you’re doing. Ask yourself some basic questions: How does what you’re doing solve the problem?

DON’T ACCEPT “I HAVE NO IDEA” People always have an idea if you probe just a bit. Ask a few pointed questions — you’ll be amazed at what they know.

The Mckinsey Way of Working to Solve Business Problems

Selling a Study

The selling process at McKinsey differs from that of most organizations because, as any McKinsey-ite will tell you, the Firm doesn’t sell.

No senior McKinsey directors make cold calls at the offices of Bill Gates and Ted Turner asking if they have problems they want solved. The Firm does not run ads in Forbes or Barron’s advertising 50 percent off telecommunications consulting.

The Firm waits for the phone to ring. And ring it does, not because McKinsey sells, but because McKinsey markets. The Firm produces a steady stream of books and articles. McKinsey also publishes its own scholarly journal, The McKinsey Quarterly. The Firm invites (and gets) a lot of coverage by journalists. McKinsey maintains a vast network of informal contacts with potential clients as well. McKinsey consultants also address industry conferences.

These efforts could not be construed as selling, but they make sure that the right people know the Firm is there. That keeps the phones ringing.

Assembling a Team

The challenge for the ED is to balance the desires and budget constraints of the client with the limits of the team. The ideal synthesis of these two opposing forces is a project that a team of four to six consultants can complete in three to six months and that will produce tangible results for the client.

At McKinsey, you never walk alone — or, at least, you never work alone. Everything at the Firm happens in teams, from front-line work on client engagements all the way up to firmwide decision making.

The Firm has developed a number of strategies for putting together and maintaining high-performance teams. Proper team selection varies from problem to problem and client to client. If you have mountains of complex data that you need to decipher, then you want the two or three best number crunchers. If you are managing a big reorganization during which many sensitive decisions will have to be made, you would prefer to have someone on your team with good people skills and experience in implementing change.

A typical McKinsey team works at the client for 10 to 14 hours a day, plus a day over the weekend at the office. So, when managing your team, be selective with team-bonding activities. Take your team’s temperature. Talk to your teammates. Steer a steady course. If you change your mind all the time about the team’s priorities or the analyses you’re doing, your team will quickly become confused and demoralized. Let your teammates know why they are doing what they’re doing. People want to feel that what they are doing is adding value to the client. Treat your teammates with respect. When the going gets tough, take the Bill Clinton approach.

Managing Hierarchy

I cannot imagine a flatter organization than McKinsey. I could, as an associate, walk into my ED’s office without an appointment and talk to him about our study.

At the same time, McKinsey has a definite chain of command. The directors and, to a lesser extent, the partners make decisions about the direction of the Firm, and the EMs, associates, analysts and support staff live with them.

McKinsey has another, unofficial hierarchy: one based on experience and credentials — how good you are (or are perceived to be).

Use a well-structured e-mail or voice mail to convey the information.

In a meritocratic organization at least, you can assert your equality until shown otherwise — until someone tells you.

Doing Research

The McKinsey problem-solving process begins with research.

Maybe other people in your field, in another division or another company, have seen the same problem already — find out who they are and get to know them.

McKinsey keeps an electronic database called PDNet containing reports from recent engagements and internal research.

These include an excellent business library that holds every business book or magazine you care to mention; it also has access to all the major commercial databases such as Lexis/Nexis, Dun & Bradstreet, Datastream and the Internet.

You may not have PDNet, but if you work in a large organization you probably have access to much of your company’s “corporate memory” — databases, files, training manuals and coworkers.

Here is a grab bag of tips to make your research more efficient and effective. Start with the annual report.

When you get a company’s annual, turn first to the “Message to Shareholders” or “Chairman’s Remarks” at the front.

Look for outliers. When you’ve collected a large amount of data on a particular aspect of your problem, look for outliers — things that are especially good or bad.

Look for best practice. If some of your competitors have best practice, they probably won’t tell you their secrets. Talk to other people in the industry: suppliers, customers, Wall Street analysts, friends from business school, and so forth.

Conducting Interviews

In every McKinsey engagement, someone on the team will conduct an interview. Interviewing is the way McKinsey consultants fill the gaps in their knowledge base and tap into the experience and knowledge of their clients. Interviewing is a skill in its own right, and most people have no idea how to go about it.

When you go into an interview, be prepared. “Write an interview guide”. You must think on two levels when constructing your guide. First, and obviously, what are the questions to which you need answers? Second, and more important, what do you really need from this interview?

At McKinsey we were taught that, as a rule, an interview should start with general questions and move on to specific ones.

When deciding on which questions to ask, you might want to include some to which you know the answer.

Once you’ve written your guide, look at it and ask yourself, “What are the three things I most want to know by the end of the interview?”

Every interview guide should conclude with what I call the prototypical McKinsey question. When you’ve asked all your questions, or you’re running out of time, put away your guide and ask the interviewee if there’s anything else he’d like to tell you or any question you forgot to ask.

When you’re picking people’s brains, ask questions and then let them do the talking. “Always let the interviewee know you are listening”. We also learned to communicate our interest through body language. When the interviewee was speaking, we leaned toward her slightly. When she completed a sentence, we nodded. And we always took notes.

Always think strategically when conducting an interview. You have a goal to reach and limited time to reach it.

Have the interviewee’s boss set up the meeting.

Interview in pairs. Sometimes, it is useful for a pair of interviewers to “tag-team” — switch roles from question poser to note taker during the session.

Listen; don’t lead.

Here’s another trick for keeping the information flowing. Ask open-ended questions.

Paraphrase, paraphrase, paraphrase. Before going out on interviews, every McKinsey consultant is trained to repeat back a subject’s answers in slightly different form.

Use the indirect approach.

Don’t ask for too much.

Adopt the Columbo tactic. Lieutenant Columbo. After he finished quizzing a murder suspect about her whereabouts on the night in question, he would pick up his rumpled raincoat and head out the door. As he reached the threshold and was about to leave, he would turn around, stick his finger up to his temple and say, “Excuse me, ma’am, but there’s something I forgot to ask.” If there’s a particular question you need the answer to, or a piece of data that you want, the Columbo tactic is often a good way to get it. Once the interview is over, everybody becomes more relaxed.

If the person you are interviewing is more senior than the person who authorized your project, you will probably have to back down when challenged.

You may also encounter difficulty when interviewing what psychiatrists might call the passive-aggressive type, but I like to call “the Sandbagger”. Sandbaggers will talk all you want; they just won’t tell you anything.

When you get back to your office after interviewing someone, take the time to write a thank-you letter.


Brainstorming is the sine qua non of strategic consulting. It’s what the clients really buy. Let’s face it. Most large, modern corporations are chock full of intelligent, knowledgeable managers who are darned good at day-to-day problem solving. McKinsey offers a new mindset, an outsider’s view that is not locked into “the company way” of doing things.

Brainstorming takes time. Typically, a McKinsey team blocks out two hours, if not more, for a brainstorming session.

The cardinal rule of brainstorming is that you cannot do it successfully in a vacuum. Before you go into that meeting, you have to know something about the problem you’ll be working on.

Put your research into what McKinsey-ites call a “fact pack” a neatly organized summary of the key points and data that you’ve discovered, and circulate it to your team.

The point of brainstorming is the generation of new ideas. So, start with tabula rasa — a clean slate.

There are no bad ideas. No one should ever hesitate to open her mouth during a brainstorming session for fear of getting zinged with the words “That’s a bad idea”.

Be prepared to kill your babies. This rather shocking notion originated among Hollywood screenwriters. It means that if your idea, no matter how good, is not part of the team’s answer at the end of the session, dispense with it.

Know when to say when. Brainstorming takes time, but if you stay at it too long, you’ll hit the point of rapidly diminishing returns.

The consensus among former McKinsey-ites is that a team can stand about two hours of brainstorming before the atmosphere deteriorates.

Get it down on paper.

You cannot, under any circumstances, leave the room and turn off the lights without a permanent record of the outcome.

One more tip for handling a grumbler or rabble – rouser at a brainstorming session: Have the leader or moderator stand behind him, and even touch him on the shoulder occasionally. This lets the troublemaker know that he is being watched.

The Mckinsey Way of Selling Solutions

Making Presentations

For your presentation to succeed, it must take the audience down the path of your logic in clear, easy to follow steps.

The rest of the world sees the McKinsey structure most often through the medium of the Firm’s presentations.

Usually, if you adhere to a structure that makes a step-by-step progression, you want the audience to follow your presentation at your pace. There’s usually someone in the audience who lacks the patience for this.

Resist the temptation to tweak your presentation right up to the last minute. Weigh the value of a change against a good night’s sleep for you and your team. Don’t let the best be the enemy of the good.

A good business presentation should contain nothing new for the audience. Before they hold a presentation or progress review, a McKinsey team will take all the relevant players in the client organization through their findings in private. That way, there are few, if any, surprises on the big day.

When prewiring, you must remember the cardinal rule of being a successful consultant or corporate troubleshooter: Not only do you have to come up with the “right” answer; you also have to sell that answer to your client.

Displaying Data with Charts

McKinsey relies on charts, graphical representations of information, as a primary means of communicating with its clients.

The more complex a chart becomes, the less effective it is at conveying information. Use charts as a means of getting your message across, not as an art project.

The Firm uses charts as a means of expressing information in a readily understandable form.

McKinsey prints its charts in black and white. One message per chart. The first two strictures are visual. The medium must not overpower the message. A good lead expresses the point of the chart in one simple sentence.

One final word about charts: Too many will bore your audience. Use the absolute minimum necessary to make your point, or you may find that your audience hasn’t absorbed the last 10 to 15 pages of your presentation.

The waterfall chart — seldom seen outside McKinsey and not generally available in computer graphics packages — is an excellent way to illustrate quantitative flows. The waterfall chart is an excellent method of illustrating how you get from number A to number B.

Managing Internal Communications

Being “in the loop” will help your teammates understand how their work is contributing to the final goal, how their efforts are worthwhile.

Meetings form the glue that holds your team together. Team meetings allow excellent information flow, in all directions, and provide a certain amount of social bonding. They help remind those present that they are part of a team. Frequent meetings are good, unnecessarily long ones are not.

Some of the most valuable conversations in my experience resulted from random encounters. Never underestimate the value of the random fact.

A good business message has three attributes: brevity, thoroughness and structure.

An effective message shares the same properties as an effective presentation:

  • It is brief, covering only the points the audience needs to know;
  • it is thorough, covering all the points the audience needs to know;
  • and it has a structure that conveys those points clearly to its audience.

You cannot be an effective consultant if you don’t maintain confidentiality. Know when you can talk and when you can’t. McKinsey’s corporate culture continually reinforces confidentiality. We never mentioned our clients by name outside the office, and sometimes not even at the Firm.

There are two kinds of “liability” members on a client team: the merely useless and the actively hostile. Ideally, neither type is on your team.

Working with Clients

To succeed as a management consultant or a business troubleshooter you must keep your client — be it your boss or the management of an organization that has hired you from the outside — engaged in the problem-solving process.

Get on a client’s calendar up front. Schedule progress meetings with tentative topics; if you need to reschedule, do it later.

You must sell your solution to every level of the organization, from the board on down.

Making change happen takes a lot of work. Be rigorous and thorough. Make sure someone takes responsibility for getting the job done.

Part Four: Surviving at Mckinsey

Find Your Own Mentor

McKinsey maintains a comprehensive system of mentoring for its client service staff. Every consultant, from analyst to director, is assigned a mentor to monitor and guide his or her career through the Firm.

As with so many wonderful ideas, the execution left a lot to be desired.

Surviving on the Road

Although working at McKinsey offers many advantages — good pay, interesting work, high-caliber colleagues — the working conditions can be grueling.

A Good Assistant Is a Lifeline

When consultants are on the road for much of the time, their secretaries are the lifeline that ties them to the rest of the Firm.

To attract the best, the Firm provides a real career path for secretaries.

Recruiting McKinsey Style

With all this heavy weaponry, the Firm hunts first and foremost for analytical ability.

I always looked for analytical thinkers, people who could break apart problems into their components. I wanted evidence that they knew how to structure problems. I also looked for business judgment, the sense that the person knew the implications of his solutions. That’s why I always used cases.

Cases are the weapon of choice in a McKinsey interview.

Beyond a candidate’s fit with the interviewer, there is also a candidate’s fit with the Firm.

How to get a job at McKinsey. The answer is simple: Be of above average intelligence, possess a record of academic achievement at a good college and a top business school, show evidence of achievement in all previous jobs, and demonstrate extraordinary analytical ability.

If You Want a Life, Lay Down Some Rules

If you want a life when you work crazy hours, then you have to lay down some rules.

Make one day a week off-limits.

Don’t take work home.

Plan ahead.

When your priorities are “client, Firm, you” sometimes you have to let your life take a backseat to your career.

Part Five: Life After Mckinsey

Leaving McKinsey is never a question of whether — it’s a question of when.

The one firm concept. No stars, just meritocracy. That culture is extremely strong within the Firm, and I think it can work in other organizations too.

Structured thinking, clear language, a meritocracy with the obligation to dissent, and professional objectivity allow an organization and its people to reach their maximum potential. Of course, McKinsey has its own word for this — it’s called “professionalism”.

Fact-based, structured thinking combined with professional integrity will get you on the road to your business goals. The rest derives from that. Go and learn.

The McKinsey problem-solving process begins with the use of structured frameworks to generate fact-based hypotheses followed by data gathering and analysis to prove or disprove the hypothesis. A hypothesis greatly speeds up your quest for a solution by sketching out a road map for research and analyses that will guide your work throughout the problem-solving process, all the way to the presentation of your solution.

The McKinsey problem-solving process begins not with facts but with structure. Structure can refer to particular problem-solving frameworks or more generally to defining the boundaries of a problem and then breaking it down into its component elements.

The concept of MECE, is a basic tenet of the McKinsey thought process. Being MECE in the context of problem-solving means separating your problem into distinct, nonoverlapping issues while making sure that no issues relevant to your problem have been overlooked.

Making strategic decisions requires understanding the capabilities of your organization and how to utilize those capabilities to maximize performance.

Structuring your thinking can add value outside the confines of the business world.

In most cases, a complex problem can be reduced to a group of smaller, simpler problems that can be solved individually. The most common tool McKinsey-ites use to break problems apart is the logic tree, a hierarchical listing of all the components of a problem, starting at the “20,000-foot view” and moving progressively downward.

You have to be careful about introducing frameworks because they can carry a fairly negative connotation, especially if they are overused.

Remember that structure is only the beginning. You still need to develop a strong hypothesis, devise and perform the right analyses to draw your conclusions, and communicate those conclusions effectively.

Using an initial hypothesis to guide your research and analysis will increase both the efficiency and effectiveness of your decision making.

You generate your initial hypothesis by drawing conclusions based on the limited facts that you know about the problem at hand without doing a lot of additional research.

Your next step is to figure out which analyses you have to perform and which questions you have to ask in order to prove or disprove your hypothesis.

The increased effectiveness of hypothesis-based decision making stems from the lesson that “the problem is not always the problem”.

Quick and Dirty Test (QDT) of your hypothesis. The QDT is simply this: what assumptions are you making that need to be true in order for your hypothesis to be true? If any of these assumptions is false, then the hypothesis is false.

An issue tree is the evolved cousin of the logic tree. Where a logic tree is simply a hierarchical grouping of elements, an issue tree is the series of questions or issues that must be addressed to prove or disprove a hypothesis. Issue trees bridge the gap between structure and hypothesis.

Leave a Reply