header

2003 Product Development Management Columns

Not All Teams Are Created Equal

A decade or two ago, the concept of a cross-functional team for product development was considered quite revolutionary. We have gotten used to the idea and virtually all organizations developing products today use “teams” drawn from different departments. Such teams are old hat and we have moved on to more advanced topics such as virtual teams – which seldom if ever actually meet in person – and co-development teams – which include suppliers, customers, development partners, and others from outside the organization.

In my experience, having worked with many organizations to improve product development, I believe that, as yet, few organizations are handling the basics very well, despite their claims to the contrary. They do indeed draw together – for meetings – individuals from several departments such as procurement, quality, testing, and regulatory. These meetings, which nowadays usually have a clear leader, a set and preannounced time, and an agenda circulated in advance, are more effective than they were before.

I believe that a real team is more than a group of individuals who have effective meetings. Because cross-functional interplay is the essence of product development, companies that aim higher than merely having effective meetings can develop better products faster than the competition.

Jon Katzenbach and Douglas Smith have devoted a whole book, The Discipline of Teams, to the distinction I’ve just drawn (this is a follow-on to their earlier book, The Wisdom of Teams; a review of The Discipline of Teams is available on another page).

They quite specifically define a team as, “A small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” This doesn’t sound too radical, but, for those who take these words seriously, its implications are profound. “Small number” means less than ten. “Common purpose and performance goals,” among other things, means common work products; in product development, for example, this could mean a single product specification document rather than separate marketing requirements and engineering specifications documents. “Mutual accountability” implies that individuals on the team cannot fail individually, because all members of the team are locked into mutual purposes, goals and work products.

Consider, for instance, the area of goals and responsibilities. Most teams I have worked with want to define roles and responsibilities up front so that they know where they stand as individual contributors. If the team doesn’t define its roles and responsibilities, then management will insist that it do so with sufficient clarity. But the beauty of a cross-functional team with complementary skills is that roles can shift over time to accommodate the workload and the skills available.

Katzenbach and Smith are clear in Discipline (more so than in Wisdom) that a team is not the right answer for all projects. Many projects simply do not require the mutual accountability and joint work products that are the defining characteristics of a real team for the simple reason that the extra effort needed to obtain these qualities will not pay off. In such cases, work groups can use a way of organizing their work that is far more common, and easier to institute – what Katzenbach and Smith call a single-leader discipline. In the single-leader discipline, a leader is responsible for assigning members to tasks and coordinating work products. In short, this leader becomes the “glue” that binds together the various activities in cases where mutual accountability and joint work products are not required. The current interest in project management tends to be in this direction.

The single-leader discipline, being easier to institute, is popular because it is sufficient for many types of projects. However, it is the nature of product development projects that they can often benefit greatly from the more intimate interplay that a real team affords. I believe that product developers can gain an advantage by employing a more powerful form of organization than would be completely satisfactory for their compatriots on customer service “teams,” sales “teams,” etc.

Katzenbach and Smith tie it all together with a diagram that is in the shape of a capital Y. The lower, common arm is effective groups, which is where most companies are today – they have effective meetings that provide limited cross-functional collaboration. The left arm is the single-leader discipline, which is one possible extension of effective groups, while the right arm is the real team, which represents an alternative. You are wise to be clear about which arm you are on.

 

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

test