Transcript for:
Understanding The McKinsey Way Principles

The McKinsey Way reveals McKinsey's closely guarded management techniques. Tools that will help anyone, at any level, think like a McKinsey consultant. Hi there, my name is Heinrich and welcome to another Coffee Break with Firm Learning. Hope you're all doing well. Today we have a very exciting topic for you and this is The McKinsey Way.

Many people seem to believe that McKinsey is an organization so unique and so special that they have a very special way of how they handle things and the label The McKinsey Way is the way to put it in a concise term. And this belief got popularized by one book. By the book that is called exactly like this. It's called The McKinsey Way, written by Ethan Raziel.

Now I hope that I pronounced this correctly. But this guy apparently was a former McKinsey consultant himself who wrote this book claiming to reveal all the secrets about what McKinsey is all about. So I remember purchasing this book when I was a young business student and thinking about whether I wanted to join a consulting firm after university.

And I found it intriguing and interesting to read about what a company like McKinsey is all about and how they are actually working in their day-to-day operations. After I then joined the firm, I kind of forgot about this book, but I recently found it again by accident in my bookshelf. So I thought it would be funny to go over some of the key claims of the book. of what the author claims the McKinsey way is supposed to be all about.

And I will give you my perspective from having worked at McKinsey for roughly six years, whether what he writes is actually true or not. So let's jointly scrutinize the McKinsey way. Let's jointly deep dive into it and think about whether it's actually true what the author describes as the McKinsey way or whether it's just complete BS.

As always, if you find this video interesting or helpful, please press the like button. button for the YouTube algorithm and subscribe to the channel and also hit the notification bell to stay up to date with my content. I will release at least one video every week and sometimes even more as I'm doing this video right now and it's not a Saturday when you will see it as a release date.

And if you haven't done it yet also check out my Instagram. I'm posting several pieces of content on my Instagram channel every day. My Instagram handle as well is firmlearning. So back to the McKinsey way. And what I will do now is, because I obviously cannot go over every single statement with you here, because this would just take too long, I will pick a couple of paragraphs, which I believe might be especially interesting for you.

And I will do it in this way that I will read to you what he is writing, and then I give you my brief and candid comment, whether I believe it is accurate or not. And please also let me know below in the comments whether you find this format interesting, because if you do, I could also imagine continuing with this and going over more passages in the book, because there are many more interesting things he writes about that I could possibly cover in this video. If you are interested to read the full book by yourself, I have included an Amazon affiliate link below in the video description.

Early on in the book, he talks about how Ed McKinsey problems are being structured. So let's hear what he has to say about how to structure problems. Feel free to be MECE.

To structure your thinking when solving business problems or anything for that matter, you must be complete while avoiding confusion and overlap. A good structure for every problem that you want to solve at McKinsey is for sure something that is very important. MECE is a principle that is frequently used at McKinsey, though I would claim that many other consultancies use it as well.

MECE stands for Mutually Exclusive and Collectively Exhaustive. And it describes a way how you should structure problems. Specifically, it gives you a rule how you should divide a problem into smaller components.

And by following the Mies'principle, the divided components should on the one hand be mutually exclusive. This means that the components should not overlap. Every single individual component should stand for itself and not overlap with other components. And second, it should be collectively exhaustive.

So this means that taking all the components together should again form the full complete problem. I will insert here a picture of a circle that is divided in a messy way from Wikipedia, and I hope that this helps you understand on a more intuitive level what a messy separation of a problem is. In the book, he also makes references to the famous and dreaded up-or-out principle.

Associates who perform poorly didn't last very long at the firm. After one bad engagement. No EM or ED would want them on the team. For the uninitiated of you, what does up or out actually mean?

Up or out is a principle that is applied by McKinsey but also other consulting firms which basically means that either you get designated over time to the next level or if you do not make the promotion, if you do not make the designation, then at some point you will be asked to leave the firm. So it's either you go up or you go out. And how exactly this works probably is material for a whole other video.

But what I can already tell you is that it is much less cruel and horrible than what it maybe sounds like. And especially in the lower levels, if you're a business analyst, associate, senior associate, these things are true. But there's only a very small portion of associates who is actually affected by that.

So there's definitely no need to be afraid that for every little error that you make, at some point you will be just asked to leave the company. This is not how it works. And what I especially disagree with is that the author claims that basically after only one bad engagement, after only one problematic project where you for whatever reason weren't really able to perform in the way that you hoped to, you would already be on your way out of the firm.

This is just not true. From what I have learned, also talking to many other associates, almost every single associate will be able to tell you one story or two. about this one project that really went badly about this one situation where he really made this crazy insane mistake these things happen these things happen to everybody and trust me that everybody will get another chance at the firm and people will try to help you will try to work with you and if there are any specific things that you struggle with people will try to help you they will really work hard together with you to really enable you be successful in the firm and master all the skills that you need to master in order to become a good and effective consultant. So claiming that after one bad project your career at McKinsey is over is just blatantly wrong.

This is not how it is. And now while further elaborating how McKinsey solves problems, he talks about the so-called initial hypothesis. Solve the problem at the first meeting, the initial hypothesis. Solving a complex problem is like embarking on a long journey.

The initial hypothesis is your problem-solving map. Yes, the book is right here. What is referred to as an initial hypothesis is often also called the day one answer at McKinsey. The day one answer. So if you are a project lead or a partner at McKinsey and you start on a project, often you are asked to develop a hypothesis what the answer to the problem should be.

be that you are solving on the very first day. So very often in the very first team meeting, in the very first problem solving session that the team has, the team tries to come up with a day one answer. So with their best understanding, their best hypothesis, based on all the information effects they know on day one is what the answer to a problem should look like.

