I’ve been interviewing recently at a couple of Very Large Organizations (hence, VLOs) that have a strong research point of view. The names are elided largely because I’d like to discuss a general problem. These particular organizations aren’t the only ones that I’ve heard of that suffer from this; rather, it seems to happen across the board. On the other hand, I have more experience talking with the VLOs.
The problem that I’m thinking of is the technology transfer issue. An article in Scientific American this month, for example, worries that MSR may not be able to transfer ideas into products; famously; it was exactly this problem that hurt Xerox PARC.
The VLOs are certainly aware of these challenges, and are beginning to tilt their internal incentive systems to reward good, technology-transferred behavior. There are always internal and structural difficulties (research, development, and marketing are not always well-harmonized, at virtually any organization); more so, there is an odd issue that can happen in the use and harnessing of creativity.
The VLOs that I’ve spoken to have all expressed concern about the development groups. In particular, development (and I write here purely from the biased research perceptive) is hesitant to adopt untested technologies. They don’t want to build things that may not work; they don’t want to work with pieces that haven’t been compellingly demonstrated and tested.
Even when a full package is visible, with all the pieces in place, it can take time to bring a product to market. Several years ago, when I worked at IBM Research in Cambridge, the team was working on getting the REMAIL project into development. Their solution was to build a complete prototype, and thence to pass that full prototype into development teams. The teams, then, could take from that prototype, implementing them into a product.
One interesting aspect—what I want to focus on—is the increasingly-tangled web that patents and intellectual property draw. Researchers are fairly constrained in what they can put in: they cannot violate patents, nor (since they need to publish) may they particularly work on ground that others have covered in depth.
Unfortunately, under this model, they also need to build those prototypes, and time spent building a prototype of known work is time lost; time spent building a prototype based on someone else’s patent might be seen as constraining the system’s ultimate use (or inviting a lawsuit).
Which means that the prototypes are built with an odd internal gap: they reflect a lot of local knowledge, but very little from outside the organization, even in a field where many people are working on the problem. This is not necessarily a tremendously constraining problem, as academics and researchers can be expert at recasting their work in terms that make it seem unique.
None the less: when something doesn’t make the prototype, it doesn’t get seen by the development and production team. And the development team can’t build things that it doesn’t see1.
This is, of course, a variant of the “not built here” syndrome that many places suffer from, on all levels. People often don’t trust code they didn’t write, or systems they haven’t put together themselves. And so a great deal of time and effort is often spent, in many contexts, reinventing, if not the wheel, then at least the tire. (That way, you get to write “VLO” on the rim). I’m concerned about it in this case because—it seems to me—to constrain not only the amount of time spent developing, but also the deeper issues of what ultimately becomes part of the product.
How does one bridge this gap?
1 There is an entirely different issue in trying to figure out how close to full implementations prototypes should be: I’ve heard everything argued from nothing-but-flash all the way out to “build a full version, and let the developers repackage and publish it.”
June 9, 2004 08:05 AM | TrackBack | in Data and Documents