J.L. Kellogg Graduate School of Management

TRANSFERRING KNOWLEDGE IN THE R&D ARENA: LINKS, LOOPS, AND LEARNING IN THE TECHNOLOGY TRANSFER PROCESS

DANIEL Z. LEVIN

Department of Organization Behavior J.L. Kellogg Graduate School of Management Northwestern University Evanston, IL 60208-2011 (847) 491-3470 Fax (847) 491-8896 [email protected]

THOMAS A. KAPPEL

Industrial Engineering and Management Sciences Department McCormick School of Engineering & Applied Science Northwestern University Evanston, IL 60208 (847) 467-2043 Fax (847) 491-8005 [email protected]

February, 1998

An earlier version of this paper was submitted to TIM Division, Academy of Management

1 TRANSFERRING KNOWLEDGE IN THE R&D ARENA: LINKS, LOOPS, AND LEARNING IN THE TECHNOLOGY TRANSFER PROCESS

ABSTRACT

This paper looks inside the “black box” of organizational learning and knowledge transfer to show contextually how an organizational routine – the process of transferring a technology from research and development (R&D) to a business unit – operates in practice. The resulting conceptual framework applies and links such elements as personal relationships, buy- in, and expertise, as well as several learning loops. Whereas much of the literature depicts organizational learning as a kind of sterile, anonymous process of building organizational skills and competencies, this research finds organizations that have the knowledge and skills in place, know how to transfer them, and are even improving the learning process, yet still fail to learn and transfer knowledge. This paper proposes that such organizations have the ability, but do not want to learn; know how to transfer, but lack the personal relationships to make the connections to enable it to happen; and “improve” the learning process by becoming risk averse.

2 The areas of organizational learning and knowledge have recently been generating a great deal of interest among both strategy scholars and practitioners (Miner & Mezias, 1996). This exciting emergence is nowhere more important or relevant than it is in the research and development (R&D) arena. For the R&D arena, indeed the entire technology management domain, is one of the most knowledge-intensive environments in the modern corporation. Moreover, the very purpose of R&D is to foster intensive learning and knowledge transfer within the organization. R&D, after all, is in the business of absorbing, creating, adapting, and transferring new ideas, knowledge, and technology to the rest of the company (Cohen & Levinthal, 1990). In short, there is no R&D without knowledge transfer. For “R&D produces one product only – knowledge” (Roussel, Saad, & Erickson, 1991: 67). One method for studying knowledge and the transfer of knowledge – defined here as the transfer from one person or group to another of consciously recognized information and know- how (Huber, 1991) – has been through the use of a learning curve methodology (Argote, 1993; Lester & McCabe, 1993; Levin, 1997). This quantitative methodology, though, cannot say what kind of knowledge was transferred, nor when, how, or how often this process occurred. In many ways, then, knowledge transfer, as investigated by the learning curve methodology, is a measurable, rigorously explored phenomenon, but it is also a bit of a black box. To answer the question of how knowledge transfer actually works, a different kind of methodology is required, one that allows the researcher to look inside the “black box” of knowledge transfer and to generate theory that is grounded in what people inside organizations are thinking and doing.

A PROCESS-BASED APPROACH To tackle this challenge, one exciting and useful approach is to systematically study the generic routines (or, processes) that organizations use (Levin, Radnor, & Thouati, 1997; Pentland & Rueter, 1994). Routines in the technology management domain, for example, would include the technology strategy-making process and the technology transfer process. This approach is especially fruitful because organizational routines form the basis for organizational learning

3 (Levitt & March, 1988), yet “much remains to be done at both the empirical and the theoretical level” (Grant, 1996: 384). Moreover, as noted by Levin et al. (1997), focusing on the routine, or process – defined here as a set of related activities – results in research that (1) better reflects the reality of organizational life, (2) better understands the terminology, jargon, and thought patterns (i.e., the “cognitive categories”) that organizational members use to describe their organization and how work gets done, (3) better discerns how organizations adapt in a dynamic way to high- velocity environments, and (4) better translates rigorous research into findings that are useful to practitioners, a goal recently endorsed by several organizational science leaders (Galunic, 1997; Hambrick, 1994; Mowday, 1997). So in the technology management domain, what are the processes used by large organizations, which do most of the industrial R&D (Raber, 1997)? This question was answered in a recent one-year research study conducted by a unique partnership of academic scholars and of practitioners in a half-dozen large technology-oriented companies – under the auspices of the National Center for Manufacturing Sciences (NCMS) consortium. This partnership is in accord with recent calls by academics for greater practitioner/scholar collaboration in the area of organizational learning (Miner & Mezias, 1996). The data for that study came from fieldwork at participating companies (interviews, document analysis) and a Delphi-type technique whereby key participants from the companies came together to meet frequently with academics to discuss what the key activities in the R&D arena are. This innovative iterative methodology yielded an overall framework of technology management processes. For each process, the researchers developed a description, a long list of key issues, potential best practices, ways in which academics or practitioners have tried to measure the process, relationships to other processes, and references to the literature (National Center for Manufacturing Sciences, 1996). The inter- relationships among the 27 technology management processes, where the output from one process becomes the input to another, describe the flow of knowledge in the technology management domain.

4 If one looks at these processes systematically, a handful stand out as particularly crucial in the R&D arena, and it is these that are the focus of the current stage of the research program. That is, while all or most of the 27 processes identified are important, three or four “linchpin” processes fill a kind of structural hole (Burt, 1992), as a middleman, in the overall network of processes (i.e., in the flow of knowledge among the processes). These R&D linchpins were identified as a result of two methods, described in detail in a separate paper, which yielded an encouraging degree of overlap: a formal, quantitative network analysis of the process inter- relationships and qualitative discussions with participating practitioners. In total, four linchpins have been identified: (1) technology transfer, (2) technology roadmapping, (3) technology needs assessment, and (4) R&D portfolio management. So while much of the literature on R&D focuses on the process of executing an R&D project – even equating all of R&D with this one process – our focus is quite different. It is on those linchpin processes that surround and make possible, via knowledge transfer linkages to the outside world and other parts of the organization, the execution of R&D projects. Of these four R&D linchpin processes, it is technology transfer – defined here as the transfer within a company of a technical artifact from central R&D to a business unit – that is the most knowledge-intensive of all and which is the focus of this paper. Note that this focus is more in the tradition of research on commercialization of new technologies, especially point-to- point transfer, than in the diffusion-of-innovation research tradition from economics, sociology, and marketing (Leonard-Barton, 1990). This process is in fact one of the most problematic in the often-strained relationship between R&D and other parts of the organization. Typical complaints include: business units (and their customers) do not want to adopt enough of what R&D develops; R&D does not develop enough technologies that business units want (i.e., is R&D relevant?); the technology transfer process is too slow and expensive; R&D and the business units do not communicate well. Note, however, that the goal here is not to take a reengineering approach and provide a step-by-step “process map” of how technology transfer does or should take place; that is perhaps a job best left to consultants and practitioners themselves. Rather, the

