Successful industry-academia relationships don’t just happen. Here’s what it takes to start a collaboration and make it work.
As a research supervisor, one of my most important tasks is finding a good fit between engineers with a problem and academicians who can collaborate with them on a project to explore some aspect of that problem.
Not every engineering problem is a good match for research—and not all professors are interested in topics immediately relevant to industry. Finding the right people and building a bridge between them is a process that has taken time to develop.
Starting as a research supervisor
When I began work at the Red Hat Research site in Israel, we did not have someone in a research supervisor role. Although this role existed at other sites, every region has different relationships among academic, industry, government, and related entities; we needed to create our own processes.
Idan Levi (Research Director of Red Hat Research in Israel) and I knew that the research supervisor would function as the person between the academic and the industry sides of a project. What we needed to determine through experience was all the different elements of bringing engineers and academics together. For example, when a professor speaks to someone from industry, they may be using the same words but mean very different things. For successful industry-academia collaboration, you need someone who can translate. But the work goes well beyond that. In fact, it starts before a project even exists and then continues all the way to successful publication and upstreaming.
The lifecycle of a research project
My first responsibility is to find unsolved problems: is there a challenge an engineer or team is facing that could be solved with science? For example, is there a problem that an engineer is trying to overcome with a lot of compute resources that an efficient algorithm could address instead so the cost of resources and run time is not so high? My background (a PhD in Computer Science from the Technion University in Haifa, Israel, and a history of publishing) is very helpful here, because a research supervisor needs to understand both how an engineer thinks and what constitutes a good research problem.
Then I need to identify the relevant party in academia who would be a good fit for creating a collaborative project. To do this, I’m working all the time on expanding our network of academic connections, finding researchers who work in the technical fields relevant to Red Hat Research. I build a list of problem-solving engineers on the industry side and a list of researchers on the academic side, and then I can do the magic of matching the right people together. And that’s all before the project begins.
Typically, academics and industry have different priorities: professors want to publish a paper, and engineers are thinking about products. At Red Hat Research, we have a unique position that helps us bring the two groups together.
At that point, I bring the parties together for a conversation, or sometimes several conversations, and help mediate to ensure that we can establish a research-worthy challenge and a common goal.
More and more academics are becoming aware of the advantages of open research and want to contribute to open source projects. Red Hat is easy to collaborate with: we don’t want to claim any intellectual property (IP), so we encourage researchers to publish freely. However, we also implement solutions in a practical way by upstreaming them as high-quality code. It does take some discussion to get the problem defined in a way that all can agree on, but it’s essential to do that in advance so the project stays on track.
After the collaborators shake hands and start work, the research supervisor’s role combines advanced project management and participating in the actual research, for example, by attending brainstorming sessions or supervising students on the technical aspects of the project. It’s my responsibility to monitor the project for the entire lifecycle and make sure that it doesn’t get frozen at some point. If a problem arises, I’m in charge of solving it. Here again, the research supervisor needs to see things from multiple perspectives. I need to understand the technical aspects of the project and academic process, and if someone is not satisfied, I need to understand why so I can resolve it and make sure everyone is happy with the results at the end of the day.
When the project is finished, I help see that it gets upstreamed. At some point, we will promote the innovation in hopes it will become part of a product that can benefit the masses, but that’s not our role. Our goal is to push the innovation’s boundaries.
Creating high-quality projects
That’s one of the most valuable things about the research supervisor role. Having a person to make these matches and facilitate these conversations leads to higher quality projects.
Because this way of working is still relatively new for us, I can’t point to a project that completed the full cycle—yet. However, a good example of the process comes from an engineering team based partially in Israel that is working on low-level network visualization. In this case, we were approached by the team, which is the reverse of how it usually happens. This team wanted to begin a research project but didn’t have the academic connections to do so.
I connected them with a professor from one of the universities we work with, and they have been in regular, active brainstorming sessions every two weeks or so for about the past five months. As of this writing, they have not entirely determined a final proposal, but that in itself is quite instructive. Although it has been difficult for them to find common ground and define a project that satisfies the needs of both sides, they really liked each other from the very beginning and are eager to work together. That suggests to me that they are a good match, so the project they eventually create will be something worthwhile.
That’s one of the most valuable things about the research supervisor role. Having a person to make these matches and facilitate these conversations leads to higher quality projects. And they are high-value projects because they are based on an understanding of where the industry is going, what the leading research topics are, and where the potential for overlap is.
After taking the time to develop our processes for research supervision at Red Hat Israel, we are also sharing them. For example, in Brno at Red Hat Czech, Martin Ukrop has begun working as a research supervisor using what we’ve learned. This model has been successful here and in Brno, and I hope we can keep spreading this success to many locations over the coming years.