Communications of the ACM
Research in the Wild: Making Research Work in Industry
How to do research in academia is well established. You get grants to fund your group, attract students, publish papers, and pump out PhDs. Depending on who you ask and how cynical they have become, the goals are some combination of impacting the field, educating students, and personal aggrandizement.
Research in industry is less established. How to organize is not clear. The purpose is not even well understood. The business strategy behind forming a research group sometimes seems to be little more than a variant of the underpants gnomes' plan. Phase 1: Hire PhDs. Phase 2: ? Phase 3: Profit!
Generally, researchers in industry are supposed to yield some combination of long-term innovation, improving the sophistication of technology and product beyond simple and obvious solutions, and helping to attract talented and enthusiastic developers.
To take one example in search, without researchers who know the latest work, it would be hard for a company to build the thousands of classifiers that ferret out subtleties of query intent, document meaning, and spamminess, all of which is needed for a high quality search experience. Information retrieval is a field that benefits from a long history of past work, and researchers often are the ones that know the history and how to stand on the giants' shoulders.
Even so, there are many in industry that consider researchers an expensive luxury that the company can ill afford. Part of this comes from the historically common organizational structure of having a separate and independent research lab, which sometimes looks to be a gilded ivory tower to those who feel they are locked outside.
The separate research lab is the traditional structure, but a problematic one, not only for the perception of the group by the rest of the company, but also because the researchers can be so far from the company's products as to have little ability to have impact. Many companies appear to be trying other ways of organizing researchers into the company.
For example, Google is well known for integrating many of its researchers into product groups and shifting them among product groups, working side-by-side with different development teams. While on a particular project, a researcher might focus on the part of the problem that requires esoteric knowledge of particular algorithms, but they are exposed to and work on many problems in the product. When this group comes together, everyone shares knowledge, and then people move to another group, sharing again. Moreover, these ephemeral teams get people to know people, yielding valuable peer networks. When a tough researchy problem later comes up and no one nearby knows how to solve it, finding the person in the company who can solve it becomes much easier.
Many other companies, including Microsoft, Facebook, and Twitter, maintain separate research organizations, but try to keep the researchers working very closely with the product teams. At these companies, the impetus for novel research often is a problem in the product, usually a problem that would not be obvious in academia because of their lack of access to big data and scale.
What organizational structure works best in industry may depend on our goals. For immediate impact, having researchers integrated into product groups provides a lot of value; they are directly solving today's hard problems. But, what about the problem that might hit in a year or two? And what about long-term breakthroughs, entirely new products, enabled by new technology no one has thought of yet?
My personal opinion leans mostly toward integrating researchers on projects, much like Google does, but also giving researchers 20% time (as all developers should get) and occasionally turning a 20% time project into a full project (again, as all developers should get, but the threshold for what is considered impactful might differ for a researcher, given the speculative gamble that is the nature of research). This strikes a balance between immediate impact, doing novel research, and taking advantage of a long-term opportunity when inspiration hits.
What do you think? How should researchers be organized in companies? Why?
Comments
Jeremy Pickens
My immediate reaction is that the 20% time (40% is more my preference, but the same principles are at play even if there are disagreements about the actual threshold value) is a fine way to go.
But I've heard from multiple friends that often -- again to use your Google example -- if you actually want to use that 20% time you have to work 120% time to do it.
So just like there is a struggle to get Bell Labs-style (traditional ivory tower) research out into the rest of the company, there is also a struggle to keep product pressures and Q3 deadlines from impinging on 20% time.
Perhaps that's why I would argue in favor of 40% time, or even 50% time. Because when your product manager pushes back against you, and demands more of your time because you need to ship by Tuesday, it's more difficult to take all 40-50% away from you.. you might actually end up with that full 20% as a compromise.
Gene Golovchinsky
Research as a process and a profession and as a mindset is quite different than product-making. Pushing the two too close together or expecting people to be good at both may not always be optimal. See Research as product on the FXPAL Blog.
Daniel Tunkelang
Rather than worry about what percentage of time researchers allocate to product teams, I think it's more important to align the goals of the research and product organizations.
When I ran a research group in my previous gig, the question I'd ask product management before starting any project was this: if we solve this problem, how much will you care?
If the answer wasn't enthusiastic, then I knew that my team was taking a real gamble to invest in the project. A positive answer at least reduced the risks to feasibility, execution, and the possibility that product management would change its mind by the time we had a solution. The last was a serious risk for a large project--which led us to favor projects with iterative deliverables that we could demonstrate to product management.
Every organization finds its own way. But I'm a fan of models that keep research and product playing for the same team. Even better if researchers and developers work closely together -- and blur the difference between the two roles.
Displaying all 3 comments