| dc.description |
How do teams complete a task involving critical knowledge that is both complex and
external to the team itself? This is a task characterized by a particularly difficult tradeoff
between external search for important knowledge on one hand and internal
coordination on the other. I explore the question in an inductive study of new product
development teams in the pharmaceutical industry. Specifically, I investigate different
approaches to managing the important task of core technology sourcing (the
identification, evaluation and integration of an external technology that constitutes a
core subsystem of the product). This research resulted in two key findings. First, in
contrast to previous research suggesting that high-performing teams do not engage in
any significant external search for complex knowledge, or that such search should be
limited to the early stage of a team's work, the study finds that a positive team outcome
is associated with continuous deployment of many search modalities of different kinds.
By coupling this search behavior with intensive communication and flexible
decision-making, internal coordination problems are offset and the benefits of external
search are leveraged. Second, this research shows that search behavior is significantly
dependent on factors external to the team. Specifically, search behavior is enabled by
factors in the task environment, such as how structures and processes are designed at
the organizational level, and by the knowledge handed down by previous teams.
I develop the concept of "architectural dependency" to capture how the behavior of
core technology sourcing teams is dependent on factors configured across three
fundamental dimensions (the team, the task environment, the behavior of previous
teams), and importantly, the way that they are linked together. These architectures of
factors are molded only slowly over time, and I found this change to be driven by the
overarching organizational regime adopted at the organizational level. I conclude by
discussing conditions under which architectural dependency may be useful as an
interpretive key to team behavior in settings other than core technology sourcing |
|