"The McKinsey Way reveals McKinsey's closely guarded management techniques towards that, we'll
have 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 them 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 Rasiel. Now, I hope that I
pronounce this correctly, but this guy apparently was a former McKinsey consultant himself, 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 intriguing and
interesting to read about what a company like McKinsey is all about and how they're 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 at my bookshelf. So, I thought it would be funny to go over some of the key claims of the book, of what your author
claims the McKinsey way is supposed to be all about, and I already 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 light button
for the YouTube algorithm, and subscribe to the channel and also hit the notification bed 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 the 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 Firm Learning. So, back to The McKinsey Way. And what I would 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 would word 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'll 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 at 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 will claim that
many other consultancies use it as way. MECE stands for mutually exclusive and collectively
exhaustive, and it describes the 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 MECE
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
fully completed problem. I will insert your picture of a circle that is divided in a
MECE way from Wikipedia, and I hope that this helps you understand on a more intuitive level what a MECE 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 may be sounds like, and especially in the lower levels, if you're business analyst,
associate, senior associate. These things are true, but
there's only a very small portion of associates 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 hope 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 they really made
this crazy, insane mistake. These things happen, these
things happen to everybody, and trust me that everybody would get another chance at the firm. People would 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 to
be successful in the firm and master this cues
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 way 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're asked to develop an hypothesis, what the answer
to the problem should be that you're solving,
on the very first day. So very often, in the
very first team meeting, and 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
and facts 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, and all the team starts to break it down into
different hypotheses. 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
hypothesis 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 reside 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 we iterate 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 this course, I have a whole section on structuring presentations,
creating storylines, and also solving problems
in an hypothesis driven way. So, if you're interested to
learn more about this course, I included a link to it below
individually description. The are 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
why there are similarities between business problems,
the clients are all different, and this makes it necessary
for McKinsey consultants structure completely different solutions for every single client. "Every client is unique, "but 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 the solution and said 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's 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 reside of an assessment of how good, how valid and how suitable the digitalization strategy
is, for a specific company. So, yes, why 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 our client, to really seek out all
avenues, all resources that the firm has available
to get to the solution that solved 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 the 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 strongly
disagree with the book, here the author makes it
sound like that on Saturdays. and Sundays, it is a regular
practice that has 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 why 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 fields like, you know, needs
to work on the weekend, to help him reprioritize his work, just sit together with
them 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 to 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
you're 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, 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.
