Greg Linden wrote on the CACM Blog about a model of research that strives to integrate researchers into product teams with the goal of helping work out thorny problems and building up social networks in the process. He also advocated that researchers should have time (something like 20%) that they can devote to non-product pursuits. This is certainly a workable model for research, but perhaps not the only viable one.
The premise that a researcher contributes more to the bottom line when working on near-term problems faced by a product team is based on the primacy of short-term ROI. We are paying salaries and overhead for all these guys; let’s make sure they contribute.
But it’s not clear to me that this model of research applies broadly. It may be true for some systems researchers and people focused on algorithms, but the marginal utility of a HCI researcher spending 80% of his or her time with a product team that’s deciding on the exact shade of blue to color its links is pretty low. I am not saying that no involvement is a good policy, but that there are many factors, including the field of expertise, that will determine the degree and manner of effective researcher engagement with product teams.
In addition, in practice it’s hard to enforce the 80-20 division because product cylces have time-sensitive demands, whereas research can typically wait another week. But effective research requires a certain critical mass of attention that a product release cycle may not readily accommodate.
Furthermore, there is a fundamental difference in the structure of research vs. product teams: whereas product-building strives to be focused, predictable, and consistent, research processes should be much more exploratory, diverse, and prone to failure. These characteristics of the process will affect the personalities of the people who are attracted to them: I’ve seen cases where contract developers hated working with researchers because there was no clear spec to which to build (and ideas shifted weekly); I’ve seen cases where researchers who were also skilled coders lead miserable existences in heavily-structured development teams; and of course there were people who’ve been successful in both kinds of endeavors. But one size doesn’t fit all: it doesn’t fit all people, and it doesn’t fit all organizations.
The perennial challenge for research organizations is relevance, which really means establishing metrics by which the senior management of a corporation judges their contributions. It is a mistake, in my opinion, to assume that the short-term ROI is the only defensible metric for assessing the utility of researchers to a technology firm. A research organization can also affect the longer-term technological trajectory of the parent corporation by creating a robust patent porfolio, by exploring opportunities tangential to the activities of product teams, by increasing the public reputation of the parent corporation, and, occasionally, by inventing something truly revolutionary. (Xerox, for example, may have fumbled away the graphical user interface invented at PARC, but it did make a bundle on laser printing.)
There are, of course, many challenges to technology transfer, and the most effective strategy often involves the (temporary) transfer of people, in the manner that Greg advocates. But we should recognize the merits of both short-term integration and longer-term segregation of these different work styles to achieve their different goals. Monoculture isn’t healthy in crops, and it’s not good for the long-term viability of corporations, either.
Hi, Gene. I think we agree on most of this. I absolutely agree that one size doesn’t fit all, that you wouldn’t want a researcher working on mundane problems (like the color of links), and that short-term ROI isn’t the only metric.
The problem I am trying to address is that research and industry often don’t get along. If we think researchers should be hired by industry — and I think they should be — then we need to make sure that it works for everyone. That means that the research team needs to justify its business impact to executives, researchers need to be happy and feel productive, and product teams need to feel like the researchers are great to have around.
When it doesn’t work, researchers either leave the company quickly or never get hired in the first place. Amazon.com, for example, is a company that has had problems in the past integrating and retaining researchers.
When it doesn’t work at companies that already have research labs, those research labs are constantly fighting for their existence, a battle they sometimes lose. HP Labs is an example here of a battle lost, but even the mighty Microsoft Research, one of the last great industrial research labs in existence, is the subject of constant fights between Microsoft executives that want to keep it and those that view it is an expensive tax on the rest of Microsoft.
My belief is that research and industry can coexist well. I think industry should hire researchers. I think the key is organizing in a way where research is inspired by novel problems in the products and product is strengthened by the deeper knowledge of research. While many organizational models can work, it seems to me that one of the more successful ways to organize researchers is to embed them in product teams and shift frequently (< 1 year) between product teams.
So, I hope you feel that we are largely agreeing and that we have the same goals. We both want researchers to be hired by industry and to be successful in industry. My article only was intended to start debate on how to make research more successful in industry and put forward one model that appears to work well.
I do think we’re mostly in agreement. I would modify your strategy of embedding researchers in product teams by saying that researchers should be embedded in product teams temporarily when transferring an idea from research into product. For the duration of the transfer, the researcher should work with the team and be subject to the same constraints as other members of the team. Once the transfer is accomplished, the researcher should return to the research organization to pursue the normal research process. Without such clear differentiation, it will be difficult to sustain an independent research organization capable of generating true innovation.
I would agree with this completely. I think valid empirical research would really benefit all stakeholders with respect to product innovations. It does appear that many technologies suffer from inadequate grounding in empirical research. It seems many vendors continue to use marketing as their primary tool for product introductions in search of quick profits. It’s very difficult to convince product vendors to recognize research because the common capitalistic wisdom is often rooted in marketing. We can look at the e-reader market and see that the lack of research recognition into different reader profiles is hampering the growth of the market. The Kindle studies at numerous colleges found that the devices cannot support active reading. E-ink and portability are not drivers for adoption among active reading genres; namely students or work related reading. If Amazon or other vendors had really internalized the prior empirical research, there would have been little need to conduct studies in higher education (Princeton, Reed College, etc.). All of the results at these colleges were completely predictable. Knowledge about past research would have rendered these studies not really necessary because the findings were no surprise at all. Whether Amazon was defiant or ignorant of the prior research is unknown. It just underscores the point that you’ve all made about having the right researchers on staff. Perhaps we should put a finer point on i and say not marketing researchers, but those researchers that are specific to the domain of interest. However, there is always the divide between ‘academics’ and the ‘real world’, which continues to thwart many innovations.