5 research goal is to uncover the underlying mechanisms and factors – from a theoretical perspective – that are at work in this process (routine). In addition, in past work (National Center for Manufacturing Sciences, 1996) and in future reportings of this research program, we devote more attention than space permits here to the linkages into and out of technology transfer and the other linchpin processes. The basic conceptual framework of intra-company technology transfer proposed in this paper begins with an R&D lab and the business unit, but it also incorporates important influences from the organizational and external environment. In short, goal of this research is to generate a grounded, conceptual model of what makes this process “tick.”

METHODOLOGY

Research Sample This program of research is first and foremost based on in-depth fieldwork at five core companies participating in the research program. The companies, which all belong to the NCMS consortium, are in different industries but all have a connection to technology and manufacturing. Note that the sample of companies is not random because the research goal is not to draw statistical inferences but rather to generate grounded theory (Eisenhardt, 1989; Glaser & Strauss, 1967). Both authors jointly conducted interviews of managers and engineers in central R&D labs and in the business units of these five large multinational companies. These in-person interviews took place in 1997, beginning in the spring. In addition, a small number of follow-up visits are planned for early 1998.

Data For the technology transfer process – indeed for all of the R&D linchpin processes – we developed a detailed 5-7-page position paper interview guide. This document, which includes a description of the process and a list of open-ended questions, was derived from the initial one- year research study of technology management processes (National Center for Manufacturing

6 Sciences, 1996). For technology transfer, the company contact within each of the five companies chose at least two R&D-related projects, one more successful, one less so. We then interviewed the relevant individuals, and a few others we suggested, about those technology transfers and about technology transfer and technology management more generally. We also gathered background material and documentation (e.g., organization charts, reports, presentation slides) from the contact people and from interviewees. Typically, interviews were one hour (sometimes longer) with approximately 75 people on eight visits to company sites in California, Florida, Pennsylvania, Illinois, Ohio, Michigan, New Jersey, New York, and Wisconsin. Slightly more than half of these interviews focused exclusively on the technology transfer process; the balance, on the other R&D linchpins or on technology management in general. In addition, several telephone interviews on technology transfer were conducted with people in Canada and the Czech Republic. All interview notes were typed by both interviewers and merged into a single document. This document, typically about 50 single-spaced typed pages per company-visit was then summarized in a 5-7 page trip report. In addition, to supplement these case studies, this research also used innovative approaches such as roundtable discussions among academics and practitioners from core and outside companies, as well as informal academic/practitioner analysis discussions.

Analysis

One of the advantages of having multiple companies participating in the research is that we were better able to triangulate among different data sources, such as cross-company and cross-interview comparisons (Eisenhardt, 1989). To interpret the more traditional data – the interview notes – both authors held intensive “analysis meetings” over a two-month period. In these meetings, we went through most of the interview notes line by line, using the interview notes as a jumping off point for generating new theoretical insights about the technology transfer process. In addition, these analysis meetings included our reactions to the relevant literature in organizational theory and technology management, as they related to the interviews and

7 emerging insights. Towards the end of this analysis effort, we developed theoretical connections among the categories of insights that emerged from the analysis. Finally, in an effort to make sure these theoretical insights remained grounded in the reality of organizational life, we presented some of our ideas to participating practitioners; for theoretical coherence, we did the same with academics.

BASIC FRAMEWORK OF TECHNOLOGY TRANSFER Based on this analysis of the case-study fieldwork, we derive a basic conceptual framework, shown in Figure 1, of the technology transfer process in large companies. ------Insert Figure 1 about here ------This framework is not a chronological, or process, model of events; rather, it shows the major proposed relationships among the key conceptual elements underlying the process. For clarity of presentation, only the major proposed connections (without any secondary, or bi-directional, links) are shown. The framework incorporates insights on the elements of relationships, expertise transfer, coordination, ability to adopt, buy-in, and outcomes, each of which is described below in detail following a description of the R&D/business unit boundary. Then, additional learning and contextual elements – feedback loops, a negative learning loop, technology life cycle, technology strategy – are added to the framework and discussed.

Background: The R&D/Business Unit Boundary Before talking about transferring a technology from R&D to a business unit, the first question one needs to ask is why even have a transfer? Why have a separate R&D group in the first place? Technology transfer, and the existence of the R&D functional group, is needed because longer-term development or research cannot easily survive in the short-term environment of a business unit, with its daily distractions and focus on stability, reducing uncertainty, and avoiding disruptive change (Thompson, 1967), all of which come with new

8 technology (Rubenstein, 1989). In fact, these points are the very reason that industrial R&D labs were created in the first place nearly a century ago (Hounshell, 1996). Yet at one particular company, we observed, R&D is increasingly working at a fever pitch, with more deadlines and business unit orientation, becoming closer and closer to a product development group. This example is part of a major trend, or pendulum shift, in U.S. industry (Chen & Rao, 1997). This is a game, however, that R&D people can never win: they will never be as fast, cheap, or good at product development as the actual development engineers are, and in the attempt, they will also lose their advanced technical expertise and skills at understanding and developing new technologies, a capability which was the original justification for having a central R&D lab separate from the day-to-day hub-bub of the business units. Still, since technology transfer can be so problematic, some would suggest that it should be eliminated in favor of one unit performing both R&D and commercialization functions. This combination can happen in one of two ways: (1) Some business units, we observed, find the technology transfer process so burdensome that they do not use R&D at all; the business unit is given the new task of doing technology development, as well as technology scanning. Inevitably, the result is a crowding out of long-term R&D (Rubenstein, 1989). (2) R&D does the commercialization work itself, as, for example, one company in our study attempted with a particular technology where a new business unit lacked the engineering capabilities required for commercialization. The result here was that R&D people had difficulty adapting the technology to the many end-user requirements and constraints, with which they were unfamiliar. They were also weak at development tasks like documentation; in the above case, for example, a business unit engineer noted, “When we started wiring up the equipment, we’d find terminals that didn’t go anywhere! So we’d have to ask, ‘What did you intend to do with this?’ ” Thus the second question worth examining is: where is the boundary located in the technology transfer process? All technology transfers involve adaptation (Leonard-Barton & Sinha, 1993), but who will do which parts of the adaptation? In one sense the company wants a clear boundary to avoid the problem of tasks falling between the cracks and finger pointing, but

