I’ve spent a lot of time thinking about, studying, and observing teams. By my estimation, I’ve been on more than 80 product development teams, and as a professor, I’ve mentored about 460 student teams. Many of those have been interdisciplinary teams involving people trained in engineering, business development, computer science, industrial design, and more. In the process, I’ve learned a few things that I wish all team members -- on all teams -- knew. Here they are.

Team Productivity and Frustration

Of all the ways to think about teams, Katzenbach and Smith’s definition most closely aligns with my experience and expectations for high performing teams. They define a team as “a small number of people with complementary skills who are dedicated to a common purpose, set of performance goals, and approach, for which they hold themselves mutually accountable” [1].

A team’s “productivity fuel” is at the center of Katzenbach and Smith’s definition. It is the team’s dedication to:

A common purpose, A set of performance goals, and An approach for achieving the goals and fulfilling the team’s purpose.

Without dedication in these areas, the team will flounder, or simply not perform.

Don’t be mistaken, there is nothing trivial about this. For many teams, it’s a difficult thing to agree on or even articulate what their purpose is, let alone rally around a set of performance goals that everyone values.

The challenges can get exponentially worse when we include the approach in what needs to be agreed to since most team members tend to forget that there are multiple good approaches to meeting the team’s goals and fulfilling its purpose. This is particularly easy to do when working in interdisciplinary teams where disciplinary norms and vocabulary mean the approaches chosen may be completely foreign to some team members.

A significant contributor to design team frustration is the common misconception that goal setting and design are serial activities, where concrete goals are established and then everyone designs. While it is true that there should be some understanding of goals before getting creative about solutions, it’s more realistic to expect only an initial high-level goal to be set at first. Progress is then made and new insights are gained, which leads to refined goals and more focused work. This is natural and normal, but not easy to deal with.

Because of the traditional engineering curriculum, it can be particularly unsettling for some engineers to work on ill-defined problems [2]. It can be equally unsettling for business developers to drive toward goals and purpose based on incomplete information about the market, or the problem. The tension between team members in these situations is real, but avoidable when remembering that the problem definition and the solution evolve together [3].

Becoming more Interdisciplinary in our Teams

There are basically two kinds of design teams; interdisciplinary and multidisciplinary teams. Interdisciplinary teams outperform multidisciplinary teams in the outcomes produced, in team member satisfaction, and in long term stability. So if we have the choice, which we do, we want to be more interdisciplinary whenever possible.

Tim Brown’s book, Change by Design, describes the difference between teams that behave in a multidisciplinary versus an interdisciplinary way [4]. In the margin of this book, I drew the image shown here, which captures his words that in multidisciplinary teams, individuals are advocates for their own technical specialty and the project becomes a negotiation among them -- resulting in a gray compromise. In contrast, they describe an interdisciplinary team as one where there is collective ownership of ideas and everyone takes responsibility for them.