Ideal Team Structure — Forming Teams

New problems require us to develop new modes of working together.

Startups and innovators of all kinds attempt to solve problems that span disciplines and require teammates to collaborate across disciplinary boundaries.

The big problems startups endeavor to solve today span field. You want to solve a problem today? Great, just hop into business / design / technology / psychology / sociology / brand / marketing / management science. No big deal, right?! Many of today’s projects even grow to include elements of the broader social implications beyond the stakeholders of “company” and “customer,” things like the ethical implications of your invention, adversarial users, and  product end-of-life.

But how should we handle the rise of multidisciplinary teams solving today’s complex problems?

What’s the right way to structure teams to collaborate better and solve these problems more fully?

Quickly, let’s define some terms around disciplines, the depth skills that team members study and hone. A project can be:

  • Disciplinary — A project that is directed inside of a single discipline. If two disciplines are needed, they’re added as components (making a project multidisciplinary).

  • Interdisciplinary — A project that blends perspectives and methods from two or more fields. The back and forth creates learning about each discipline’s underlying assumptions. The project team’s work starts to develop concepts that cross boundaries.

  • Transdisciplinary — A project which strongly overlaps each contributor’s perspectives to create a new discipline (or at least explore creating one). Transdisciplinary teams also often consider the impact of the project on broad stakeholders and “the public.”

I’ve been searching the space, and I wanted to look beyond the usual teamwork and team design bookshelf — Creativity, Inc., Designing Together, Redesigning Leadership (and this new one which is coming out at the end of October, Turning People into Teams).

But then I found something super interesting buried in a student’s unattributed presentation. Scarlet Atkins (a student of some sort - ?) created a guide to ‘mechatronic product development’. What?! Uh, okay. Mechatronics concerns the design of household or industry-specific electronics, such as computers, phones, appliances, and hospital systems like MRI machines and heart-rate monitors.

In this kind of a project, the team will create a product. But doing so requires deep engineering skills to make the product work, UX design for the controls, industrial design for the enclosure, and mechanical perspectives for manufacturing the item. So companies in this space have spent a lot of time designing — and managing and evaluating — teams. And using each team member’s unique perspectives to harmoniously collaborate, navigate constraints and not just your discipline’s constraints), and ultimately delivering amazing solutions.

Here are three models for interactive product development.

  • Cooperative Specialists
    Each person on a team works as a trained specialist, with deep but narrow knowledge. The team members desire to cooperate and collaborate and so they establish a zone of cooperation between their areas. The project at hand is in the middle, between the designers and so it will include a bit of each disciplinary specialty, but with limited interdisciplinary work to blend the team’s perspectives.

  • ‘T-type’ Generalists - Japanese Model
    The Japanese model is quite different. Teammates are selected for their “T” shapes. They are all a team of generalists. While each team member has her own skills, disciplinary background, and department affiliation “developer,” she at the very least possesses passing knowledge of the vocabulary and methods from other domains. Others might have relatively deep skills in other domains, and their titles can be built to match —  companies sometimes explicitly name a “creative technologist” Other companies use the “slash,” where a single team member might be the “ux-slash-dev” or “ux-slash-designer” player on a team.

    Because of the influence of IDEO in design thinking — and perhaps the 1990s management buzzword for cross-training — the T-type generalist model is popular at many companies and agencies today.

  • Generalist Facilitator - The Finnish Model
    This hybrid teaming model was popularized by Finnish companies, especially Nokia, during heyday in the 1990s, but might be less popular in U.S. companies. The model anoints an interdisciplinary facilitator, who usually also serves as the team leader, as the single team member with the broadest and most overlapping skills. This facilitator servers as the orchestrator of the collaborative project, having deep skills and knowledge in many domains. He or she works with specialists who don’t have as much interdisciplinary knowledge.

    Pushing leaders to have a firm grasp of all of the domains used in the project might be somewhat simpler than hiring a full team of generalists. The idea that one person owns the “magic moment” — the insightful moment of synthesis where it all comes together — could appear undemocratic. But in some of the best product design work we’ve been a part of, this accurately captures how the team functions.

What model do you use? Is it explicitly designed did it implicitly evolve from the team dynamics? Who leads your product team — and what perspective does she have?