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