Barriers to collaborations between industry and research labs
Bridging the Valley is a series recording a shared exploration of the potholes in the road of hardware technology development between lab research and implementation. These obstacles often prevent the productization of new technologies, causing a phenomenon called the “Valley of Death.” In this and future articles, the author dives deeper into the causes of the Valley of Death that we hypothesized in the introduction to the series, and provide more information on various areas of the technology development ecosystem.
There are many paths to realize new technologies into products. In the last article, we focused primarily on the route of entrepreneurship emerging from a research lab, but now we shift our focus to collaborations between industry and research labs. Interestingly, one of the most significant barriers to this mode of technology development appears to be friction caused by cultural differences between the labs and corporations. Let’s discuss what these cultural differences are, and how they have such a large impact on the outcome of these collaborations.
Based on research on this topic, the major themes of this divide appear to be:
- Differences in goals: The drivers for researchers can be different from those of their partners in industry, which results in distrust and diverging preferences in how to proceed during decisions in the research process.
- Differences in expectations and background: Researchers are accustomed to things like academic freedom and much longer time scales.
- Breakdown in communication: Communication can be difficult because of different assumptions and lexicon. It’s even more difficult if the knowledge background of the two partners aren’t complementary. Beyond that, certain kinds of technical knowledge are naturally very difficult to communicate.
- Difficulty building trust: Because of a variety of factors, trust can sometimes not be established, leading to suspicion of ill intent and conflict.
There are actually two problems that emerge from these cultural differences that we care about. The first is friction and negative feelings between the lab and industry partners, which discourages future collaboration and gives a bad reputation to these types of partnerships. The second is failure to discover and transfer the relevant technology to the industry partner. The whole purpose of this article series is to facilitate precisely that. Let’s discuss these cultural differences in more detail to understand how these two problems emerge.
Differences in goals
In research social circles, the measure of success is generally the number and importance of novel intellectual contributions, measured by papers published in esteemed journals, citations, and general recognition by peers. This can sometimes be at odds with the goals of industry, which are to make a differentiated and profitable product [1].
Having different goals commonly becomes a problem as companies consider the secrecy of the developed intellectual property [1]. Researchers want to publicize their findings, and the goal of university labs is the teaching and dissemination of knowledge. Most industry partners rely on maintaining trade secrets to give their product a competitive edge. These goals are precisely at odds with each other, which can lead to disagreement and distrust. If an industry partner doesn’t trust their research partners to maintain secrecy of information, then there’s no way information can be freely shared. Even with nondisclosure agreements in place, the industry partner might still be concerned about lab members letting trade secrets slip just because they’re accustomed to an environment of free information flow.
Differences in expectations and background
In my discussions with researchers on the topic, by far the most common friction between industry and researchers mentioned is timelines. Lab researchers are used to much longer timelines for projects, while industry tends to be very fast paced, driven by the need to respond to rapid developments in the market.
The time frame that an individual is accustomed to heavily influences their behavior and decisions. Imagine you’re a researcher whose experiment just failed, providing evidence that the approach isn’t likely to achieve the intended effect, but not providing decisive proof. If you have more time available, you’d probably be more likely to pursue further experiments to increase your confidence that this is a dead end — especially because you want your paper to be rigorous. This kind of methodical process is an expected standard in research, and it’s built into the culture. However, the company that partnered with your lab and is funding your research likely has a strict timeline. They probably want you to move on to exploring a different approach. [2] Even without ill intent, one might see how this can become a point of friction — especially if there isn’t constant communication informing both parties of expectations on how to move forward.
Another instance of different expectations that can lead to disagreements is the highly valued academic norm of academic freedom, or the ability to freely investigate and discuss areas or problems of their choosing. In a research collaboration, the needs of the market need to be the driver in what research should be focused on, or it won’t result in an economically beneficial technology for the company.
Breakdown in communication
In general, studies show that having enough engagement and touchpoints between research partners is essential [3]. Most people who’ve experienced interorganizational collaboration will likely agree with this. A fairly consistent trend in my career in product design consulting was that the more touch points we had with a client, the better the project went. Some of the most successful projects that I ran did well because our team was fully integrated into the client’s team, and often even worked at the client’s office.
However, the knowledge of technology transfer can be difficult by nature — and some is tacit knowledge, which is transferable from one person to another only via experience. It’s extremely difficult to transfer tacit knowledge via reports, patents, or other recordable methods (as opposed to explicit knowledge, which is much easier to transfer via those methods). For example, while designing hardware, I’ve come across several instances where I absolutely couldn’t explain the severity of a problem to a client. I tried explaining it via meetings, diagrams, and videos. Nothing could get them to understand until I was able to place a prototype in their hands and they could experience the problem for themselves, upon which they immediately realized they couldn’t ship the product with that issue.
If the necessary methods of communication for transferring both tacit and explicit knowledge aren’t in place, the research partners won’t be able to communicate important technical knowledge [3]. In the cases where the industry partner doesn’t have a similar knowledge background to the lab partner, it can be additionally difficult to transfer research knowledge, and even more so for the industry partner to internalize that knowledge to the point where it’s useful to them [3].
Because of the differences in backgrounds, the industry and research lab partners might also have different understandings of terms. Especially during the beginning phases, where understanding and expectations are being established, if terms are used during communicating expectations where each group has a different understanding or definition of that term, the expectations end up being misaligned [1]. Having different understandings of an early agreement can end up with huge disparities between what a group is willing to do versus what their partner wants them to do.
Difficulty building trust
The impact of not trusting a partner results in finger-pointing, assumption of ill intent, and withholding information. I’ve seen a few instances of this over my career, as I’m sure many people have. Obviously trust is important. It enables both of the things we care about: continued collaboration and information exchange [3].
Based on my own experience, if there’s a difference in the way two groups of people think, frame problems, prioritize goals, or even how they talk, it’s easy to fall into an “us” and “them” mindset. You can see it in the relationship between engineers and sales in some companies — when engineers start talking technical and the eyes of the sales team start to glaze over. Or in consumer product development when industrial designers are talking about the same problem as engineers, but the designers are saying, “That solution completely destroys the design. The product would never sell looking like that. How could they even think to propose this?” Meanwhile, the engineers are saying, “That’s an absurd design. It’s simply not possible to manufacture! Why would they even bother with this design approach?” They both want to solve the problem, but they’re looking at the box from completely different dimensions because of their backgrounds.
Experiencing situations like these repeatedly can quickly result in an “us” and “them” mindset. The more different two groups are, the harder it is to establish trust. I can understand why this research article [1] is saying that it’s extremely important to find the right partner. It’s easier when the interpretation of words and problems are approached similarly. However, I do want to add an important caveat to this: I believe differences in culture and approach are absolutely necessary to come to the right solution — you absolutely need both engineers and designers to make a quality consumer product — but solutions need to be intentionally implemented to prevent rifts from being caused by those differences.
To increase the frequency and success rate of technology transfer to industry, we need to identify solutions to either overcome or circumvent these cultural differences. Each of the papers cited in this article actually already proposes solutions. Before we start proselytizing those solutions, however, we would benefit from having more discussions with people who have experienced these kinds of industry and research lab collaborations. It’s very important to understand the full context, which is much more easily obtained through a discussion than a paper. If you or someone you know has relevant experience, please reach out to me on our Discord!
informal is a freelance collective for the most talented independent professionals in hardware and hardtech. Whether you’re looking for a single contractor, a full-time employee, or an entire team of professionals to work on everything from product development to go-to-market, informal has the perfect collection of people for the job.