What I learned at McKinsey

I spent a little over four years working at McKinsey. One of my motivations was to pick up the sort of business soft skills one does not learn when studying physics. McKinsey is a great environment to do this given

Many trainings focused on interpersonal and other soft skills
Lots of opportunities to practice, due to interactions with many different clients and colleagues
A deep feedback culture, consisting of ad hoc comments, as well as dedicated feedback time every ~2 weeks in a direct reporting relationship and about once a month in relationship across two layers

Here are some of the things I learned – some of which I plan to keep, some of which I consider harmful outside the McKinsey context, and some of which I see as double edged swords.

1. Things I am taking away to keep

Syndication

Before presenting a result to senior stakeholders, we want to first test it with relevant junior stakeholders. That way

We may receive input that improves the work
The junior stakeholders may support us when we are challenged by the senior stakeholders
If we do not agree with the junior stakeholders’ input, at least they feel heard, and we can ideally peacefully agree to disagree

To make syndication as smooth as possible, we need to take it into account when planning the timing of our work. We need to give the people we need to syndicate enough time to find slots in their calendars and to read the materials, as well as ourselves enough time to integrate the feedback we receive.

Client meeting structure

The following structure worked for most client meetings:

Some small talk to connect with the client – easily forgotten when in a rush
Recapping of where we are at – we remember, but the client may not
Starting with our agenda of things we want to get through – but, and this was my most important learning, releasing that agenda if the client wants to talk about something else / goes off on a tangent. This feels very non-intuitive when under stress, and comes with a time cost, but has several advantages
- Important information may be uncovered, after all the client has some sort of reason to bring these topics up
- It strengthens the relationship. For example, after a meeting that lasted for 3 hours instead of 1, a client said: “I used to be very sceptical of McKinsey, but I now changed my mind. Finally someone is listening to me”
- Because they feel listened to, the client will be happy to make time for a followup meeting, where the original agenda can be completed

Addressing feelings as well as facts

When people talk about their problems, they do not necessarily want just their problems solved (or at all), they also want to feel heard, have their feelings recognized as valid and understandable, and receive emotional support. When we go straight into problem solving, they may be in a less productive mindset and the relationship may suffer. In non-professional relationship guides, it is commonly said that we should not give advice at all. I do not believe that is the right approach in a work context (and probably also not in a personal context in my opinion), instead we can

First provide empathy and emotional support (“When [something similar] happened to me I also found that very difficult”, “I can’t imagine how that feels”)
When it looks like the person feels heard try to jointly solve the problem (“Have you considered xxx?”)

Putting yourself into the shoes of the other person

If we want to meet other people’s needs, and influence them to meet our needs, we need to put ourselves into their shoes. So before an important conversation it helps to formally go through a framework like this:

What is the current situation of the topic we want to address, as well as my / my team’s relationship with that person?
What outcome are we looking for?
What is the best way to reach the outcome, given 1.?

More generally, I developed the habit of imagining how I would feel when hearing what I am about to say before saying it, potentially adjusted for known differences between me and the conversation partner. For example, in the case of a late deliverable, instead of saying “I am upset with you because you have not sent this to me yet”, we can ask “Are there any roadblocks that prevent you from completing this? Can I help in any way?”

Making ourselves heard

To get ahead, it helps tremendously if the seniors are actually aware of us. Sometimes direct supervisors will make the effort to actively create visibility for us, but usually they are worrying about other things, or even want to hog visibility for themselves. That meant I had to make an effort to actively be visible. Initially in my first few months I started with this by going into meetings with senior internal stakeholders with the intention to say at least one meaningful thing. In big meetings where it can be hard to get a word in, one neat trick is to start speaking when it seems like a person is about to finish their sentence, rather than waiting for them to finish completely. An often mentioned McKinsey classic that also helps is top down communication: We want to start with the takeaway first. The takeaway will then be accepted or we will be asked for reasons. If we start with the reasons and we lose people’s attention, we may never get to say the takeaway. And if we do get to the takeaway after starting with the reasons, and it turns out the takeaway was actually uncontroversial, we have spent more of everyone’s time than needed.

2. Double edged swords

Ownership mindset

Stakeholders (both internal and external) want problems to be solved, and want to be able to trust that their people will get it done. They do not want to have to worry about bad surprises. This means it creates a lot of value to actively take ownership of the problem and try to find the solution, even if the problem is someone else’s fault. The risk of the ownership mindset is to let ourselves be exploited, by reflexively taking on ownership for everything that is asked of us rather than pushing back, or even taking ownership when noone actually wants us to.

Quality control

When studying physics, I could make a mistake in a problem and still get most of the marks. When creating work output this is not the case: We really want to make a good effort to make sure our stuff does not contain mistakes. I created a checklist for that purpose that I would go through before sending off my deliverables. Where quality control can become a problem is if it is taken to excess, and focused on optics. I cannot recall a single instance where a client complained about formatting (which many other consultants loved to do), but many instances where they would have liked to get involved earlier and looked at some work in progress material (see syndication).

3. To be unlearned

Working until the last minute

In university, I would often complete my assignments as much as months in advance – doing so reduced my stress levels without any downsides. This approach does not work in McKinsey for two reasons

The context might change, making work done earlier less relevant
It can be difficult to get anyone to look at the work if it is not urgent yet, so there is always a chance of rush due to last minute input
Being done ahead of time invites additional work, up until the real deadline

While the last problem can be addressed by not sharing the work until the last minute, the first two cannot. I thus learned to become more accepting of the stress of working close to the deadline. While I am convinced this is the right strategy at McKinsey, and probably at most other corporates, for self-directed work I see it as much more useful to be ahead of things.

Sleep deprivation

At McKinsey many people still have the belief that by working more and sleeping less, we will get more done and at higher quality. A dialogue between a well-meaning manager and a nervous team member before a presentation that illustrates this:

Manager: “Did you work until 4 am last night to prepare this?”

Team member: “Yes”

Manager: “Then why are you worried? You have put in the effort to create quality output. You will be fine, it will hold up”

The evidence that sleep deprivation significantly hurts performance is now about as conclusive as things can get in psychology (e.g. here and here). Within McKinsey, it is increasingly often mentioned in training programs or documents, like this one, but is not always recognized among partners in their actions – the consultants that care deeply about sleep tend to leave before becoming partners.

4. Other

One thing I did not mention is problem solving, even though McKinsey is often associated with that. There are two reasons for this:

My learning intention was focused on communication / relationship skills
I actually believe that the way we solved problems is quite specific to large professional services firms. A few decades ago, when generalist methodologies like issue trees became popular, McKinsey was much smaller, and there was not much specialist knowledge available. Now, with a much larger community that is significantly more specialised, these generalist tools are rarely used and the problem solving process usually goes something like this:
- Identify the problem
- Search the intranet and reach out to some well-connected people to find relevant existing materials and experts
- Choose one of the previously undertaken approaches found in the previous step
- Execute, copying as much previous work as possible to preserve time for the rest of the work

Overall, I am grateful for the many things I learned at McKinsey, but also making an active effort to returning to my own best practices where I lost them a little bit in order to fit in. It is also great to have more free time for unrelated personal development.