Author: Dirk Riehle, SAP Research, SAP Labs LLC
Reference: Steven Fraser (editor). “Escaped from the Lab: Innovation Practices in Large Organizations.” In Companion of the 2008 Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA ’08). ACM Press, 2008: Pages 787-790.
Available as a PDF file; my part follows as HTML below.
Position statement for the OOPSLA 2008 Panel on Innovation Practices in Large Corporations
In most companies, the innovation process is organized as follows: A research unit suggests to build a prototype of some innovative product or feature, a line-of-business sponsor signs off on the project, the research unit develops the prototype, a product unit receives it and turns it into a real product.
The critical point is the transfer from research to product unit. Here, many things can go wrong, for example:
- The prototype is incompatible with the current product technology;
- The innovation does not address the real problems of the product unit;
- The prototype and innovation are incomprehensible to the product unit;
- The prototype is late and the product unit is already developing its own solution.
The underlying problem is the organizational separation of research from product unit. In most companies, research is separated from product units to prevent immediate product needs from usurping research and innovation resources. For effective transfer, however, research units need to consult with product units during the development of the research prototype. Unfortunately, product units are typically too busy to worry about research projects. Hence, product engineers are rarely assigned to engage with research projects early, or if they are, they frequently are too busy to do it properly.
At SAP, we have been complementing the traditional top-down process of research-to-product unit transfer with a self-organizing bottom-up process that we call open collaboration [1]. Open collaboration is characterized by the following three core principles:
- Egalitarian: Everyone can participate; no borders to joining a project are erected.
- Meritocratic: Contributions are evaluated based on merit; seniority is less important.
- Self-organizing: The collaborators choose their own collaboration processes.
Open collaboration happens, when forward-looking engineers from product units engage with researchers on their own free will rather than as the result of a top-down assignment. We have found that letting engineers choose by themselves is critical to the success of the engagement.
Most product units have engineers who are curious about “the next big thing” and who are happy to engage with a research project if they think it has a future. Such engagement takes place while the research project is still going on, and product unit engineers contribute by providing valuable real-world insight. Product engineers can generally ensure that the research prototype will be compatible with the product unit’s need. At the same time early engagement ensures familiarity with and buy-in into the research project by the product unit, which significantly eases later transfer.
This strategy is counter-intuitive to most senior managers’ experience. After all, if no engineer gets assigned to engage with the research project, it won’t happen. We observe the opposite: By self-selecting, product engineers seek out and find exactly those research projects that have the highest likelihood of success and where they can contribute the most.
At SAP, we use two key technologies for fostering the process of open collaboration: software forges and wikis. In [1] we describe how using SAP’s internal software forge research projects can find volunteers from product units to help them with their prototype. Our preliminary results promise a significantly eased research-to-product transfer. In addition, for non-source code related collaboration, we heavily rely on wikis. Both wikis and software forges are built on the principles of open collaboration: Everyone can join, there is no or little status hierarchy, and collaborators make up their own processes [2].
We have found that open collaboration has created self-organizing processes within SAP across departmental boundaries that foster innovation and increase the chances of successfully transferring research projects to product units. Our next step is to further enhance open collaboration in SAP’s rich and flourishing ecosystem of customers and business partners.
References
[1] Dirk Riehle et al. “Bringing Open Source Best Practices into Corporations Using a Software Forge.” IEEE Software, 2009, to appear. Available at https://dirkriehle.com/publications/2008/bringing-open-source-best-practices-into-corporations-using-a-software-forge/
[2] Dirk Riehle. “Bringing Wikipedia to Work: Open Collaboration within Corporations.” In Proceedings of Wikimania 2008. Available at https://dirkriehle.com/2008/05/28/bringing-wikipedia-to-work-open-collaboration-within-corporations/
Leave a Reply