The McKinsey Mind for Quality Engineering

How many times have you participated in a meeting where the problem is not identified, stated, or written? Personally, too much.

I remember as a child hearing my godfather saying “at work, we are paid to solve problems”. It sounded a bit negative at first, but I got it better with time, and with experience, feel what he meant. We can summarize the work of engineering in solving technical problems but the reality is, we must be solving customer problems.

McKinsey is one of the most famous consulting firms over the world, owning a tremendous reputation of high quality and costly consulting services. The stereotype of high rates, black suits and perfectly crafted presentations are following them. In reality, their customers do not buy slides but the enablement of “impactful transformational changes with data-driven insights”.

Internally known as “The Firm”, they shared two key books – The McKinsey Way and The McKinsey Mind – sharing some of their internal practices. Even if a bit commercial, they share useful materials from a company that mastered the process of problem-solving in highly-complex environments.

This article shares takeaways from the McKinsey Mind book that aims to be applicable in our quality engineering context.

The importance of a structured process

The whole book revolves around McKinsey’s key processes to solve customer challenges or the “Problem”. The objective is to structure the reasoning to increase the quality of the output, in our case the recommended action plan, the “Solution”.

blank — Figure 1: The McKinsey Problem-Solving Model

The process aims to balance Intuition and Data to solve complex business challenges.

Data structure the analysis and the presentation with the scientific approach of data-driven hypothesis exploration. Intuition leaves space to complement the solution with gut feeling, expert knowledge, and the human capacity to generate solutions.

We could say that there is nothing new – solving problems is something we all do daily – even searching for food is a basic form of problem-solving. The key difference in McKinsey interventions is the complexity of high-stakes subjects they have to tackle. The difficulty lies in the execution, not in understanding the process. In the meanwhile, engineering problems are also becoming more complex for all of us.

Solving the right problem right is one of the risky shots identified for Quality Engineering. We can face different issues ranging from a complex incident, a scenario selection, to answering a particular question. For instance, if your boss asks you “How can we improve by a factor of 10 our delivery cycles?”, intuition and data will be required to structure your answer.

Be ready, as the McKinsey Mind requires to answer in 30 seconds this type of question. Before reaching that level, we have to start with “First Things First”, framing the problem.

Structuring the problem, ideas and reasoning

While a well-framed problem does not guarantee a good solution, a poorly defined problem does not lead to quality solutions.

The MECE Principle (Mutually Exclusive and Collectively Exhaustive) is a valuable pattern we can all apply to structure our reasoning. It is fundamentally a “list of list” enabling a broader, hierarchical, and ordered thinking. This practice comes from McKinsey, helping to drill down complex problems into work packages that could be streamlined in parallel for a faster hypothesis analysis.

Engineering is full of MECE. For example, functional and non-functional requirements are the first list to drill down non-functional requirements into usability, availability, security, etc. Pragmatically, we can apply MECE to different tasks such as our requirements analysis and architectural design.

MECE is powerful in our problem-solving process when materialized with an “Issue Tree”. Our problem framing, intuition, and initial data will guide us to define the hypothetical issues and related sub-issues. The issues are formulated into questions we can answer with yes or no; our goal is to answer “no” as fast as possible to reduce the number of questions to investigate.

The next step is to select the most critical questions balancing intuition and data to identify their data-driven hypotheses. This step is based on the scientific method of iterating over data-driven experiments to draw conclusions. We can explore our engineering practices improvements with this approach, ensuring the data is collected in the first place. For example, we could combine Value-Stream, Process Mining, and Data Science to try to answer our boss’ acceleration question.

The mentioned practices support the “right analysis”; the next step is to perform the “analysis right”.

Design the analysis right and efficient

At that stage of the problem solving, we have our list of questions, hypotheses, and potential data sources to explore. Before digging into the details, the practice of McKinsey is to ensure the analytical priorities are defined.

Each investigation point is prioritized using various techniques. Intuition is helpful as a guide to select the most important issues from our previous analysis that we can combine with expert knowledge. Answering the basic question of “So what?” is an effective McKinsey triage practice. Their culture also states regularly “at the end of the day”, supporting people to step back on impactful activities. The Pareto Principle is another effective practice part of the prioritization exercise, thinking in “80/20”.

Triage is a fundamental practice to apply daily in engineering: prioritizing the backlog, meetings, or tasks. Essentially we have to manage time as there are always more tasks than resources available. With the tendency of time to use the available space, a lack of triage leads to sustained poor execution. The final test is to ask “Will my boss care?” avoiding unnecessary tasks in the first place.

We can now work on data gathering.

Gather meaningful and valuable data

Each hypothesis relies on data points that we must fill. A good practice is to balance internal and external data sources, where publicly available information usually benefits from benchmark data and cross-sector analysis. These data are useful for the soundness of your analysis, win time, and the credibility of the restitution. We have to construct over time a systematic list of references completed depending on the analysis at hand.

Interesting sources exist for our engineering context. The Accelerate report is one source we could use for our boss’ acceleration question. Benchmarks of web performance, standards of most prominent vendors such as Google are also powerful references we can use. Context is important in our analysis to compare the right things. If you compare your Start-up to Google for investment decisions, that would be misleading. Even if you are in the same general MECE list of “Tech companies”, you are not in the “Top 10 Largest Corporation” one.

Counter-intuitively, data sources can also come from human interactions.

Ask the right questions right

Interviewing is one of the standard McKinsey practices used through the process, from problem framing, prioritization to solution generation. Knowledge management is an industry challenge, explaining the emphasis on this source of data. We cannot rely exclusively on interview data; it is a balance similar to the one of Intuition and Data.

