Tactic 12: Hold regular feedback sessions to allow time for improvement.
STORIES FROM THE FIELD
STORY FROM THE FIELD—1
Topic: Team dynamics discussion simplifies cross-cultural project management. Our first story from the field comes from D. A. Gros, a former associate principal with McKinsey who is now a vice president at an investment bank. D. A. recalls the importance of the first Rule of Engagement, "Discuss Team Dynamics," which affected a project he was running out of Chicago.
We were working on a six- to eight-week product strategy project for a pharmaceutical company that was based in France, for which the deliverables would be entirely in French. The project brought together consultants from geographically, culturally, and linguistically diverse backgrounds—this is increasingly common in the firm. The members included:
A junior engagement manager from Paris (originally from rural southern France)
An associate from New Jersey (physician who spoke no French)
A Spanish associate who was an ex-investment banker and had a working command of French
A partner from France (Ph.D. in science)
A partner from New Jersey (MBA who spoke no French)
Clearly, we had our hands full in terms of handling the diversity of backgrounds, especially given the short time frame of the project. From day one, the team got off to a great start. We met in the McKinsey Paris office and covered the structure and the approach for the project. After discussing the project details in the office, we headed out to a bistro on the Champs-Elysées to discuss team dynamics, including self-introductions, individual work styles, Myers-Briggs, and so on. I knew that this step would be very important to ensure that the team members would get along, learn from one another, and deliver on high expectations. Each person had a critical role in the process, and we had to spend some time getting to know each other and the roles we would play on the project.
STORY FROM THE FIELD—2
Topic: A change in team size and structure necessitates a new "evaluation" plan. Our second story from the field comes from ex-McKinsey consultant Yannick Grecourt, now with Deutsche Bank in Belgium, who vividly remembers the role of evaluation in a team project and the importance of explicit conversations.
The situation was a new engagement for a client. The team started with only an engagement manager and one associate, but after two months the team had increased and now consisted of an engagement manager and six other consultants. The complication was that the Evaluate plan had been done at the start of the project for a small team, and we hadn't taken the needed time to rediscuss and adapt the plan for a larger team and an increase in the scope of the project (the Evaluate plan was even more important with a six-person team and one EM to steer).
Our resolution was to take a formal step back and organize a team learning exercise. Such an exercise is often better if it is led by someone outside the team to discuss the three main points of Evaluate. Each of us could share his or her point of view on group dynamics, discuss learning and development opportunities, and get to know one another better. The team became much more effective after some crucial points were discussed. Specifically, there was some jealousy because the EM was sharing a room with one junior associate, who consequently had more access to him than the rest of the team. Also, there was a lack of understanding about some work-stream delegation decisions—some of the choices had been made by the client, as he was already used to working with a specific consultant. We resolved these and other misunderstandings with open discussions.
STORY FROM THE FIELD—3
Topic: Disclosing personal weaknesses leads to personal improvement and team success. Our final story from the field is a clear articulation of how admitting a development opportunity may have made life easier for a consultant. Victoria Lim, now an associate director at UBS in Singapore, remembers how it took her a while to communicate a personal learning objective on her first project at McKinsey.
I remember my first McKinsey engagement, when one of my personal goals was to hone my skills in Microsoft Excel. As part of this engagement, my EM asked me to perform various analyses on the client's customer data to help the team understand the dynamics of the client's customer base. There was a huge amount of data that cut across different segments, products, and years. Because of my limited proficiency in Excel, I was doing most of the calculations manually, and any small change to the data set meant hours of extra work. My EM couldn't understand why I took such a long time to make any changes, and I didn't know how to manage expectations. Finally, one of my other team members stepped in to take a look at the monster I had created in Excel, and promptly sat down (at 3 a.m.) to coach me for two hours. I've since learned that it is better to discuss learning objectives early, to ask for help before spinning my wheels, and to manage others' expectations—these all help me grow individually and contribute to team success.
STORY FROM THE FIELD—BUSINESS SCHOOL EXAMPLE—1
Topic: A business school leader discusses group dynamics and the importance of feedback. Clifford Dank, the MBA Association president at the Haas School of Business (University of California at Berkeley), discusses how taking the time to get to know one another informally lays the groundwork for a successful and pleasant group experience. He also explains the evolution of his executive board, which started as a group of distinct individuals, swung to the other extreme and fell into groupthink, then found the happy medium.
As the president of the MBA Association, I lead a team of 12 vice presidents with varied backgrounds—they are diverse in age, geographical orientation, and culture. They are functionally diverse as well, as each vice president deals with a separate and unique issue (e.g., academics, diversity, or corporate relations). Initially, I thought it was going to be very difficult for us to function as one cohesive unit, and I was very dedicated to finding a way to make us a real team, not just a group of people with similar job titles. At the beginning, we definitely overdid it—we were so focused on being team-oriented that we constantly fell into groupthink and strove to have a consensus on all issues. However, as we matured and grew more confident in our roles, we understood that the value that each of us brings to the team is based on that person's own unique perspectives. We evolved throughout our first semester to become a well-run group, in which we were comfortable expressing our own thoughts, but also respected individual decision makers and trusted them enough not to micromanage and constantly proofread each other's work.
In order to define group goals, objectives, and dynamics, we started the semester with a retreat. We aligned our goals there, and discussed what we as a group represented to the student body. We did not have much discussion about specific objectives, as most of our work was done autonomously or with our own subgroups. However, because we had defined our goals, we were able to make sure that our own individual objectives contributed to the group's overall mission. To establish positive group dynamics, I used improvisational comedy icebreakers as a starting point to allow us to get a feel for the different members' personalities; I found this to be very effective, as all the participants seemed to shed their shells and enjoy themselves. At the retreat we also answered different personality-type questions very informally—in lieu of the standard Myers-Briggs test, we asked each other interesting questions (e.g., "What is your greatest hope and your greatest fear?").
Our group was very feedback-oriented, which is a natural result of going to a very feedback-focused school. For example, we have a whole class geared toward incorporating constructive feedback as a cornerstone of effective communication (I teach this class as a professor's assistant). I think this is a great component of our program, as it is one of the most applicable things we learn: if you cannot communicate your thoughts effectively to both peers and superiors in a feedback-type setting, you won't be an effective leader. I incorporated feedback in the executive board by having each person fill out a feedback form for everybody else on the team after three months of working t
ogether. Although this was somewhat tedious (filling out 12 evaluations!), at the end of the day, everybody thought it proved useful. To get feedback from the student body, I sent an e-mail to everybody in the business school asking for feedback on the student government (95 out of 480 people responded). We have been striving to incorporate this feedback as we reexamine our goals and objectives.
STORY FROM THE FIELD—BUSINESS SCHOOL EXAMPLE—2
Topic: A team surmounts cultural differences by discussing work styles and setting ground rules. A germane example comes to us from a second-year MBA student at the University of Michigan's Ross School of Business, who discusses an experience in which team-mates' cultural differences led to a misunderstanding of work and communication styles. By discussing these differences openly, the team was able to adapt its plans and establish some ground rules, drastically improving team dynamics.
I was on a class team assigned to analyze marketing practices and develop a marketing campaign. Our team was very culturally diverse (with members from Russia, India, and the United States), and these cultural differences invariably influenced our working styles. A misunderstanding of these differences caused friction in the team at times. Most notably, the more direct people tended to clash with those of us who are more subtle in their communication style. To compound this difficulty, most of us were type A individuals who weren't naturally very good listeners.
For example, at one point, we were supposed to e-mail the professor a component of our project by midnight. At 11:59, we were ready to send the e-mail, and the atmosphere was understandably tense. Because of my cultural upbringing, I considered it unacceptable to send an e-mail to a professor without including a courteous message. I took the time to compose a polite e-mail despite our time crunch, and several team members were understandably annoyed and frustrated.
We dealt with these issues by talking about them openly. We were all in a class about managing teams, so we readily recognized that we had significant cultural differences. Each of us explained his or her own cultural customs and practices, and then we discussed how we could work together and communicate better; specifically, we decided to give each other more space and to rely on delegation more. Despite one teammate who never really came into the fold, our team really came together in the end.
CASE STUDY
Hi, Tim here. As we set out to implement the Evaluate ideas in our case study, we thought it would be a piece of cake. We were wrong. Peer-based teams can make role assignments and evaluation difficult at times. Let me explain.
WHAT WE DID
We were very conscious of the need to assign roles and responsibilities carefully, and so we spent a long time at the beginning of the project deciding how we would divide the project into buckets (see Chapter 6). Once this initial brainstorming and structuring was completed, though, we were not able to call it a day; we monitored these buckets constantly throughout the project, reevaluating and refining our original structure. Once we came up with our key areas, though, it was relatively simple to assign responsibility. We matched ourselves up with an appropriate bucket based upon background and interest. For example, because of my law background, I volunteered for the "Incorporation/Annexation" category, which covered the legal issues of the project.
Once we each had our assigned roles, we defined our own individual objectives and created our own work plans. We then worked individually throughout the week and shared our results at weekly meetings. One of our first steps was to create "fact packs" containing the most important information about our topic; we then shared this information with the other team members, which helped us to see more and different options and to understand how our components fit into the big picture.
We followed the same sort of process throughout the project, gathering information and forming our own conclusions before offering them to the group for feedback. This group time was particularly important for us because of the high level of autonomy in our own assignments. Throughout the week, we were dealing only with our own small portions of the overall project, and so it would have been very easy to slip into a very narrow view of the project. By paying careful attention to this potential pitfall and by updating one another at weekly meetings, we were able to reconcile our personal objectives with the team's objectives and goals.
WHAT I LEARNED
In the Johnson County study, it became clear that the goals for the team as a whole are easier to define than individual objectives, but that achieving these big-picture goals is much harder than simply throwing together individual research. In any team project, the individual parts are important and contribute to the overall effectiveness; however, the real measure of success is not whether any one component is outstanding, but rather how the overall project turns out.
I also learned that peer-based teams can be difficult to manage. Dr. Friga and Chris Cannon helped with this issue as they stressed specific roles and ownership of the pieces of the project. I also learned how important it is to have a "process-driven" person who keeps things moving forward at all times, but I believe that is covered more in the next chapter.
DELIVERABLES
Figure 2-2 Evaluate: Individual Plan
3
ASSIST
Figure 3-1 TEAM FOCUS Model—Assist
CONCEPT
Once the project is up and running, there are a few critical steps that we can all take to ensure smooth sailing. Speaking of sailing, for illustrative purposes let's envision a sailing adventure with my wife, you, and anyone else you wish to bring. We are going to take a Sunfish, which is a very small sailboat, the type that my brother, father, and I sailed on lakes and rivers growing up in Virginia. We must discuss our approach before boarding and agree on what each of us is going to be responsible for. All four of us must play a role and be ready to help each other out over the course of the three-hour tour. Meredith can handle the rudder; I will deal with the sails. One of you will handle the anchor, and the other can focus on leaning to either side to provide extra weight. And by the way, there will be times when each of us will have to help someone else, should the weather turn or the wind shift dramatically, so be ready to be flexible (plus a little variety makes it more interesting). We must be ready to assist.
Experience and research suggest that there are typically three key areas where issues arise related to providing adequate assistance during a team problem-solving project.
Confusion over roles. The most common problem is that after the team is formed, assignments are doled out very quickly, without giving much thought to everybody's capabilities and interests—a common mentality is to "just divide this up and get started."
Feedback not provided (or not provided well). If any of us really want to develop and grow, we need to receive feedback. The problem is that we don't really want to hear about our weaknesses (these days it seems like we prefer to call these "opportunities for improvement"), or, more important, the messages are delivered in an awkward or personal way that makes them hard to digest.
Overfocus on our own assignments. We all tend to prioritize our tasks based upon maximizing the benefits to ourselves, and as a result, we often lose sight of whether or not our teammates need help.
RULES OF ENGAGEMENT
I have formulated three key recommendations to facilitate a good assistance process on any team, one that will lead to the growth of all the members on a team and increased team effectiveness.
RULE 1: LEVERAGE EXPERTISE
This Rule of Engagement builds on discussing strengths and weaknesses, the importance of which was detailed in the previous chapter. It should be a "no-brainer" for teams to take advantage of the inherent expertise of their members, but for some reason that doesn't always happen. Often, we just don't take the time to ask what our team members' strengths are, or perhaps we focus more on what people want to work on at that particular time than on their capabilities. You have to (or should) take an inventory of team members' skills (what they have done) and wills (what they would
like to do), and have an explicit conversation about assignments. In essence, do an assessment based upon the respective education, work experience, and personal experience of everyone on the team.
Consulting firms do this in a very scientific way, using electronic databases to provide data on skills and availability that are useful in creating deployment strategies. Even if you are on a team that was formed without any strategic input, the skills and wills inventory should still be done.
After the inventory, the team should then venture into a "roles" discussion. Who is going to be responsible for what on this project? Generally, high-level roles that people play on teams (especially in business schools) boil down to two categories: process and content.
Process Roles
"Big picture person." This team member focuses on the overall story of the project and the presentation.
"Deliverables driver." This person keeps track of the time and the status of deliverables.
"Communicator." This person is the one primary point of contact with clients.
"Devil's advocate." This team member ensures that alternative views are considered.
The McKinsey Engagement Page 5