And the reason why this is done is that this gives now the whole team a direction. So based on the day one answer, the team starts to... break it down into different hypothesis. So what do you need to believe?

What do you need to know in order to understand whether this hypothesis, this day one answer is actually true? And then the team starts to go out, interview people in the organization, collect data, conduct analysis, and to find out whether the day one hypothesis is actually true or not. And very frequently in the process after a few days, or maybe also a couple of weeks, you find out that Well, no, the day one answer is not correct.

But actually, one of the hypotheses that the day one answer was based on was found to be false because you did some interviews, you conducted analysis, and this is what the result of that is. So now you can revise the day one answer that you have based on the new findings and then use this revised version to conduct further tests, further analysis, and then reiterate on this answer until you get to the final answer that everybody believes in. And there are many different reasons why this hypothesis-driven top-down approach to problem solving is actually advantageous compared to other problem-solving solutions.

And if you're interested to learn more, I have created a whole course on creating slide presentations in the way the top management consulting firms do that. And in this course, I have a whole section on structuring presentations, creating storylines, and also solving problems in a hypothesis-driven way. So if you're interested to learn more about this course, I included a link to it below in the video description. The over 10,000 students already taking the course have a look to see whether this is something that might interest you as well. He continues to argue that while there are similarities between business problems, the clients are all different.

And this makes it necessary for McKinsey consultants to structure completely different solutions for every single client. Every client is unique. That there are many similarities between business problems does not mean that similar problems have similar solutions.

You have to validate your initial hypothesis or your gut with fact-based analysis. This will put you in a much better position to get your ideas accepted. I believe that this section of the book tries to address a frequently phrased criticism of consulting in general and maybe also McKinsey in specific, which is that consulting firms develop a solution once for one client.

And then they take this solution and sell the very same solution to a whole bunch of other clients. And I would argue that this is true for some aspects, but wrong for most of the other aspects. What do I mean by that? It is true that consulting firms try to come up with methodologies and tools that they can use not only at one client, but then at other clients as well. And by doing that, it really enables them to validate their concept, to then also refine these tools based on the learnings that they had using them at other client situations and coming up with a solution that is really helpful and really adding value to the client.

So yes, this is true. This is what consulting firms are doing. And one example could be a certain framework of how the consulting firm analyzes the digitalization strategy of a company. So potentially they could come up with a framework of saying that there are five key areas that they would want to look at when they assess the digitalization strategy of the company. And then each area probably consists of other elements that they would want to look at.

And by following this approach, they would be able to come to a reliable and repeatable result. of an assessment of how good, how valid, and how suitable the digitalization strategy is for a specific company. So yes, while they would reuse this framework for several other clients, what they will not do is just to copy-paste the solution that they found for one client. So it's absolutely true and crucial that every single situation is different.

Even if you look at companies in the very same industry operating in the very same field, these companies are often structured. in a very different way. They operate in a different way.

There are often some fine and important nuances in the product portfolio. And you need to take all of this into consideration to come to a solution. So you just cannot copy paste the solution that you just developed at another client.

And I've really never seen this happen during my time at McKinsey. To the contrary, there is a very strong spirit in the firm trying to challenge each member of the team to really get to the best. possible solution for a client to really seek out all avenues, all resources that the firm has available to get to the solution that solves the problem for the client in the very best way possible.

One thing many people are afraid of, especially when they think of the MBB consulting firms, so McKinsey, BCG or Bain, are the work hours. And in this regard, he tries to give one advice. Make one day a week off limits.

Pick a day most people take Saturday or Sunday and tell your boss and yourself that you never work on that day unless it's an absolute emergency. Most bosses, at least in my experience, will respect that most of the time. So this is where I strongly disagree with the book.

Here the author makes it sound like that on Saturdays and Sundays it is a regular practice that as an associate or a consultant at McKinsey you would need to work. From my experience this is absolutely wrong. While it is no secret that the work-life balance at McKinsey and also other consulting firms is not necessarily great, and while there are also differences country by country, I was part of the German office at McKinsey, and the German office is considered one of the worst offices worldwide regarding the working hours.

I guess Germans just have the reputation of working long hours. And having worked in Germany, I can tell you that in my time at McKinsey, there were really only a handful of weekends where I needed to work because there was really a hard business reason. And actually, I found the contrary to be true. In the firm, there's a strong culture to keep the weekends free. I have seen many project leads who really tried to make an effort that whenever they sense that an associate feels like, you know, needs to work on the weekend to help him reprioritize his work and just sit together with him to make it possible to just cancel out all the to-dos to help him to get the weekend free and not making work necessary.

So if there is just a situation in your project that just makes it absolutely necessary to work on a weekend, then yes, you will be asked to work on the weekend and it will be expected from you that you will make the time to do that. But this is, at least from my experience having been part of McKinsey for six years, this is a clear exception and not the norm. Now I'm interested in your opinion. What do you guys think?

Do you also have a notion in mind what the McKinsey way is supposed to be? If you have any questions, just let me know in the comments and also let me know what you thought on the paragraphs in the book. Would very much appreciate your opinion on these topics. And again, if you took any value out of this video at all, please hit the like button for the YouTube algorithm and also subscribe to the channel to stay up to date with all the content that I'm planning to put out in the next weeks and months. And also follow me on Instagram for daily firm learning updates.

It was a pleasure for me doing this video for you and I'm really grateful that all of you are joining me here on my YouTube journey. So thanks so much for watching and have a good day. This is Heinrich from Firm Learning.