9 it also wants a flexible boundary to handle different technology transfer situations. Moreover, technology transfer is generally not a single handoff; it is a series of handoffs. In addition, some of these handoffs are done more than once (i.e., iteratively) in an effort to refine and adapt the technology. Technology transfer is thus not a point, it is a zone, with multiple actors interacting over time. Organizations have long had to deal with how to span departmental boundaries (Lawrence & Lorsch, 1967), and one technique for doing so is the use of boundary spanning individuals (Allen, 1977; Tushman & Scanlan, 1981). We found two variations on this theme for the R&D/business unit boundary: (1) As one might expect, these liaisons seemed to have more success when they had work experiences on both sides, or could at least “live” in both worlds. For example, one marketing person found it easier to communicate with technology people because he had a technical background; at another company, an R&D manager who was a much- praised liaison to the business unit was quite business oriented and understood commercialization and market issues well. (2) In one case of technology transfer, a company transferred a lot of deep knowledge from one group to another group by using a “counterpart matching” system, whereby knowledge was transferred between two paired individuals. This pairing up of an R&D person with a functional counterpart person in the business unit primarily enabled them to learn from each other, as a kind of mutual apprenticeship. The paired individuals were also reportedly more willing to cooperate on each other’s tasks, and on tasks which might otherwise fall between the cracks.

The above discussion on the why, where, and how of the boundaries between R&D and commercialization activities forms the basis for an analysis of what occurs inside the “technology transfer zone.” And it is within these boundaries that we now turn to study the interactions and communication among the relevant actors. We propose that this interaction serves three main purposes: relationship-building, expertise transfer, and coordination.

10 Relationships The finding presented here is a demonstration, in the R&D arena, of what might be termed “the human face of learning.” For, contrary to the conventional view, which sees technology transfer as largely anonymous and easily outsourced, this “human face of learning” model suggests that transfer is more likely to occur, and occurs better, when a personal relationship exists between senders and receivers, at both the managerial and technical staff level. For example, in the successful “epsilon” project at one company, two top engineers at a remote R&D lab moved thousands of miles to live at the business unit for 8-9 months before the project began. As their R&D manager noted, “This builds a personal relationship. The guys go for a beer in the evening. . . . They know each other well. . . . This initial stay in [that location] helps a lot.” In contrast, at the same company, another R&D project that ultimately failed was staffed by a new employee and by an engineer who acknowledges he is not a big “conversationalist” type and who lacked close relationships with potential receivers in the business unit. When it came time to transfer the technology, the reaction of the product developers in the business unit was, “Who are these guys?” This transfer ultimately failed in part because, without any kind of good, working, personal relationship, R&D was unable to overcome the business unit’s resistance to the new technology. These findings are linked to theories of embeddedness, the notion that economic action is embedded in a network of social ties (Granovetter, 1985; Uzzi, 1997), although this paper looks within the firm; and to theories of bureaucracy, with their emphasis on informal structure (Blau, 1963; Blau & Meyer, 1971). They are also consistent with the study of transferring best practices, a domain where it has been found to be important not to have an “arduous” relationship (Szulanski, 1996). Finally, this paper’s findings are consistent with early work on interaction within R&D: “We continually encounter the phenomenon of ‘old buddies’ working together and supporting each other; giving a man another chance, even though he may not deserve it; and communication channels dominated by friendships and historical relationships” (Rubenstein, 1966: 417).

11 Interestingly, the importance of personal relationships for technology transfer is especially important when the technology is more complex or unfamiliar to the business unit receiver. The underlying theoretical reason is twofold: (1) Having a personal connection to the R&D sender boosts the business unit person’s “comfort level” and confidence in an unfamiliar technology, thereby increasing the receiver’s motivation and buy-in (see arrow in Figure 1) for technology transfer. New product development engineers, after all, in recent years have been on a faster and faster treadmill to reduce their cycle time, and so they are particularly wary of any unproven technology that will require them to slow down and iron out problems. In addition, we observed that business unit buy-in increased when personal connections with R&D people led a business unit manager or engineer to become more aware of, and more familiar with, technologies that R&D might transfer in the future. (2) Having the ability to find a common language (so communication can be effective) is easier when a prior relationship exists, and it is this common language that is particularly important when a complex or unfamiliar technology needs to be transferred. This point is the case because a common language – not to mention a cooperative approach – can help when there is a greater need for transferring a lot of expertise and know-how and for reducing friction and disconnects when coordinating the adaptation and multiple handoffs of a complicated technology transfer (see arrows in Figure 1). Senior managers in particular, it seems, have difficulty understanding or intelligently discussing technology when it is not presented to them in a language they can understand; i.e., in the language of business. Interestingly, our research finds that personal relationships play a more minor role in another R&D linchpin process – technology roadmapping (planning) – in part because, while some expertise transfer does take place when a technology roadmap is created, it is sparse compared to the massive amounts of expertise that must accompany the transfer of a complex or unfamiliar technology. One provocative implication of the “human face of learning” is that it calls into question the efficacy of recent efforts to develop corporate knowledge bases, where electronic repositories of knowledge and prior learning are codified and stored. For such efforts overlook the

12 importance of media richness, trust, and a common perspective that come from a face-to-face relationship and which are, we propose, critical components of intensive knowledge transfer. For example, in the epsilon project described above, having visiting R&D people co-located in the business unit appears to have been critical in building up a relationship from close contact at work and afterwards that ultimately led to a more successful technology transfer.

Expertise Transfer Besides relationships, another major purpose of communication in the technology transfer zone is to transfer expertise and know-how. However, different technology transfers have different degrees of expertise transfer. That is, in some cases, R&D transfers little knowledge over and above whatever is already embedded in the technology itself. Organizational learning theorists such as Nonaka (1994) have emphasized the distinction between explicit versus tacit knowledge. And tacit knowledge – knowledge that is difficult to understand, codify, or explain – can be particularly difficult to transfer (Argote, 1993), yet it is precisely this type of knowledge which adds value and which plays such an important role in accompanying a technology transfer. Based on this study’s fieldwork on the technology transfer process, we further note that expertise transfer – i.e., the learning and transfer of know-how – occurs in one of two major areas: technical and organizational. Technical know-how (from R&D) refers to knowledge on how to use the technology, what it is capable of, when and how to apply it, nitty-gritty technical information, general skills, and training. The flow of knowledge between R&D and the business unit, however, goes both ways, and so the business unit needs to transfer technical know-how to R&D on user needs, adaptation requirements, and obstacles. The second type of expertise, knowledge on organizational issues (e.g., “cultural” or “political” knowledge), refers, for example, to expertise on another group’s work style, expectations of how people will interact, as well as on other individuals’ work habits and abilities. When is all of this expertise transfer needed? A technology transfer, we propose, will require a lot of expertise transfer when:

