Deciding which organisational structure is most efficient for pushing forward research & development initiatives, taking into account the interaction between research, engineering, and product teams, has long been a big topic of discussion as it is paramount as a precursor of success. Organisational behaviour and structures are deemed to change in the era of Generative AI. Our success in applying Generative AI technology to Nexar will be large conditioned in our ability implement the right organisational structure to optimises productivity and velocity.
The classical model for R&D, which started in the early 1960s and lasts to our current times, is for research and product development organisations to report into the CTO, or sometimes the CEO. This model works well when the organisational objectives depend critically on the innovation potential and hence require high visibility of the progress at the executive suite. This model was followed rigorously by Intel, Xerox, and IBM Almaden for decades.
The birth of the Internet however challenged this model, particularly in the area of information retrieval. As more teams were trying to develop products that were used by millions of people, and which required signals from all over the world in order to develop the algorithms, the classical approach of gathering data, going away for a few months, and coming back with results and a paper started to fail. The cycle of innovation was too long, and the need for a faster ability to develop and test in the field started to appear. Particularly in web search and computation advertising this has been, and still is the problem, as these applications rely almost exclusively on the data generated by the users themselves. The algorithmic development, choice of models, architectures, etc. as well as the training, evaluation, testing and fine tuning of the models is only possible against real production data. And agility of results is paramount.
This need led Inktomi, a search startup in the 1990s, to propose a new model for product development, where engineering and research work very closely in some projects and research takes an active role in leading product development. At Inktomi research as a force for IP creation was not an objective of its own, like it had previously been at IBM or Xerox, but rather research only became efficient if it was incorporated into the product as soon as possible. This model separates the work of research into three buckets:
- Pure research, led by scientists and closer to the original IBM model, and which serves to prove the viability of a solution not strictly required in the product roadmap in the next 6-18 months. These are usually step change that jump the company forward. The end result is IP generation, and measured by papers published and patents filed (and granted).
- Applied research, led by engineers, and which serves the day-to-day product development needs of the product in the next 0-3 months, and be solved by adapting existing “science recipes.” In this model, results are measured by products shipped, as a binary contribution of research into the product.
- Hybrid research, led by scientists with the support of engineers, which addresses immediate needs of the product in the next 3-12 months, when there is enough published research, but no available existing “science recipe” yet.
The model that Google, Bing and a few others that deal with very large information retrieval problems adopted is the hybrid model. At Nexar, we are faced with a similar problem. The cycle from field results to research to engineering and back to the field is too long. Only by research being directly involved in the field and engineering we can provide the necessary agility that will allow us to deliver on the challenges we face.
Since only a few companies can afford to do pure research, applied research has been widely adopted in the industry, particularly in fields where there is substantive evidence and literature upon which to base ones products on. The research task basically comes down to selecting the next technique out of an existing pool, figuring out timelines, putting research engineers on it, obtaining the data, and a few weeks to months later, coming out with a working prototype, and sometimes a paper. This is then handed over to the engineering and product teams, which at their own pace (sometimes never), finish the work and bring this to production. Although this model is useful, this is not what we need in order to create the largest machine learning application on the planet outside of web search: we need both more research agility, as the boundaries of possible and impossible are rather unclear right now, and we need faster product development, as Generative AI removes many of the mundane tasks.
A model with many small pods working under the hybrid model would allow us to deal both with the research risk and engineering velocity. In these pods, the research team takes an active role in the definition of the product requirements, the metrics that must be met to determine success, and has an influential role in regards to defining the product strategy for the company.
Product management gets broken down into three different responsibilities under the hybrid research model:
- A scientist is responsible for defining the product requirements (for research features), and the focus should be on metrics to be met (e.g. F measure, recall, coverage, etc.). The research scientist in charge of a product is also responsible for identifying the dependencies between projects and prioritizing the work accordingly based on the estimation and planning timelines. A scientist collaborates across multiple pods.
- A (technical focused) product manager (TPM) is responsible for the day-to-day execution of the roadmap. PMs align field requirements with product requirements, and translate them into specifications and written requirements. A TPM is an engineer who happens to no longer write code. TPMs are ultimatelyresponsible for the on-time, on-budget, on-quality of multiple pods.
- Top-down product strategy is defined by the CEO and/or the CTO (this is true across all hi-tech product driven companies), and is not delegated down the organisation. The CEO and CTO take all field, research and engineering inputs and recommendations and define the overall strategy for the company, with a vision, goals and KPIs, assigned to teams and quarters.
The organisational structure for product development encompassing TPMs and scientists could be as follows:
- Small pods of 2-3 engineers and research engineers execute in each of the projects (e.g. road damage, traffic conditions, …)
- A scientist carries the work across many pods of the same domain. They are domain specialists, e.g. ego-localisation. This means that they may need to work with multiple TPMs.
- A TPM is assigned to 1-4 pods. This means that they need to work with multiple scientists, but only one scientist per project.