The McKinsey Engagement Page 6

  "Touchy feely." This is the person who continuously checks the morale of the team.

  Content Roles

  "Functional expert." People in this role concentrate on strategy, marketing, finance, operations, or some other area.

  "Relationship guru." This team member focuses on the relationship with external constituents.

  "Voice of experience." This is someone who has worked on a similar project in the past.

  Don't forget that there is a chance that no one on the team has an immediate strong content role (this is not likely in a consulting firm, but it is certainly possible on business school teams). In this case, a significant effort must be made to locate some content expertise outside the team. Many times teams, and companies for that matter, default to secondary research rather than holding conversations with experts. I recommend flipping your research plan of attack, first asking others what they know and then using secondary research to fill in the gaps. While you do need to do some basic fact finding as part of every project, conversations with experts will provide significantly more bang for the buck! A final consideration is that, depending upon the size of a team, it is entirely possible that one person will play multiple roles. Just remember to keep the workload equitable.

  RULE 2: KEEP TEAMMATES ACCOUNTABLE

  One of the paramount operating practices for team members at McKinsey is ownership. Ownership means that each person on a team, from the brand-new business analyst to the most senior partner on the engagement, knows the big picture of the project (its mission and objectives) and knows how he or she fits in. Not only is the overall puzzle picture clear, but each person takes ownership of a piece of that puzzle. This is an important concept, because each person on a team should be doing something of value and contributing to the team's overall success (see Chapter 4). The other positive by-product is that the other team members are aware of what each person is working on, what deliverables are anticipated, and when to expect them.

  Another major principle within this Rule of Engagement is the importance of deadlines. In Chapter 6, I will describe the use of content and process maps to guide engagements. For now, I think we can all relate to how important deadlines are to getting things done. In fact, deadlines are the backbone of the consulting process, as they give targets for the time by which a certain analysis must be completed. Deadlines also drive efficiency, as there is a tendency to add work to fill the available time; our goal is to force ourselves and our teams to be sure that everything that we are doing is adding value and having an impact on the end product for the client.

  Deadlines also give us a chance to reconnect with our teams to review the status of the pieces that each person owns and how the overall story is coming together. Every engagement has a mix of "individual" and "team" time, and the deadlines ensure that we have adequate (but not too much) team time to allow multiple perspectives and inputs for the "ideation." It is also during the team time that we can review the current workload and assignments to ensure that our efforts are equitable and are continuing to contribute in a meaningful way to the overall direction of the project. However, this is a fine line, as we don't want to micromanage the process, and we must trust our teammates to complete their assignments adequately. The Russian proverb that Ronald Reagan was fond of repeating is very fitting in these types of situations: "Trust, but verify."

  This leads to my last thought on keeping teammates accountable. Very rarely do we get the key issues, hypotheses, and work streams completely nailed down at the start of a project. In fact, iteration and modification are part of the process described in the second half of this book, the FOCUS section. With that in mind, we should all realize that adjustments of assignments and workloads are to be expected; for some reason, many of the teams I have been on have preferred to try to keep the original course. By shifting assignments a bit based upon their current status of completion and importance to the final story-line creation, we are given an invaluable opportunity to assist our teammates and keep things "sailing" along.

  RULE 3: PROVIDE TIMELY FEEDBACK

  The final Rule of Engagement of this chapter is dedicated to covering the touchy topic of feedback. Let's face it, every team will have issues, disagreements, and improvement opportunities (just as we all experience personal growth opportunities every day). The best teams are the ones that handle feedback in a constructive and timely fashion. There have been hundreds of books written on this topic, but I would like to distill the concepts that seem to surface as the most important from my experience and research.

  The most important aspect of effective feedback is that it must be delivered in a timely manner. This means that we must all share and receive feedback during and not just after the engagement. Postmortem feedback (especially in terms of after-action reviews) is helpful, but the more meaningful feedback comes during the project. This gives the person receiving the feedback a chance to work on improvement during the life of that particular engagement and minimize the negative effect of whatever the person is not doing well.

  Feedback should also generally be done in private. There may be times when a team does a group-sharing session, especially if it is facilitated by a third party. Most of the time, however, feedback is better delivered in private, and it should be presented in a non-threatening and helpful way. The word choice is critical. Here's a great example of how not to do this from a particular partner in charge of reorganization consulting at PwC in New York City. After my first week on the project, he took a look at the deliverable and exploded at me in front of several employees in the office. After about 10 minutes of this "feedback," I was more focused on the feedback approach than on the feedback itself. At least he was giving it to me in time to do something about it, rather than just waiting until after the engagement to yell at me.

  What should be included in feedback? First, it should be balanced. Feedback should not be limited to the negative aspects of someone's performance on a team (often euphemized as "opportunities for improvement" rather than negative observations). When delivering feedback, be sure to include some praise of a positive contribution before delivering the negative comment. A few recommendations for the feedback process follow:

  Deliver balanced feedback.

  Be specific; don't generalize (e.g., "you are not a good problem solver").

  Report from your perspective, not everyone's (e.g., "I react a certain way when you . . .").

  Provide examples of the causation and impact.

  End with a positive outlook and offer ideas for improvement and assistance.

  OPERATING TACTICS

  The Operating Tactics for the Assist element of the TEAM FOCUS model are:

  Tactic 13: First spend at least an hour in a general brainstorming session to openly discuss the problem and key issues to explore (see Chapter 6).

  Tactic 14: Be sure to balance the load equitably based upon the estimated number of hours required to complete the tasks. Periodically revisit the assignments after work has begun to ensure that the work distribution continues to be equitable.

  Tactic 15: Identify and leverage the specific skill set of each team member (and the firm or the client, if applicable).

  Tactic 16: Include at least one or two key status report meetings with the team (and the client) to review findings, data sources, and work streams.

  Tactic 17: On a daily basis, provide an update of individual and team progress to assess opportunities to adjust workloads and assignments.

  STORIES FROM THE FIELD

  STORY FROM THE FIELD—1

  Topic: Assisting colleagues—even those on different projects on different continents—is beneficial to the firm as a whole. One of my interviewees suggested that the organizational structure and the reward incentives within McKinsey provide insight into ways in which companies can encourage teamwork and mitigate the bias toward individual incentive programs.

  An interesting example related to the Assist bucket is how McKinsey structures its internal reward