13 • The technology itself is hard to modify or use; i.e., the knowledge needed is not already embedded in an obvious or self-contained way in the technology, or

• The technology must be integrated with other technologies into a product, or

• Later modification of the technology will be needed (e.g., for manufacturability, changing needs) but is hard to do, or

• The business unit has an unclear understanding of the proper application of the technology, or

• R&D does not care or know enough about the receiver’s needs to do the technology modification itself. A common theme in all of these scenarios is that more expertise needs to be transferred when a lot of knowledge about the technology needs to be integrated with the business unit receiver’s own knowledge. Given what it is and when it is needed, how does expertise transfer take place? It is often said that technology transfer happens best when it is accompanied by personnel transfer. The various mechanisms used for transferring expertise that we observed in the field sites were all attempts to achieve this ideal. For example, one company used temporary personnel transfers (in both directions), although this was reputed to work only for single men who were willing to relocate. Another option is to hire technology developers from R&D permanently into the business unit, although there are serious career implications here for people interested in doing R&D. Yet another alternative mechanism for expertise transfer is the use of advanced communication technologies, such as e-mail, video conferencing, and internet conferencing. For the technology transfer process, though, we found that these cannot replace face-to-face interaction, either among managers or engineers. In terms of tacit knowledge, some technical know-how transfer requires physical interaction – one engineer noted that he often needs to lean over his counterpart’s shoulder to point to things. In addition, some organizational know-how, such as an understanding of the other group’s work environment or work habits, requires being in person. In general, when co-location was not an option, most companies tried a combination of approaches, including in-person visits, e-mail, ftp (internet) sites, and telephone calls.

14 Often overlooked, however, when expertise or knowledge transfer is discussed is that such transfers can be quite costly. Practitioners (as well as academic theorists) talk about how organizations need more communication and that organizations should increase what everyone knows about what knowledge is “out there” in the organization. The imagery is that all organizations have to do is tap that knowledge, as if it were as free as tapping a tree for syrup. It is not free, though; you have to buy it. Interestingly, this “knowledge transfer is free” mindset diminishes considerably when it is framed less glowingly: few would say, for example, that people in organizations need to spend more time in internal meetings and on phone calls, even though these are common knowledge transfer mechanisms. Nevertheless, it is not clear to us that a system of internal transfer prices for knowledge is the answer. For any such accounting mechanism in the R&D arena is likely to have internal transfer prices that are wrong and lead to not using R&D when it might make economic sense to do so – if only because the transfer price numbers are more salient and immediate than what goes on within the business unit. That is in fact precisely what happened at one of the field-site companies, which discouraged business units from using central R&D by assigning R&D much higher “billing rates” than those of engineering groups within the business units. Thus, while there is a cost of transferring expertise, there is also a cost of not doing so.

Coordination

The third major reason for interaction within the technology transfer zone is to coordinate the series of handoffs and adaptations. This type of communication is similar to the need “to coordinate the many complex tasks and subsystem interrelations that exist on an R&D project” (Allen, 1986: 212), but here we focus on such coordination across the R&D/business unit boundary. Simon (1997) defines coordination as occurring when organizational members follow the same decision, or make decisions consistent with the same goal. For technology transfer this “working towards the same goal” requires that, at a detailed project level, the business unit knows what to expect from R&D (“what’s coming”) and that R&D knows what is needed by the

15 business unit (“what’s needed”). One business unit manager, for example, approached the problem of matching “what’s needed” with “what’s coming” by creating – even before the start of a technology development project – a short document spelling out each side’s expectations, deliverables, responsible individuals, schedule, etc. Even earlier in the process, technology workshops at some companies served this same purpose. Nevertheless, contrary to the conventional view that one can and should specify all business unit needs and R&D offerings in advance of the R&D project (or at least of technology transfer), in the technology transfer process we have found that it is often necessary (if not also faster overall) to be iterative and thereby learn from experience in adapting the technology. That is, just as with product development (Eisenhardt & Tabrizi, 1995), some adaptation (or “rework”) of a technology is probably necessary and desirable. Just how much, though, likely depends on the technological context. Much of the needed back-and-forth, iterative, ongoing communication (e.g., weekly updates from R&D, monthly meetings) that takes place in the technology transfer process between sender and receiver is to achieve this purpose of matching “what’s needed” with “what’s coming.” In fact, even before a technology development project begins, engineers and managers need to be exchanging specific information about what business units need and what R&D has to offer.

Ability to Adopt

Ultimately, expertise transfer and coordination are useful to the technology transfer process because they lead to a greater organizational ability to adopt a new technology and incorporate it into a new product or manufacturing process (see Figure 1). This ability, which takes the form of both technical and organizational skills, allows the business unit to adapt and modify successfully the technology to its own unique needs. That is, the business unit needs the ability to re-invent the transferred technology for its particular purpose (Leonard-Barton & Sinha, 1993). For example, in one company, a given technology that did not transfer had multiple uses across a range of products, each with different performance or integration

16 requirements. For the business units to have customized this technology, however, would have required detailed knowledge of both the technical design and how to manipulate it; yet they possessed neither. In the end no business unit understood the technology well enough to know what would be an appropriate use for it, and so the organization lacked the ability to adopt it. From the theoretical perspective of organizational learning, the ability to learn has been the primary focus (Levitt & March, 1988; Nonaka, 1994; Walsh & Ungson, 1991), much more so than the question of whether or not people even want to learn (or transfer knowledge) in the first place. For that, we turn to the issue of buy-in.

Buy-in For the technology transfer process, we have observed, buy-in is important not just for the business unit but for R&D as well. That is, contrary to the conventional view, which sees R&D as a supplier of knowledge that can be ignored or used solely at the discretion (or whim) of the business unit, R&D in fact has its own set of expectations about this relationship that must be met for R&D to buy into the transfer. For example, suspicion, fear, or power will make R&D reluctant to develop and transfer a technology:

• If R&D suspects that the receiver lacks credibility in its ability to convert technology into production, or if past technologies were transferred and then dropped by the receiver, R&D may be reluctant (i.e., less motivated) to send again. This reaction results when R&D feels demoralized; it is even worse if R&D feels that it invested extra time and energy to adapt and transfer a technology.

• We saw one R&D group fear that it would be giving away its job security if it transferred its technological expertise and, thereby, its usefulness to the organization. As a result, this R&D group, which had witnessed a long pattern of corporate layoffs, did not transfer the technology for a long time.

• If R&D has more power, such as the ability to work on alternative projects or with alternative business units, then its buy-in becomes more of a factor in the technology transfer process. In terms of implications, we observed that sophisticated receivers are sensitive to maintaining the R&D sender’s motivation for future projects. For example, in one transfer situation, the original R&D project, for external reasons, became less valuable to the business unit receivers, so they