Their book recommends these 7 best practices for conducting effective interviews :

Have the interviewee’s boss setup the meeting
Interview in pairs
Listen, don’t lead
Paraphrase, paraphrase, paraphrase
Use the indirect approach
Don’t ask for too much
Use the Columbo tactic

All of them are relatively self-explanatory. The Columbo one consists of asking the most important question while ending the meeting to get spontaneous answers. They are tailored to perform consulting interviews aiming at collecting data. For our engineering context, listening, paraphrasing, and not asking for too much are practical habits to develop in our various interactions.

Even if not stated in the book, we can also apply the principle of “Seek first to understand, then to be understood” by Stephen R. Covey in The 7 Habits of Highly Effective People. Like problem-solving requires more time in framing than actually generating solutions, interactions are no exception; we have to listen more than we talk. We mention the “Question Asker” role in a previous article to improve the quality of the various deliverables.

The value of our data analysis requires effective communication.

Iterate to craft a valuable presentation

“It’s not what you say, it’s how you say it” is a good summary of the importance of presentations. Keep in mind that the balance of intuition and data also applies to the stakeholders you will interact with in various ways.

Before sharing with anyone outside your working team, data validation is fundamental. You can perform this yourself by doing the maths and some type of coherency verifications. Invest time here to avoid the card castle effect where someone can ruin your presentation in two seconds, pointing out incorrect data. A traditional pitfall is to draw misleading conclusions mixing correlation or causation.

Peer review is an effective practice of getting external feedback on your work, both for the data and the visual presentation. Like with other quality practices, a continuous approach of peer-reviewing your presentation iterations will bring maximum benefits. Applying the same question of “So what?” when looking with a fresh look at your slides helps to focus on the important messages.

The format of the McKinsey presentations are well known for their overall quality. Some people can joke that the price per slide is relatively high. That’s partially true as the value resides in the changes implemented, not in the slides themselves. Like for a Michelin restaurant, you expect a qualitative presentation on top of a tasteful meal.

Some good formatting practices are to use self-explanatory titles, graphs, highlight key messages, use standard fonts, limit colors. All data sources must also be cited. McKinsey also mentioned the occasional tailoring of the presentation depending on the audience.

The presentation structure is equally important as its content and formatting.

Present ideas to drive change

McKinsey shares vital ingredients of a well-crafted presentation message. Their experience of sharing conclusions with so many directors and executives helped create a series of valuable best practices.

The first counter-intuitive guideline is to start the first slide with the conclusion. We are used to following the traditional introduction, development, and conclusion structure. The difference with doing a written exercise for our school teacher is that we have to convince executives of the solution to the stated problem. Executives usually like to feel in control, know the facts and what is involved. The other advantage is to align from the start guiding the presentation; the next slides support the solution preconization rationale. The first slide summary is not the only challenge.

“In our business, it is helpful to get to the one or two really important numbers that need to be considered. There isn’t time for more.” We concur.”
Ethan M. Rasiel

The “30-seconds elevator test” is a powerful McKinsey technique to assess the clarity of your thoughts on the problem. The test consists of explaining to someone outside of your working team – like it is the CEO – the problem, your solution, and the rationale within the time constraint. This is a true challenge of conveying the important message in a clear, concise, and sound way. We can even use this 30-seconds test as a continuous assessment during our analysis and before writing our first slide.

We can extend our review mechanisms more broadly as the next step.

Effectively managing the stakeholders

The official presentation is usually only a formality. Our previous work of reviewing will need a pre-sharing with key stakeholders: Client, Team, and Self.

The Client must be involved during the whole process. Sharing usually happens in a 1to1 format to create sufficient space for discussion, identifying possible objections, and improving trust. The team benefits from iterative feedback on the presentation while involving influential persons in its construction. The goal of McKinsey consultants is to foster a pull rather than a push communication model by creating engagement opportunities. Our engineering practice can be similarly improved by an early, broader, and continuous involvement of stakeholders.

The second stakeholder group is the Team. McKinsey shares key elements of member selection, cultural fit, and feedback. The firm requires specific profiles to perform its particular mission, its talent pool revolving around business schools. Interestingly, a fundamental recruitment principle is to consider potential at least as important as demonstrated ability. The second guideline is to carefully assess the cultural fit with a series of behavioral questions or group dynamic exercises. Their last practices support the quality of their interventions pushing for clear expectations and regular feedback with team members.

The trio of stakeholders ends with oneself. The rhythm imposed by McKinsey requires specific attention to recharge the batteries to play the long run. There is no magic here, and some key points are highlighted, even if their difficulties lie in the execution. The time-box approach of agile can be applied to planned personal time, even if limited in these contexts. The key message is to balance as possible non-professional time with discipline.

A bit of rest that is probably easier to take when the Solution is delivered.

What are your Quality Engineering problems?

McKinsey sharing is a repeatable process to solve complex business problems. Their experience brings us a series of actionable practices we can apply in our engineering context.

We are all paid to solve problems, and surprisingly, problem management is rarely trained at school, personally, or in-company sessions. I would argue that before trying to solve any problem, investing in a problem-solving capability is a sound decision.

Pragmatically, experiment with a few practices on concrete topics you are facing at work while ensuring peer reviews mechanisms. We can be surprised by the effect of shared continuous improvements. I recommend reading Atomic Habits and exploring the Firm Learning youtube channel from an ex-McKinsey consultant.

With time, we can develop truly differentiating capabilities that make a difference in both the solution generated and their presentation. “At the end of the day”, developing the most valuable internal consultants is one of our missions.