This paper was written after John Tang and I organized a panel at CHI '96 on technology transfer. ACM published it in 1996 in Communications of the ACM, Vol. 39, Number 9, 22-25. A PDF version of this paper is available.

In 1994, our advanced development group, SunSoft's Collaborative Computing (COCO) group, was finishing its second set of proof-of-concept prototypes. Two years earlier, our first prototype, a desktop video conferencing and shared whiteboard system, had been transferred to a product group without much difficulty and was now selling as SunSoft's ShowMe(TM) product. We were looking forward to a similar technology transfer process. One of our new prototypes, Montage, was a "next generation" desktop video conferencing system. It focused on the problem of helping people find and negotiate a good time to interact, as this had emerged as a problem in our first prototype. Our other new prototype, Forum, enabled speakers to give live, video-based interactive presentations over the network.

Over the next two years, we were to discover that our first experience had been unusual. Although Montage and Forum were well received within the company, we could not find a group that would productize them. The ShowMe group was rightly concerned that the video conferencing market wasn't mature enough to understand the need for Montage's awareness features. And, although Forum was being used regularly within the company and was enthusiastically received, there was no one obvious group to productize it. As various organizations changed, there were times when no group was interested, and others when too many groups were interested and we got caught in battle of charters.

As we struggled with the problem, we realized that other researchers in large corporations probably have experienced similar difficulties. Perhaps other people had learned a better way to structure their organizations to make technology transfer more central to their development. Perhaps they had developed better processes for moving advanced prototypes into the product pipeline.

We were particularly interested in people's experience with transfer of software that had a strong user interface component. Our work tends to focus on the design and graceful integration of existing technology, rather than exploring entirely new technologies. Development groups, however, tend to respond to exciting features that can stand out in the marketplace. In addition, market and budget pressures tend to make development groups averse to the risk of taking over a new technology they have not developed themselves from the start. It was unclear whether the subtlety of a good user interface would be enough to sell a prototype to a product group.

ACM's 1995 conference on Computer-Human Interaction (CHI) was coming up, so we took advantage of the gathering by inviting a group of 15 people in corporate research or advanced development to an ad hoc dinner discussion. Participants had gathered their experience from such companies as Apple, Hewlett-Packard, IBM, Intel, Lotus Development Corp., Microsoft, NTT, Sun Microsystems, US West, Xerox PARC, and others. In that meeting, people described their experiences and told us what they felt worked and did not work when trying to transfer technology. We compiled this list of success factors over the course of the discussion:

Management and Organizational Infrastructure

• An organizational model that encourages coordination between research activities and product projects
• Executive-level commitment to the transfer of ideas from research groups to development groups
• Geographic and social proximity between research and development groups

  Technology Push
  

• Research projects that are aligned with corporate strategy
• Research projects containing people who are highly motivated to see
• the fruits of their research transferred into products
• A high-level visionary who champions bringing the idea to market
• Readily demonstrable improvements over existing or related products

  Demand Pull
  

• A product group motivated and poised to take the technology
• A significant customer with a strong need for the technology
• An involved marketing group that tracks customers' needs and markets the ideas throughout the company

1. A mutually shared and developed vision of what could be.
2. Trust established and maintained.
3. Distinctive and complementary competence.
4. Willingness to share needed knowledge.
5. Mutual benefit maintained over time.

With this analysis, the discussion shifted dramatically from organizational factors necessary for technology transfer to the process of cultivating the relationships needed to make those factors possible. We focused on the ways to develop and maintain effective relationships and which people should be involved. (A complete summary of that meeting is available.)

We in the COCO group realized that once we returned home, we should not focus on changing the organizational structure or putting in place new processes. Rather, the best thing we could do was to build bridges to other groups. We needed to have lunch with other groups, sponsor and attend talks, give demos, include others in our meetings, schmooze at social events, wander the halls of other buildings in the company to make unplanned interactions more likely. The goal was to stay in touch with as many people -- executives, engineers, managers, marketing people, sales people -- as possible, both to keep them aware of our work and to stay in touch with their concerns and directions. Of course, we had been doing some of this already, but we hadn't thought of it as a conscious activity designed to improve the technology transfer process. Now we do.