17 decided to use some of that work for a new and less critical project to keep the technically- impressive R&D people involved and motivated. Just as essential to the success of a technology transfer is the motivation and buy-in of the business unit receivers. Moreover, this buy-in is not an event; it needs to be sustained throughout the R&D project’s life. Note, too, that buy-in makes technology transfer easier whether the technology’s origin is one of “technology push” or “market pull.” One would, however, expect business unit buy-in to be greater for market pull technologies because those technologies are already desired by the business unit’s served markets. This “technology craving” is thus a force that generates business unit buy-in. In contrast, technology push projects often imply that R&D knows better than the business unit or marketplace, so buy-in is more difficult to generate in the receiver. This effect is even more extreme for “castor oil” projects, where the business unit people are encouraged to “swallow” a technology that is supposedly good for them. The whole purpose of buy-in is to make technology transfer easier. However, organizations sometimes do not want radical innovation to be easy to transfer, because most radical innovations do not succeed in the marketplace. So technology transfer is a kind of filter – although not necessarily a good or appropriate one – for radical innovation. But how does buy-in arise? Rationally, business units “buy into” a technology transfer when they see that it makes sense strategically and will make a valuable addition to a product or manufacturing process. Yet, as we describe below in the section on technology strategy, business unit people often have a healthy anti-technology bias. To counter this bias, clever R&D people at the five companies we examined devised numerous ways to increase business unit buy- in for technology transfer. Some of these approaches, such as early business unit involvement, take advantage of psychological mechanisms in the business unit like pride and personal satisfaction, having one’s own neck on the line (fear), and escalation of commitment (Bazerman, 1994). Others are designed to break through the “awareness barrier” of senior managers in the business unit; i.e., to capture the limited managerial attention (Ocasio, 1997; Simon, 1997) of people who do not just discount the value of new technologies, but who can completely ignore

18 and not even be aware of what knowledge or new technology could be transferred. Still other approaches help boost the “comfort level” of the business unit receivers, a mechanism discussed above in the section on personal relationships. Putting aside for the moment the wisdom of increasing receiver buy-in (see section below on technology strategy), we now outline many of the approaches used in the five companies to increase it:

• An R&D sender with experience as a technology receiver – e.g., via job rotation or transfer – can more easily overcome resistance to transferring new technologies because the sender better understands the business unit’s generic and specific needs and concerns related to commercialization.

• Getting informal, “sly” involvement by business unit engineers (and their test facilities) in an R&D project helps generate buy-in and commitment without creating any red flags, or opportunities to reject the project, that a more formal request for involvement or funding might generate.

• Rather than getting buy-in up front, R&D provides after-the-fact “boot camps” to sell and market the technology to business unit receivers. Note that this approach’s expertise transfer (e.g., explaining how the new technology works) also builds the business unit’s ability to adapt the technology.

• Ongoing communication, such as weekly updates, from R&D not only improves coordination (as discussed above), it also serves as a reminder from R&D that “we’re alive,” thereby helping to keep the technology on the receiver’s “radar screen.” This point is related to our concept of the awareness barrier.

• Business unit funding of an R&D project leads to greater motivation in part because of an escalation of commitment; cognitive dissonance – “I funded it, therefore I must want it.”; and the funding decision causing the receiver to seriously think over the matter beforehand.

• Generating end-use customer interest in a technology (an “end-around move”) can certainly get the attention of the business unit’s product developers. However, demonstrating a technology’s viability in this way can be dangerous if it forces unprofitable or strategically unwise decisions onto the organization.

• Increasing the business unit’s confidence in R&D’s ability (and willingness) to complete successfully the technology development task also builds buy-in; e.g., when R&D clearly communicates why a slip-up occurred.

• R&D managers – as a result of hiring, promotion, and training – need to be skilled at and motivated to communicate heavily with the business units. This role, however,

19 may be quite different from why they went into science in the first place (Chen & Rao, 1997) and why they were hired into the organization.

• Finally, there is a right time and a right level, we propose in Table 1, to get business unit involvement in a technology project and transfer. ------Insert Table 1 about here ------

Outcomes According to the framework proposed in Figure 1, all things being equal, greater ability to adopt and greater buy-in will lead to better technology transfer outcomes. Indeed this part of the framework parallels a generic theoretical framework for understanding any organizational action by focusing on both the desire and ability of the organization or its members to perform that action (Levin & Shortell, 1996; Zajac & Kraatz, 1993; Zajac & Shortell, 1989). Of course buy-in by the business unit is a good thing only if the business unit is correct in knowing what will work in the marketplace. The main aspects of performance (i.e., relevant outcomes) for technology transfer are: transfer or no transfer, the cost (and opportunity cost) of the technology transfer, as well as its speed, ease, and strategic importance. An important concern to practitioners on this topic is how to measure technology transfer (and the R&D domain more generally). However, the issue of how to measure appropriately and usefully R&D is a difficult and long-standing problem (National Center for Manufacturing Sciences, 1996); e.g., the impact of R&D work is felt years later and many contributions are difficult to trace. Nevertheless, this research study does provide a few theoretical insights into the technology transfer measurement problem. We can divide the useful metrics into two types: outcome and process measures. The first type – examples of which are listed above – can be measured at the project level or for a whole portfolio of R&D projects. The second type of metric focuses on the technology transfer process as described in this paper. That is, this paper proposes that, to get the leading indicators of technology transfer success, one should measure

20 the three elements of technology transfer zone communication: relationships, expertise transfer, and coordination. The logic for suggesting these three categories is that they are based on a theory of how the technology transfer process works; they are therefore preferable to, say, counting the number of technology transfers that occurred (as one company in this study’s sample recently began doing). In addition, we do note, however, that corporate measurement systems based on these elements are subject to the same potentially dysfunctional consequences that all such systems face.

LEARNING AND CONTEXTUAL FACTORS Now that we have laid out the basic conceptual framework emerging from the research on the technology transfer process, we turn to some of the major contextual factors and learning/feedback loops that affect the basic framework. ------Insert Figure 2 about here ------

Two Feedback Loops Both feedback loops described below deal with where the boundary between R&D and the business unit is drawn for a particular project (for overall clarity of presentation, the feedback loops are not shown in Figure 2). In the first feedback loop, if the business unit lacks a sufficient ability to adopt a technology, then the organization may shift the boundaries of the technology transfer zone. We call this effect, where R&D must step in to do some of the commercialization, coping with a learning disability. The best example of this phenomenon occurred in one company where a new business unit was created to commercialize a technology from R&D. This new business unit, however, did not yet have enough ability to use the technology, or to learn how to do so from R&D fast enough. As a result, the technology transfer handoffs from R&D to the business unit occurred closer to product commercialization than is the norm at that company. Speed is increasingly a factor driving this coping mechanism.