system. McKinsey pays all partners the same salary globally regardless of location, and consultants are also paid on a global basis. Occasionally, problems arise from an individual incentive perspective, as when clients in a country with lower billing rates (like India) require expertise and advice from a partner in another country with a higher billing rate (like the United States).

  The general philosophy within the firm is to provide the best of the firm to each client (if the expertise is available), even if there is a loss in billing rates for the work performed. In essence, the U.S. partner is not penalized; instead, the firm absorbs the difference with a long-term understanding that the benefits to the company served and the firm overall outweigh the short-term loss in transfer pricing. Additionally, partners are expected to spend a percentage of their time assisting other projects, regardless of the location of the client demand. This is not the case at many other consulting firms (some have an "eat what you kill" mentality), and it helps to differentiate McKinsey in a very positive way.

  STORY FROM THE FIELD—2

  Topic: Leveraging the knowledge of multiple work-stream leaders helps one consultant create a cohesive financial model. Our second story comes from Victoria Lim, who also provided a story in Chapter 2. In this case, Victoria leveraged expertise by frequently consulting with key leaders of her project's multiple work streams.

  I was working on a huge transformation project with at least five different work streams running in parallel. As fate would have it, I was to work on the financial model (I became more confident in Microsoft Excel with every project, and am now pretty proficient!), which had to take into account specific "levers" and recommendations across all the different work streams. It became critical for me to leverage other teammates in order to understand all the work streams and to represent them accurately in the overall model. I communicated with my teammates frequently in order to update them and to hold them accountable for the inputs they provided. These inputs later translated into measurable targets for the implementation team—by delivering on these targets, the client could achieve the expected financial upside shown in the consolidated financial model.

  STORY FROM THE FIELD—3

  Topic: Formalizing feedback practices helps to make the process more effective. Another insightful personal story comes to us from Oliver Personnaz, who is currently with Apax Partners in Paris, France. He reminded me of some of the most important lessons that McKinsey teaches related to giving and receiving feedback.

  McKinsey excels at ensuring that all consultants on all projects speak the same language and use the same tools. One of the most important elements is the systematic use of feedback throughout the problem-solving process. I remember learning just how important the language is, especially when you are communicating opportunities for improvement. For example, it is critical that you frame any feedback as being from your own individual perspective. The suggested word choice for sharing feedback is along the lines of: "I have observed that . . .; the effect on me is . . .;" pause, "what I suggest is . . ." Receiving feedback is also important, and some suggested tips include listening carefully, asking for examples to ensure understanding and context, and trying not to become defensive (not concluding that I am a "bad" person).

  Giving and receiving feedback on the spot is part of the McKinsey culture, and it happens almost daily. More formal feedback is given and received in face-to-face meetings, team learning sessions, and IT-based questionnaires at the end of an engagement. Once again, this is a very structured process and is part of the evaluation of all the senior people within the firm. I once attended a conference featuring a former director from McKinsey; this impressive individual had spent more than 20 years with McKinsey and was one of the firm's top five directors worldwide. When asked how he felt about having moved on from McKinsey, he said he was relieved—he was finally out of the constant spotlight of scrutiny and evaluation. Though feedback can be painful, I'm sure he grew significantly through the process!

  STORY FROM THE FIELD—4

  Topic: Including the client in organized feedback mechanisms contributes to the engagement's success. Our final story illustrates a fantastic system of coordinating feedback that was developed by one creative ex-McKinsey consultant.

  I worked on developing an electronic feedback system for improving team dynamics. McKinsey consultants are trained to give and receive feedback effectively among themselves, but I found that our clients often are not as comfortable with feedback. We needed another method to share evaluations, particularly in situations where McKinsey consultants and clients have not previously worked together as a team. I worked to create a model that would address this concern, and it has proved to be especially valuable in Asia and other regions where clients are often uncomfortable speaking in a public forum.

  In the model, the first step is to address the Talk and Evaluate elements of team projects—to get our clients engaging on and talking about team dynamics. From there, the next step is to collect anonymous feedback, using a Web-based platform. The McKinsey team sends out electronic forms to the client and McKinsey team with normal survey questions (e.g., Are you learning? Do you feel that people are helping you develop?). I have found that this is a good way to break the ice, instead of making people uncomfortable in an open forum. The comments are then aggregated and average statistics are calculated (individual feedback reports are available only to the individual being evaluated).

  Typically, these electronic feedback sessions are conducted weekly for the duration of the project. The McKinsey project manager sits down every week to analyze the feedback and to build statistics. As a rule, the questionnaires bring unsur-faced issues out into the open. This helps us address problems quickly and to further personal and team progress.

  The next step of the process is to send our client team's manager the survey results. Note that no senior people (either from McKinsey or from our client) are involved in the process, as that could discourage people from being candid. The project manager then circulates the report within both the McKinsey and client teams. This typically occurs on a Thursday afternoon, and a meeting is held on Friday morning to address the issues that have surfaced. We always make sure to begin each meeting by celebrating accomplishments, and then to discuss opportunities for improvement. Here, the idea is to tease out the issues that were common among many individuals and to come up with satisfactory solutions.

  This system has worked very well every time I have implemented it. It has led to exponential improvement in the team's performance, and getting our client to start talking more openly is always helpful. This open communication does take some time to develop, though. The pattern I've noticed is that in the first feedback meeting, few people are willing to talk openly. A few weeks later, clients see the effectiveness of the McKinsey feedback sessions, and slowly start opening up. After three or four weeks, client teams generally seem completely open, and even look forward to these team meetings.

  Though my experiences with this model have all been very positive, some teams have had some problems. The feedback sessions occasionally become a platform for criticizing or offending teammates. In some cases, moderators or conflict managers have had to intervene; understandably, our clients in these situations don't like the organized feedback process. The takeaway here is that team members should feel open about discussing team issues, but that these forums must be respectful. It can require coaching and practice to learn how to provide feedback constructively.

  STORY FROM THE FIELD—BUSINESS SCHOOL EXAMPLE—1

  Topic: Defining clear leaders helps to overcome team conflicts and to improve efficiency. One of our business school stories is from an MBA student at the University of Michigan's Ross School of Business. The respondent describes the common issue of what to do in a peer-based team without any natural leadership roles.

  I was working in a group on a project for Kmart and Citibank. As is common in a top business school, there were problems as a result of clashing personalit
ies and a lack of accountability. With no designated team leader, we had problems at all stages: project definition, organization, delegation, and so on. Thus, we were constantly being pulled in multiple directions. We ultimately recognized this problem and decided to overcome it by implementing a rotating leader position—every two weeks, we named a new leader. After we made this change, our meetings were much more productive; overall, the team was much more successful when we had clearly defined leadership in place.

  STORY FROM THE FIELD—BUSINESS SCHOOL EXAMPLE—2

  Topic: Role definition and project collaboration balance individual and team responsibilities. Another business school example comes to us from an MBA student at the University of Texas at Austin. He described a project he encountered while working as a summer associate at a top consulting firm.

  I was working on a team in Chicago for a large company. This was the best team I have ever been a part of, for two reasons.

  Ownership. All the members of the team understood what their roles were, and people owned their work chains. This is difficult to find in teams—typically, there are a few really good people who get things done, and there are a few who lag behind. On this team, nobody waited for someone else to tell him or her what to do—each person was proactive in getting things done individually.