We decided to continue this discussion with a larger community, so we put together a panel at the 1996 CHI conference. We selected members of our dinner discussion who had articulated a particular point of view. Jean Scholtz, at Intel at the time and now a consultant, argues that those wishing to transfer technology should focus on developing prototypes because they are an effective and compelling way to communicate the value of the technology to the product groups, management, and other interested parties. She added that it is important to keep product groups involved in the prototype development process so they will be more willing to receive the technology when it is ready to become a product.

On the other hand, Jeff Johnson, who was in a product group at SunSoft at the time and had previously worked in research groups at Hewlett-Packard among other places, puts forth the view that researchers should focus on transferring information rather than technology. If a prototype is developed as a way to better understand an issue, that is a bonus. He argued that many product groups need answers to research questions but do not have the time or resources to explore them. The role of researchers is to provide this information. He claimed that defining technology transfer as information transfer also makes it more likely that a research group will be seen as successful, since there are many valid reasons why a research prototype may not become a product, even while the company is benefiting from the research.

Allan Kuchinsky, from HP Labs, argues that applied research groups should take a broader view of the business case for a new technology and build with product teams a shared understanding of not only the technology but the business and marketing issues around a new product. The research group should gain a deep understanding of the customers and their needs, as well as the business environment within which the new product would be deployed. This view requires the research group to work closely with the product team as it is developing the product, rather than transferring the technology and then moving on to the next project.

We decided to broaden the scope to include the process of transferring technology from academia to industry, so we invited Jim Foley to speak at the panel. Foley had been head of Georgia Tech's Graphics, Visualization, and User Interfaces lab and was moving to become head of Mitsubishi Electric Research Lab. Having had many years of experience handling technology transfer, Foley summed up his view with the comment "Technology transfer is a contact sport." He focused on the importance of relationships between researchers, engineers, and management to make sure all the parties have a genuine interest in the process and that they understand and respect everyone else's objectives. Relationships also help people accept that transferring technology takes a long time and happens in many forms.

These people articulated their views at the panel, after which John Bennett synthesized the arguments. As before, he stressed that groups involved in technology transfer must develop a shared vision of the possible results, develop mutual trust and respect, acknowledge each other's distinctive skills, share information, and attend to each other's objectives and interests in the project.

The audience broadened the discussion by reminding us of the importance of rewarding people for transferring technology (whether they are transferring information, prototypes, or otherwise). They also brought out the importance of involving customers in the process. And they challenged us to include the process of transferring technology from a large research lab to a small startup, something we had not addressed.

The following articles discuss these arguments in greater detail. Each panelist has fleshed out his or her point of view, and Bennett once again summarizes and synthesizes their views, this time taking into account the comments of audience members at the panel.

One final note: Several months ago, the COCO group did transfer Forum to a development group headed by a director we have known and maintained contact with for many years. Originally, when we were ready to transfer Forum, this director had been in different part of the organization, but when his charter changed to cover media-based technology, he sought out our technology. This has reinforced our notion that we must consciously maintain a wide-reaching network of relationships within the company, since we cannot predict who will be in a position to receive out technology when we are ready to transfer it.

We have since stayed in touch informally with the developers on the project. At one point several months ago, one member of our group had an informal conversation with one of the development engineers when they happened to encounter each other in the company's fitness center. We discovered that the developers were struggling with a technical roadblock and did not have the resources to explore an alternative approach. Based on that spontaneous conversation, some of our developers helped them explore the alternate approach, and that effort helped put the project back on track. Rather than thinking of this fitness center conversation as an incidental event, we now consider it the stuff of technology transfer.