21 Another feedback loop that affects the boundaries of the technology transfer zone occurs when R&D does more commercialization work to persuade the business unit of the technology’s viability. This effect, which we call boundary shifting to make more convincing, is an attempt by R&D to get around the problem of low business unit buy-in. In one case this shift in boundaries occurred when an R&D manager actually went out and borrowed an industrial customer’s equipment for a several months so the R&D manager could install a new technology into it and demonstrate to his own company’s product developers that the technology would be useful and should be transferred to them.

Negative Learning Loop In addition to the existence of these two feedback loops, some of the organizations studied believe they are improving the technology transfer process. In fact, though, they have created a learning loop that results in more and more risk aversion, and even the inability to manage risk at all. The vicious cycle begins when negative outcomes are combined with an unrealistic expectation that, as with all “good business processes,” technology transfer will always work and work well. An unrealistic expectation in this context means an attempt to remove more market and technical uncertainty, and earlier, than is possible. Note that, unlike many contexts, technology management and R&D are inherently probabilistic (Roussel et al., 1991), so an expectation of 100% success in technology transfer is especially absurd.

The negative learning loop is created if, as a result of these unrealistic expectations, negative consequences (e.g., harsh criticisms, lack of promotion, budget cuts) befall those involved in a less-successful transfer. The result of this negative learning loop, we propose, is a future avoidance of anything risky and a growing inability to make decisions under circumstances of limited information (i.e., managing risk). For example, R&D projects become too incremental and low-reward (they would rather not work on a high-risk project again if they are just going to get “hammered.”), opening up the company to blind-siding; R&D comes to rely on externally-guaranteed project funding (e.g., government); business units only agree to fund

22 technology projects when there are guaranteed customer commitments to buy the resulting product; business units start to only want low-risk, off-the-shelf technologies; business units overlook intellectual property and dependence issues and begin preferring outside technology suppliers, who are supposedly presenting them with less risk. In fact, part of what makes negative learning loop so damaging is that many in the company come to see this avoidance of risk as a strength, rather than a hindrance. So, as a result of the organizational culture (“rules of the game”) and context, here is an example of learning where learning is not the usual “good news” story one might expect. In fact, this negative learning loop is related to the “failure myopia” identified by Levinthal and March (1993), although in this case the problem goes beyond simply oversampling success and undersampling failure, resulting in overconfidence – rather, in these organizations, the existence of failure creates a loop of increasing risk aversion, leading to poorer learning. Now let us turn to contextual factors that influence the technology transfer process.

Technology Life Cycle The life cycle of a technology, like that of products or industries, has long been described as a taking the form of an S-curve: early developments start slow, then big jumps in the technology’s performance occur, and then it starts tapering off (Roussel et al., 1991; Radnor, 1986). What we now propose is that the technology transfer process, and buy-in in particular, will be affected in a curvilinear way by the stage in the technology life-cycle (or S-curve). That is, late in a technology’s life cycle – the maturity stage, when advances takes longer – technology transfer becomes more difficult because the business unit receiver increasingly values operational efficiency more than technological change; i.e., the business unit organization is increasingly professionalized and trying to drive out things that cause variation (Simon, 1997). Moreover, any remaining technology improvements will have lower yields (i.e., less reward for risk involved). In the middle stages of the life cycle – the growth stage – technology transfer will be easier (although, as one practitioner noted, it is never “easy”) because technological

23 improvements are more likely to have strategic or competitive value to the organization. As one R&D manager confirmed, “Tech[nology] transfer is always more successful when there is a ‘pull’ from the receiving organization, and that is most likely to happen in the middle phase when there is a perception of urgency on the part of the receiving organization.” In the early stages of the technology life cycle – when the technology is still emerging – technology transfer may be more difficult than in the middle stages because (1) the organization may be reluctant to back an unproven technology that could threaten existing products, (2) commercializing a brand new technology imposes overwhelming time constraints on product developers early on, and (3) these product developers may lack experience in adapting the brand new technology. An important implication of the above discussion is that if technology transfer is especially difficult, R&D people may assume that the process is at fault and recommend changes to their relationship with the receiving organization. In fact, though, it may be that increasing difficulty is a sign of the technology’s maturity, and is a natural and appropriate consequence – new technologies add less value at that point. The proper response might be to shift the R&D portfolio towards breakthrough technologies which can begin a new S-curve. This response is of course easier said than done, because many business units (and their customers), especially those already focused on stability and operational efficiency, resist long-term or radical technologies. A senior corporate commitment is thus key to implementing such a response. Alternatively, some R&D groups use the various practices described above in the section on buy-in, such as informal business unit involvement, to get technology transfer to work even in this mature stage of the S-curve. Note that, although, a shift from product technologies to process technologies is typical during the course of the life cycle (Radnor, 1986), this shift does not significantly diminish the resistance of business units to new technologies of all kinds, despite the fact that cost reduction may result from them. Interestingly, process technologies are frequently viewed as cost reduction opportunities, but they, too, are typically resisted due to the focus on stability.

24 Technology Strategy “The distinction between technological leadership and followership is a central one in the literature on the management of technology” (Porter, 1983: 12). That is, even in technologically- intensive industries, some companies (or business units or product groups) find profit as a technology follower by inexpensively copying and adapting the cutting-edge innovations of others. This technology strategy, as with all strategies, entails some risks; e.g., a technology follower is more prone to blind-siding and more vulnerable to getting “locked out” by another company’s patents (Radnor, 1986). The main focus here, however, is not on the determinants of the leadership/followership choice (Porter, 1983), but on what we propose are the implications of that choice for the technology transfer process. Put simply, technology followers are more reluctant receivers of technology from central R&D. This lack of buy-in, in turn, makes the technology transfer process more fragile, and the mechanisms for enhancing buy-in more important to central R&D. For the organization as a whole, however, increasing business unit buy-in for technology transfer may not always be desirable. For example, one company’s major industrial customer refuses to buy anything with new, untested technology in it, for fear that such equipment would be too disruptive to their own operations. Such pragmatic, conservative customers appreciate stability, standards, and service over state-of-the-art technology. For them, using only proven technologies is a requirement, and if the technology is hidden altogether, that is even better. Thus, when technology is not of primary strategic importance, the business unit receiver will not want much technology from R&D. Such receivers often have their product developers buy and adapt existing technology themselves. So not only is technology transfer harder to do on the more horizontal parts (i.e., the early and late stages) of the technology life cycle’s S-curve, but it is also harder when the organization is not attempting to be on the state-of-the-art S-curve and is satisfied to remain on a lagged S-curve. As a result, we observed in at least two companies, R&D’s focus turns to technologies specifically asked for by business unit receivers, who mostly make their requests reactively based on the marketplace. Since radical innovation is not yet in the marketplace, or at

