Skip to main content

.

.

.

How to Get Experts to Work Together Effectively

How should teams of experts working on knowledge-intensive projects be structured? Should they be hierarchical? Or will flexible, self-organized groups perform better? 
Teams often struggle with how to get the most value from the members’ expertise, to minimize conflict, to integrate their diverse expertise, and to leverage it during all phases of a project.

The traditional approach is to put the person with the most experience and expertise in charge — for example, a head coach or a chief programmer. The assumption is that this person has the expertise to make the best decisions about how to allocate tasks and responsibilities. Teams that adopt this model feature a rigid hierarchy, whereby final decisions are centralized through this single, formally designated individual.

The downside of this approach is that when projects increase in complexity and team size, the central individual can become a communication and coordination bottleneck for the team.

Another approach is to let teams self-manage. This approach is evident in, for example, agile software development methods. The assumption of this model is that team members are best equipped to match skills with needs and to organize their own tasks accordingly. These teams are characterized by broad, open sharing of expertise and by decentralized decision making. While this approach allows ideas to flow freely, it dramatically increases the number of people who need to frequently interact with each other. Thus the approach increases coordination demands and can reduce efficiency.

Whether centralization (star structure) or decentralization (wheel structure) leads to better team performance has been a long-standing debate in team management. Most managers recognize the inherent challenges in each model. Perhaps intuitively, many seek a spot in between: neither strict hierarchy nor boundless flexibility. But is this really the best way to work?

Our research reveals an unexpected answer.
We studied how expertise was organized in 71 software development teams in a large U.S. high-tech company during the design and implementation phases of projects. A total of 484 individuals participated in our study; they had an average of 12 years of experience. We asked team members to nominate up to four individuals with design expertise on each team and up to four individuals with technical expertise. Next, we asked them to assess how valuable the named individuals’ expertise is to their work. (We calculated a team’s network of expertise by weighing how valuable their expertise was to their work.) We then created a network map of team expertise, based on the nominations and weighted by the reported value. This allowed us to use social network analysis to calculate the centralization of expertise for each team in the design phase and in the implementation phase.

To our surprise, we found that the highest-performing teams were the ones that adopted a different configuration of expertise depending on the needs of the project phase. They decentralized design expertise when identifying solutions, and then centralized technical expertise to build them.

Additionally, if the knowledge required for the project was complex, novel, or otherwise difficult to share, decentralizing expertise during design and centralizing it during implementation became even more important. Teams following this pattern achieved higher ratings on multiple measures of performance: higher coordination success, less team conflict, increased team effectiveness, and higher client satisfaction.

Our findings suggest that different project phases require different ways of organizing expertise. Rather than doggedly following either a strictly centralized or decentralized approach, teams should recognize that the design and implementation phases deal with different kinds of knowledge. Specifically, in complex knowledge work the design phase favors divergent, creative exploration of a broad canvas of conceptualizations and ideas. Decentralized configuration of expertise is appropriate for this phase because:
  • By broadly eliciting and sharing expertise during the design phase, high-performing teams can achieve a better understanding of ill-structured, poorly understood problems, and converge on and design an optimal solution.
  • While figuring out what needs to get done — encompassing requirements, gathering, and design — a decentralized approach reduces team conflict and leads to more effective solutions.
  • Broadly tapping team members’ expertise reduces the risk of myopic, insular thinking that can occur in a rigid hierarchy. This was confirmed by our finding that the more difficult it was to articulate a design problem, the more important it was to involve team members broadly.

Later, as the team moves into implementing that solution, centralizing expertise more narrowly among a few designated experts is appropriate because:
  • Building out a solution favors convergent deep knowledge of how best to concretely implement a solution.
  • Centralizing design expertise avoids the pitfalls of analysis paralysis. During implementation phase, a focus on building leads to increased efficiency.
  • For implementing an already identified and specified design, having centralized expertise and clearly defined roles and responsibilities reduces team conflict and reduces coordination requirements.

This research suggests that when managers are staffing, organizing, and managing knowledge projects, they should embrace flexible organization of expertise — based on the needs of the project phase — in order to maximize team performance.

- Sri Kudaravalli , Samer Faraj and Steven L. Johnson

Comments