Supporting X-Teams

The more dependent a team is on knowledge and resources in its external environment, the more critical is the organizational context. Companies that want highperforming X-teams can create a supportive organizational context—with three-tier structures mandated for teams, explicit decision rules, accessible information, and a learning culture. Within a company, it's generally the organizational unit that sets those parameters, provides resources, and lays down rules. (See figure 13.2.)

Figure 13.2: Creating an X-Team

A large pharmaceuticals company that we call Pharma Inc. illustrates the importance of such support. One of the authors was asked to investigate a dramatic performance variation among drug-development teams that were working on molecules from external sources. (Such projects are known as in-licensing projects.) A performance assessment showed that the teams of one unit were doing well, the teams of a second unit showed varying results, and the teams of a third unit were doing poorly. To probe the differences, we picked a chronological sequence of three teams at the best-performing site (the Alpha site) and three teams at the worstperforming site (the Omega site) for a careful study.

The story that emerged seemed almost implausibly black-and-white: All the central steps the three Alpha teams took seemed to contribute to positive performance, whereas the opposite was true for the Omega teams. It appeared that despite fluctuating external circumstances, the Omega teams were sticking to a traditional approach that had served them well enough when they worked on internally developed molecules. The Alpha teams, however, were adapting to the changing environment by using an X-team approach, although they didn't call it that. In the wake of the molecular biology revolution, which has led to increased use of in-licensed molecules, they saw the importance of external activity and extensive ties, and they adapted.

Three-Tier Structure

Organizational structure has a profound effect on team behavior. All Alpha-unit teams used a mandated three-tier structure that gave core members oversight of the activities of operational and outer-net team members. Importantly, the roles were not a reflection of organizational hierarchy. Often a core-team member was junior in the organizational structure to an outer-net member.

Having the core team tied to the outer net was particularly helpful when much external technical knowledge was needed quickly. With links already established, a core member could get information from an outer-net member at short notice. The brief time commitment for serving on the outer net gave X-teams access to some of the company's most sought-after and overbooked functional experts.

The Omega-unit teams, however, used a traditional one-tier structure. In X-team terminology, the Omega teams had only core members. Although that worked well for coordination, it hampered team members' ability to adapt to changing external demands.

Explicit Decision Rules

X-teams favor decision rules that adapt to new circumstances. The Alpha unit's X-teams, like most product-development teams, used traditional flow charts, but they constantly updated them. Also, they complemented flow charts with decision rules that allowed the charts to become evolving tools rather than constraints. One such rule was that, all things being equal, the search for solid information was more important than speed. It wasn't that the teams tolerated slackers. In fact, at times speed had to take precedence over information, but it was the team leader's responsibility to identify when that should occur.

Another rule mandated that whenever important expertise was not available in the time allotted, a team member would be free to bring in additional outer-net members. Such rules allowed for flexibility but spared team members any ambiguity about what to do at important crossroads. Furthermore, the rules gave them the confidence to act on their own and to raise issues needing discussion. For example, it was never wrong for a team member to suggest that a process be stopped because of a lack of important information in that member's area. Even if the team overruled the request, speaking up on the basis of an explicit decision rule was definitely appropriate.

The Omega unit's teams, by contrast, used process flow charts quite rigidly and without complementary decision rules. Team members had to stick to the planned process and were allowed little latitude for tweaking the process even when they saw the need. There was no mechanism for making adjustments.

Accessible Information

Access to valid, up-to-date information is always critical, but when knowledge is widely dispersed, the information infrastructure becomes even more important. The Alpha unit had processes that supported teams' need for accessible data. After every project, a report was written detailing important issues and the lessons learned. The store of reports increased over time. In addition, the Alpha unit maintained a "know-who" database, which provided names of experts in various fields and explained the unit's historical relationship with those experts.

Unfortunately, at Omega, project reports were written only occasionally and contained mainly the results of internal lab tests. And Omega did not have a know-who database at all.

A Learning Culture

A useful information infrastructure cannot be established instantly. It has to be nurtured. That's why Alpha insisted on project reports whether or not the project was considered a success and regardless of time pressures on team members. Alpha also saw to it that past team members conferred with ongoing teams.

Strong recognition from top management at the Alpha unit reinforced the information infrastructure. The relentlessly communicated learning culture not only generated positive performance for any given team, but helped make every team perform better than the previous one.

The Omega unit had no such practices. As a consequence, new teams in that unit generally had to reinvent the wheel.