>> This week we're talking about the exciting subject of managing team dynamics. So, you've designed the team, composed it. Thought about rows and responsibilities. Private and shared goals. The key question now, is how do you manage team dynamics? How do you manage the team once it gets going and begins to work on a particular task? And this is an absolutely critical question to address. We often run studies when we ask people to work on a task with randomly assigned teammates. So, we have teams working on exact same tasks that have equal access to talented individuals, randomized. And yet we see drastically different outcomes of this teamwork. Why is that? Well, the answer to this question lies in understanding team dynamics. What happens in the team? Once it get's going and begins to work in a particular task. And it turns out that our teams can fall into some major traps with respect to managing team dynamics. Those traps lead to process losses or sub-optimal outcomes in collaboration and so our goal for this week is to recognize what these traps are and learn how to avoid them. And I'd like to start with the subject of coordination, which is perhaps one of the most central dynamics within teams. It goes to the fundamental problem of organizational design. How do you effectively couple specialization with integration. See, in teams, we often take advantage of a larger pool of labor and different competencies and expertise of our teammates and assign different tasks to them, allowing them to specialize. Now, the key challenge then is how do we bring these different outputs of different teammates together Into coherent product and one way to think about this systematically is to think carefully about how we divide work and coordinate labor. The first step in this process could be to think about the type of interdependence that your team is facing. It's important to recognize what type of interdependence your team is facing because that will inform. What types of coordination demands your team is up against. Many years ago, a famous organizational theorist James Thompson distinguished among three key types of interdependence, pulled, sequential, and reciprocal. So, pulled is perhaps the loosest form of interdependence. This is when your teammates work on separate, independent tasks that jointly contribute to the overall product. Imagine, for example, that your team is responsible for organizing a corporate conference, and you're in charge of three primary tasks. And so you site one teammate to managing the food, another teammate to setting up the stage and managing the acoustics. And the third teammate to designing flyers that would advertise companies, products, to conference participants. As you can see in this case, there is very little interdependence among the teammates. The type of food one of the teammates orders has no bearing. On the stage set up an the type of a fly that the other teammate would design and vice versa. Yet, collectively, these tasks contribute to the overall product which is a succesful conference. Sequential interdependence occurs when the outputs of one of the teammates become inputs for the other, so the classic example of sequential interdependence is the assembly line. Only after someones designed the car frame I can put in the seats and the engine. Only after one of my team mates has analyzed the market I can begin to develop the strategy for the firm. And finally there is Reciprocal Interdependence, which is the situation when the outputs of one of the teammates become inputs for the other, and vice versa, often in very reciprocal, cyclical, iterative fashion. So, imagine you're working on developing an online sales platform. Some of your teammates would be piloting that platform with beta testers and customers. Then taking the insights from this test to the developers. Working jointly with the developers to figure out what should be done to improve the sales platform and what can be done given the constraints. And then taking these improvements back to beta testers and the customers and likely running that cycle multiple times. I'm sure that many of you have quickly realized that reciprocal interdependence places the highest coordination demands on work, pooled the lowest, and sequentially somewhere in the middle. And again, it's important for us to recognize these different types of interdependence because that can help inform our managerial response to interdependence. Specifically in situations of pooled interdependence, we might get away with simply standardizing requirements for processes and outputs. That alone may be sufficient. So, back to the task of organizing the conference It might be sufficient for me to specify the budget for food, for stage set-up and acoustics, and for printing the fliers. I might additionally specify the acceptable range of sound for stage set-up and the percentage of vegetarian meals. Now, in sequential interdependence, There has to be a basic plan that would guide the hand offs from one team mate to another, in terms of when and how they would happen. And this is where centralized coordination by team leader can be quite effective. Meaning a team leader can take the primary responsibility in designing and executing that plan. Reciprocal Interdependence as we've just discussed places the highest coordination demands on work. It requires continues information flows, group meetings, multiple integrators. And this is where encounter a particular coordination trap that I would like for us to be aware of. Most team leaders, when they face a situation of reciprocal interdependence, recognize that they're up against very high coordination demands, that's not the problem. The problem is that their instinctive response is to centralize coordination, take charge of planning all meetings, control all deadlines. Micro manage the team and put it under a tight leash, and that can often backfire for two primary reasons. First of all, in reciprocal interdependence many of the coordination demands are not predictable in advance. They can not be anticipated in advance. They're emergent so for example, it's very difficult for me to predict what kind of feedback I'm gonna receive from customers and beta testers on the first round of testing that online sales platform. How well and how quickly my developers would be able to respond to these demands, therefore enabling a subsequent round of testing. And secondly, as a team leader I might not always have the best information o manage multiple coordination linkages. I'm not close enough to the problem and so your role here as a team leader becomes different. As opposed to centralizing all the coordination, the goal is to make sure that there are open lines of communication between piloting teammates and the developers. You want to make sure that there are incentives in place and relationships, so the developers feel comfortable reaching out to the piloting team mates and vice versa to solve ongoing problems. Now, this is not to say that you shouldn't have periodic check in status meetings that would help you understand the progress of the overall project. What I'm saying is that if you restrict coordination to those meetings alone, that can be grossly ineffective and inefficient. So, what are some of the best practices when I comes to dividing work and coordination? First of all, manage the size of the team. Recall from your discussion with Scott, that the optimal size of a team is around 6 to 10 people. If you get into double digits, coordination demands rise significantly. If your managing a team of 15 as a team leader, you may be responsible for over 100 unique peer wise connections among your team mates. Have clear goals and performance standards, that's essential no matter what type of inter dependence you're facing. Minimize links in communication. Note that that's exactly the type of response I advocated for in reciprocal independence. We can empower and enable our teammates to coordinate directly as opposed to asking them to go through me every single time. Division of labor should be focused on the ultimate goal of the group. What I mean by this, is that we could divide labor. In most situations, in very different ways. We can divide labor in a way that makes subsequent integration coordination easy or easier. And we can divide labor in a way that makes subsequent integration coordination very hard. So, let me give you an example. A client approached a team of consultants and asked them to evaluate the combined opportunities and threats their competition presented, given the client's product portfolio. Now, the leader of the consulting team quickly realized that they're three primary competitors and he signed one consultant to investigate each competitor. Now, it's a very clear, crisp, and unambiguous division of labor. Unfortunately, that division of labor made it very difficult to integrate the outputs of different consultants in one coherent product. Because it was very difficult to understand the collective presence, of the competitors in a particular product niche. The similarities and differences among their products, in the particular product niche. And again the collective opportunity and the collective threat they presented for the client in a given product segment. Don't give the most important task to the least committed person. Sounds very trivial and straightforward but keep in mind that there could be conflicts between private and shared goals. We can have different work load rates. And so that can make some of us more or less committed to particular projects. So, keep that in mind when assigning tasks and finally, try to preserve equity across projects, and not within individual projects. Recall that in course one, on motivating and inspiring individuals, we talked about the importance of equity and fairness. We also talked about the fact that it's probably futile to try to attain equity on a daily or weekly basis within every single project. If you get too preoccupied with making sure everybody is doing equal share in every project you will most likely end up slicing tasks way too thinly, thereby increasing coordination demands. Instead, think of how we can manage equity across projects. What I mean by this is put one teammate in charge of project a and ask them to do bulk of the work on that project, another teammate in charge of project b and ask them to do bulk of the work on that project, and so on.