25 least not in the markets served by the technology follower, R&D “learns” that technology transfer is much easier to do when it is mainly used for incremental innovation wanted by the business unit. An exception to the above discussion may exist for the technology “fast follower” (e.g., AMD in its competition with leader, Intel), where the business unit is eagerly awaiting – and has prepared – to adopt the next technology (or standard) that has found acceptance in the marketplace. In such cases, buy-in would be greater, and technology transfer, easier and more likely. Some of the business units in our study claim to be fast followers, but their actions suggest that they are simply technology followers. Their claim may be more for legitimacy purposes, since being a fast follower is more professionally respectable; these business units seemed to lack the kind of “technology craving” one would expect from a true fast follower.

CONCLUSIONS This study’s empirically grounded insights paint a picture of organizational learning and knowledge transfer as something much different than a straightforward – even sterile – process of exchange. For example, this research finds that learning, especially for the routine of technology transfer, is embedded in a set of relationships. This “human face of learning” – a notion similar to embeddedness (Granovetter, 1985; Uzzi, 1997), although existing within the hierarchical organization – stands out as critical in this knowledge-intensive domain, especially when the need for expertise transfer is high. Interestingly, this finding is consistent with that of Szulanski’s (1996) in a different domain: the transfer of best practices. Another way in which organizational learning and knowledge transfer are more than just a straightforward process of building organizational skills and competencies is in the role played by R&D’s and by the business unit’s buy-in and motivation. For not only is buy-in a subtle yet prominent issue in the basic framework of how the technology transfer process operates, it is also strongly affected by contextual factors like the technology life cycle and technology strategy, as well as power issues between central R&D and business units. With some exceptions the issue

26 of organizational motivation is under-appreciated in the organizational learning literature. Thus, the conceptual frameworks proposed here are an attempt to incorporate this factor, along with the other key underlying factors, into a coherent theoretical model. Moreover, from a theoretical perspective, this research study adds to our growing understanding of how organizations learn. More specifically, given that routines form the basis for organizational learning (Levitt & March, 1988), we have taken one critical routine – the technology transfer process – in a critical, knowledge-intensive arena (Roussel et al., 1991) and fleshed out how it actually works. This research program, along with others (e.g., Pentland & Rueter, 1994), thus tackles the challenge put forth by Grant (1996: 384) for more “detailed study of the operation of organizational routines.” Furthermore, this research does so systematically, by first detailing the overall network of routines in the technology management domain and then focusing in on the most knowledge-intensive ones. Thus, a major benefit to examining a routine, or process, in detail is that we been able to get inside the “black box” of organizational learning in ways that quantitative, learning curve-based studies (e.g., Argote, 1993; Levin, 1997) alone cannot. The basic description and function of the technology transfer process is an example of first-order learning (Collis, 1994); i.e., the organization has “learned” when it adapts a new technology for use in new and improved products (or manufacturing processes). The inner workings and implementation of the technology transfer process (depicted in Figure 1) are all aspects of this learning. We have also raised the possibility and identified examples of second- order learning, when the organization “learns how to learn” (Collis, 1994); i.e., when the organization adapts this (technology transfer) routine over time. Interestingly, this second-order learning is not always a good thing, as evidenced by the negative learning loop described above. An important benefit of including examples of second-order learning in the expanded framework of technology transfer (see Figure 2) is that it captures the dynamic quality of this routine. In particular, technology transfer is a dynamic process that occurs over time, and where the boundaries within the technology transfer zone can be changed by the actors involved.

27 In terms of managerial implications, practitioners (and even scholars) often focus on a technology transfer handoff, as reflected, for example, in their expectations, the way they measure the process, and their attempts at improvement. In contrast, we have introduced in this paper the notion of a (dynamic) technology transfer zone in which complex, multiple, and iterative handoffs between R&D and business units take place. It is not that practitioners are totally unaware of the conceptual elements (see Figure 2) involved in the technology transfer process. They have in fact devised some clever and successful ways to improve some of these elements; e.g., the numerous techniques used for generating business unit buy-in. What the practitioners have not done, however, is systematically address why problems like a lack of buy- in occur. Consequently, they do not address root causes. The contribution of our framework for practitioners is thus that it can help address the underlying causes of technology transfer and what makes that process “tick.” In sum, this research accomplishes two things. First, it uncovers major theoretical elements – apart from the transfer of the technical artifact itself – in the workings of the technology transfer process. These elements, which necessarily accompany the transfer of the technology, can be seen as falling into several major clusters:

• Aspects of the “technology transfer zone” (relationships, expertise transfer, and coordination)

• The desire (buy-in) and ability of the parties to carry out the transfer

• Performance outcomes

• Learning and contextual elements Second, this research shows how these theoretical elements can be informed by an overall conceptual framework, as shown in Figures 1 and 2. This framework allows scholars to better understand how this process, and routines more generally, function in organizations, and it allows practitioners to focus on those key underlying factors which determine how successful this process is in action.

28 The frameworks proposed here help add to our understanding of organizational learning by rounding out our view of this important strategic phenomenon as more than just a sterile, anonymous process of building skills and competencies. This research also systematically identifies a useful and interesting set of variables and concepts for the technology transfer routine. Moreover, we have tried not to study a single routine in isolation, but to place that routine in an overall network of inter-related organizational routines and in an organizational and strategic context as well. We believe this framework will be useful for scholars who wish to further explore and test in other and broader domains the relationships it proposes. As this research program continues, the focus will be on continuing to refine and apply the framework, both for technology transfer itself and for the other R&D linchpin processes as well.

29 REFERENCES

Allen, T. J. 1977. Managing the flow of technology. Cambridge, MA: The MIT Press.

Allen, T. J. 1986. Organizational structure, information technology, and R&D productivity. IEEE Transactions on Engineering Management, 33: 212-217.

Argote, L. 1993. Group and organizational learning curves: Individual, system and environmental components. British Journal of Social Psychology, 32: 31-51.

Bazerman, M. H. 1994. Judgment in managerial decision making (3rd ed.). New York: Wiley and Sons.

Blau, P. 1963. The dynamics of bureaucracy. Chicago: University of Chicago Press.

Blau, P., & Meyer, M. 1971. Bureaucracy in modern society. New York: Random House.

Burt, R. S. 1992. Structural holes: The social structure of competition. Cambridge, MA: Harvard University Press.

Chen, C. C., & Rao, A. 1997. On being foreign: The career dilemma of Asian-born scientists in a changed R&D environment. Paper presented at the annual meeting of the Academy of Management, Boston.

