So welcome back, to our course on strategic innovation. In this video, we're going to continue to connect teams, and innovation, and we're going to focus on teams in product development efforts. Our particular interest here today, is with cross-functional teams. And, cross-functional teams that have a major responsibility for product, or process development. So this is a specific way of thinking about, what a team is going to try to accomplish. And what I'm going to do today is, I'll be drawing on an article, and research by Professor Wheelwright and Clark at Harvard, about what they call "Heavyweight" teams in product development. What they mean here, is really cross-functional teams. But we'll see that the term Heavyweight, is an important one in the article. There research is, I would call it classic and enduring. It happened quite some time ago, and I don't think there's been work that has had this particular focus and insight, since that's added to it. In fact, it's received some recent attention. For instance, no less than Clayton Christensen, devotes considerable discussion of it, and its value. The value of this kind of team, in his new book "The Innovators Solution". So this is going to be our focus here. Let's step back, and just talk for a minute about, why teams are so often used in innovation related projects. We know that, where innovation and new ideas are concerned, there's a lot of uncertainty. And that uncertainty might spread across the market, it might spread to the technology, it might spread to whether we can manufacture something, what its costs might be. And so one of the major challenges in product and process development is integration of different capabilities, so that we can create something new. That is, how are we going to effectively manage and coordinate, the work of a team whose members are based in different functions, engineering, marketing, manufacturing, and so on. And they have different expertise, different expectations, they use different systems, different routines. Now teams seem naturally suited to this task, because in different ways, individuals across functions can be brought together. And, really, this is no different in many ways than why teams are used in general. And so, if we think about that, one of the important points to have in our mind, is that team's success, is by no means assured. No less an expert than Richard Hackman, one of the deans of the team gurus, penned an article entitled "Why teams don't work". And one of the big points in that article, was that we tend to assume, that if we pull a group of people together, and assign a leader, and call it a team. Then it's going to work more effectively than individuals. And he suggests that that belief is really an error, he saw a great number of teams that had failed, and he described a number of pitfalls. So his call was to design teams effectively, and pay a lot of attention to team process. And so, team research calls attention to a number of different key design elements for teams in general. These are things like compelling goals, leaders who can take a team perspective, membership, so that people are clear on who is on the team, so it constitutes a real team, enabling structure such as rewards, a supportive climate, and many more. Now, these are all important relative to our course, but we aren't going to go and repeat general insights about effective team leadership, and design here. Instead we are going to narrow down, and look at teams from a specifically innovation centered perspective. We know already, from the prior two modules, that this brings some particular challenges. So if we put those ideas together, I do think we can gain some insights about the specific success factors and pitfalls that teams encounter in this context. What we're going to do is, we are going to discuss four different designs for development teams. We're going to call those and you can see them on the diagram. Functional team structure, a lightweight team structure, which is simply where we've added a project manager, a heavyweight team structure, where this is truly a cross-functional team, and then the autonomous team structure, where we've pulled people out of the functional structure entirely. So what I'll be doing is talking about what these are, what their advantages are, what their advantages are supposed to be as well, and what their disadvantages are, that is what tends to actually happen, how it isn't necessarily going to work out quite as planned. What we're going to do is we're going to have a brief discussion of each of these kinds of teams. And then in the next video, we're going to go in more depth on the cross-functional, or heavyweight team, as Clark and Wheelwright call it. So first, let's discuss functional teams. You can think of this as the traditional approach, where teams exist within functions. Each of those circles would be individuals within a function. Those would be separate teams on the diagram. And there would be a team in each function, that is managed by a functional manager. The project's specifications and tasks, are mapped out in advance. And so the primary responsibility for the project passes sequentially, from function to function. It might go from engineering to marketing, or sometimes the other way around, and then to production or operations. This is evident in this diagram, where we have nothing linking the teams across the functions. This approach is not without its advantages. What it lets us do in a very straightforward way, is to bring deep and specialized expertise to bear on the problems at hand. Because, within each function, we have the specialists. People who have repeatedly worked within the same knowledge domain, and so each project is able to build on knowledge gained in previous ones. If we're building airplanes, and we have someone who has worked on two generations of landing gears, that persons can barely be on this project. And we'll get the benefit of that. And if we're designing a microprocessor, and there's a particular part of that microprocessor, that someone has worked on the last three generations on, we're going to get the benefit of their experience. Because the functional manager, is going to be able to make some very nuanced assignments of tasks and individuals. This approach also has the advantage that it aligns authority, and responsibility, and rewards. Because the functional managers, they control the resources, the people on the team, in whatever team has primary responsibility, so the marketing manager is going to control the marketing professionals. And that functional manager, not only controls the resources, has authority over them, they have responsibility for that part of the project. And these managers having some expertise in their area, are relatively easily able to assess task performance and they can provide rewards such as promotions. So we have some advantages here. But, there are important disadvantages. And it's almost evident right on the diagram, there is nothing linking the functions. Each function is working on this almost on its own. And so coordination, and integration, between the functions is weak. One example here is, when we transfer responsibility across, from one function to another, as each completes its part of the project. That's not always smooth. This is quite a siloed approach. As importantly, there's nobody who is actually the owner of the project in this scheme. Often, no one who works on the project is responsible for the results that are finally achieved. There's no one where the overall success of the product is their metric. Instead, the metric tends to be best practices within each function. Now, it's not just ownership, it becomes commitment. Because commitment to the project might vary across the functions. This might be a technologically exciting project that engineering is very much into, but the marketing doesn't see a market for. And so, their commitment is weak. And this links to what we've seen before, we've seen before how new ideas can have trouble competing for attention and resources with established ones. And you can see how in this approach, that variability in commitment could really cause problems. We might have two functions that do well, and one that does poorly, the project as a whole might do poorly as a result. Finally, the nurse is going to be strong here. Each function is going to look at the task, through the functional lens. They're going to try to do what is best practice within the function, and to reapply old solutions. Rather than thinking how we might conceive of a new model. So to a certain extent, this forms are our default model. And in situations where we're addressing markets, that we've addressed before, with technologies that we basically address before. It can actually work quite well because the coordination needs are not that extreme. But if we have a more challenging project, then we need to improve on these issues. And, a common response, to issues with the functional team, is that we had a project manager to the mix. So in this approach, we have a project manager seen there to the side, and a liaison person in each function who is designated to work with that project manager. So now we've got a way of going across the functions. Otherwise, the team design is generally similar to the functional one. Members remain in their functional areas, and so many advantages of that approach remain what we're trying to do is to improve on the coordination, the communication, across functions. And the way that happens, is the project manager's regularly meeting with liaisons, and problems in one functional area that might affect others can be surfaced and resolved through this process. That's the idea. The trouble according to Clark and Wheelwright's research and other research, is that these expected improvements in coordination, and communication, are not so easy to achieve. And often they're not achieved. Now remember, when I first mentioned the kinds of teams, this was labeled as a lightweight team. I basically described it as a functional team with a project manager. They call that a lightweight, and that becomes important in understanding where these problems come from. The project manager is the lightweight. That's the key thing to think about. The project manager is typically a mid-level person, who has limited status and influence in the organization. And they have enough knowledge to coordinate, they have enough knowledge to work with people at the working level. But there are some key implications. And the critical thing is, that sure, the project manager can inform and coordinate, they can update schedules, but they can't make key decisions. They don't have control of the resources. And that is all important. We've seen how product development requires navigation of many political challenges. And resolution of many conflicts. So, the lightweight managers might be able to communicate that this is an issue but then they're going to the individual functional managers at the top of the organization, and all they can do is influence those managers. In that previous example where marketing wasn't very excited, about this particular opportunity. The project manager might go to them and say that they're not working quickly enough, and the vice president might nod, and say, "I see what you're saying, I'll see what I can do." But they're not addressing the concern, that within marketing, there isn't enthusiasm for this project overall. So, Clark and Wheelwright, actually in their research, they come to quite a pessimistic conclusion that the project managers tend to be tolerated at best, and are often ignored when the innovations are challenging. Because there's more important things going on than these project managers can really address.
