External sourcing of core technologies and the architectural dependency of teams

Abstract

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