Cohen, W. M., & Levinthal, D. A. 1990. Absorptive capacity: A new perspective on learning and innovation. Administrative Science Quarterly, 35: 128-152.

Collis, D. J. 1994. How valuable are organizational capabilities? Strategic Management Journal, 15(S2): 143-152.

Eisenhardt, K. M. 1989. Building theories from case study research. Academy of Management Review, 14: 532-550.

Eisenhardt, K. M., & Tabrizi, B. N. 1995. Accelerating adaptive processes: Product innovation in the global computer industry. Administrative Science Quarterly, 40: 84-110.

Galunic, C. 1997. An interview with Henry Mintzberg. OMT Newsletter, Winter 1997. Briarcliff Manor, NY: Academy of Management’s Organization and Management Theory Division.

Glaser, B. G., & Strauss, A. L. 1967. The discovery of grounded theory: Strategies for qualitative research. New York: Aldine Publishing.

Granovetter, M. 1985. Economic action and social structure: The problem of embeddedness. American Journal of Sociology, 91: 481-510.

Hambrick, D. C. 1994. 1993 Presidential address: What if the Academy actually mattered? Academy of Management Review, 19: 11-16.

30 Huber, G. P. 1991. Organizational learning: The contributing processes and the literatures. Organizational Science, 2: 88-115.

Hounshell, D. A. 1996. The evolution of industrial research in the United States. In R. S. Rosenbloom and W. J. Spencer (Eds.), Engines of innovation: U.S. industrial research at the end of an era. Boston: Harvard Business School Press.

Lawrence, P. R., & Lorsch, J. W. 1967. Organization and environment: Managing differentiation and integration. Boston: Graduate School of Business Administration, Harvard University.

Leonard-Barton, D. 1990. The intraorganizational environment: Point-to-point versus diffusion. In F. Williams & D. V. Gibson (Eds.), Technology transfer: A communication perspective: 43-62. Newbury Park, CA: Sage.

Leonard-Barton, D., & Sinha, D. K. 1993. Developer-user interaction and user satisfaction in internal technology transfer. Academy of Management Journal, 36: 1125-1139.

Lester, R. K., & McCabe, M. J. 1993. The effect of industrial structure on learning by doing in nuclear power plant operation. Rand Journal of Economics, 24: 418-438.

Levin, D. Z. 1997. Organizational learning and the transfer of knowledge: An investigation of quality improvement. Best Papers Proceedings of the Academy of Management.

Levin, D. Z., Radnor, M., & Thouati, M. G. 1997. Using a process view of organizations to understand the management of technology. Paper presented at the annual meeting of the Academy of Management, Boston.

Levin, D. Z., & Shortell, S. M. 1996. Desire to implement and ability to implement: The case of total quality management. Paper presented at the annual meeting of the Academy of Management, Cincinnati.

Levinthal, D. A., & March, J. G. 1993. The myopia of learning. Strategic Management Journal, 14: 95-112.

Levitt, B., & March, J. G. 1988. Organizational learning. Annual Review of Sociology, 14: 319-340.

Miner, A. S., & Mezias, S. J. 1996. Ugly duckling no more: Pasts and futures of organizational learning research. Organizational Science, 7: 88-99

Mowday, R. T. 1997. 1996 Presidential address: Reaffirming our scholarly values. Academy of Management Review, 22: 335-345.

National Center for Manufacturing Sciences. 1996. Management of technology: Feasibility study. Ann Arbor, MI.

Nonaka, I. 1994. A Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5: 14-37.

31 Ocasio, W. 1997. Towards an attention-based view of the firm. Strategic Management Journal, 18(S): 187-206

Pentland, B. T., & Rueter, H. H. 1994. Organizational routines as grammars of action. Administrative Science Quarterly, 39: 484-510.

Porter, M. E. 1983. The technological dimension of competitive strategy. Research on Technological Innovation, Management and Policy, 1: 1-33.

Raber, L. 1997. House endorses patent law changes. Chemical & Engineering News, 75(17): 11- 12.

Radnor, M. 1986. Technology strategy: Internal and external perspectives. International Journal of Technology Management, 1: 502-507.

Roussel, P. A., Saad, K. N., & Erickson, T. J. 1991. Third generation R&D: Managing the link to corporate strategy. Boston: Harvard Business School Press.

Rubenstein, A. H. 1966. Some common concepts and tentative findings from a ten-project program of research on R&D management. In M. C. Yovits, D. M. Gilford, R. H. Wilcox, E. Staveley, & H. D. Lerner (Eds.), Research program effectiveness: 399-424. New York: Gordon and Breach.

Rubenstein, A. H. 1989. Managing technology in the decentralized firm. New York: Wiley.

Simon, H. A. 1997. Administrative behavior: A study of decision-making processes in administrative organizations (4th ed.). New York: Free Press.

Szulanski, G. 1996. Exploring internal stickiness: Impediments to the transfer of best practice within the firm. Strategic Management Journal, 17(S): 27-43.

Thompson, J. D. 1967. Organizations in action. New York: McGraw-Hill.

Tushman, M. L. & Scanlan, T. J. 1981. Boundary spanning individuals: Their role in information transfer and their antecedents. Academy of Management Journal, 24: 289- 305.

Uzzi, B. 1997. Social structure and competition in interfirm networks: The paradox of embeddedness. Administrative Science Quarterly, 42: 35-67.

Walsh, J. P., & Ungson, G. R. 1991. Organizational memory. Academy of Management Review, 16: 57-91.

Zajac, E. J., & Kraatz, M. S. 1993. A diametric forces model of strategic change: Assessing the antecedents and consequences of restructuring in the higher education industry. Strategic Management Journal, 14(S): 83-102.

Zajac, E. J., & Shortell, S. M. 1989. Changing generic strategies: Likelihood, direction, and performance implications. Strategic Management Journal, 10: 413-430.

32 TABLE 1

Level and Time of Business Unit Involvement for Technology Transfer

Phase of R&D Project

Early Middle Late Senior level Bad. Too much Good. Find the Bad. Caught by surprise commitment required too appropriate time and unprepared. early = project might be when value can be killed. demonstrated. Technical Depends. Business unit Good. Depends. Can result in re- level technical people are busy. work, delays, and rejection. Limit this to projects where Appropriate for “shelf” significant adaptation is (i.e., stand-alone) required. technologies, though.

33 FIGURE 1

Basic Conceptual Framework of Technology Transfer Process

Use Word 6.0c or later to

view Macintosh picture.

34 FIGURE 2

Expanded Conceptual Framework of Technology Transfer Process

Use Word 6.0c or later to

view Macintosh picture.