White paper: Google's Hybrid Approach to Research

Alexander opened with a joke: last time, on the chapter about fault tolerance, it was the Miro board that failed the fault-tolerance test and the story had to be told by voice; he prepared no separate slides this time either, but the board did work. The guests introduced themselves: Igor Maslov leads the group's core data-processing technologies — the internal tools that raise engineers' productivity and efficiency, which by his own account take 99% of his working time. Stanislav Moiseev works inside Igor's unit and curates engineering research, helping push the company to the frontier. The white paper itself, Alexander recalled, appeared in 2012, one of its authors is Peter Norvig, and it holds literally five or six pages of substantive text.

It opens with Google's mission — to organise the world's information and make it universally accessible and useful — and draws three consequences: the economics of scale, where information is vast and teams need powerful abstractions for computation, storage and networking in data centres; a delivery model around services, where teams of different sizes assemble complex products on internal tooling; and the ability to hire people who carry not just product features but research along the way. One of the guests underlined something easy to miss in the opening paragraphs: Google wants research to end close to production, with systems built ready for use from the start — unusual for research work. Broadly, the approach breaks into five points: work in directions the company cares about; cut large research into short steps, each owing a result — a rollout, a paper, a local improvement or at least a negative experiment; lean on the enormous infrastructure and user data; assemble teams flexibly, with no single correct scheme; and spread knowledge through papers, standards and open source.

Stanislav described the paper's key slide as an enumeration of every way to connect the yellow circle with the green one. Pattern one: an engineering team runs its scheduled work, suddenly gets something nobody had before, and decides to tell the world. That is rare: a team may have no interest in formulating and publishing a result, a KPI may get in the way, or there is no habit of singling out one's own findings. Google's own example sits here: they solved a practical big-data processing problem first in the world, although the idea is not that complex and functional programming rests on the same one. One of the guests called the pattern partly disingenuous: the team storing the whole internet does research just to keep the system running day by day, and writes it up as papers only afterwards. Alexander added: Facebook has few engineering papers but endlessly many about social networks and graphs, and once the VR story started, papers on that appeared too.

Pattern two is a research team with a theme such as machine translation, living by its own internal logic; Google's example here is Google Translate, which started as a research project. The participants noted this needs money and people for risky projects, and is about a product rather than a technology. Pattern three is the research-then-develop pipeline, which the authors themselves call traditional and set their hybrid model against: researchers hand over a technology and the engineering team brings it to product quality, fixes the sources, runs security tests and writes documentation. Pattern four Stanislav honestly could not tell from the third by anything but how often the teams talk; the slide, he noted, shows neither external partners nor universities. Igor drew the boundary differently: in the fourth the teams jointly take on a problem the business understands, while the third is when he spends ages compressing data and then the YouTube team turns up, says wow, adopts it, and traffic drops sharply. Pattern five hands a research task to a partner, after which the relationship falls back into one of the first four. Andrey asked from the chat which pattern the guests like: all work at Google, the first is rarer, the second demands a certain culture and money, the third is the most reliable and classic, the fourth the best of the lot.

The diagrams reminded Alexander of a 2019 book by two consultants on team topologies: stream-aligned teams around the business, platform teams, enabling teams that plug in and help, and complicated-subsystem teams whose expertise is too expensive to keep in every team. The book's collaboration mode is exactly pattern four: a product team and a platform team agree what the product will look like and build it together. But collaboration is expensive, two teams spend a lot of time in discussion, so the goal is to bring the contracts and product surface to where it is offered as a service and scales well. A participant who joined late brought a thesis from his outsourcing experience: there R&D usually ends in a project rather than a product. Alexander objected that real research goes not to an outsourcer without frontier competence but to a university lab, and is better called a partnership, split into stages with an incremental result.

In the decade since the paper Google has not stood still: a page on its research philosophy now sorts work along four axes — fundamental research, new products, contributions to existing products, and infrastructure. Robotics counts as fundamental for Google, whereas for Amazon with its warehouses it is purely applied; machine translation grew into a product of its own; and BigTable, GFS and the big-data processing engine are the classic infrastructure research without which the key products would never have got going. Stanislav added that the axes differ by their metrics: a product improvement is measured by speed and quality, an infrastructure one by new capability and scale. Igor saw a shift here: in the 2012 article fundamental research was rather discounted, while the philosophy page calls it a top priority; Alexander added it stands first in their list of key areas. Alexander put the products page on screen and Igor talked through them — an observability platform with a home-grown database for logs, and speech recognition and synthesis services grown out of call-centre automation — announcing that from next year the research gets more systematic; Stanislav, Alexander added, is already hiring.