Research Is Not Engineering at a Slower Speed – THE VOICE IN THE MACHINE

Skip to content

THE VOICE IN THE MACHINE

June 2026 (1)

April 2026 (2)

March 2026 (1)

January 2026 (1)

October 2024 (1)

May 2024 (1)

July 2014 (1)

October 2012 (1)

August 2012 (2)

July 2012 (5)

June 2012 (4)

June 10, 2026

Research Is Not Engineering at a Slower Speed

Three kinds of work, three success criteria, and why confusing them is costly.

Early in my career I worked at Bell Labs, where one could work on any intellectually challenging problem, whether or not it had immediate relevance to the mothership AT&T. Later I worked at startups where the pressure to sell and ship was the only thing that mattered. At IBM Research, where I was a researcher, and then a manager, the relationship between research and development was marred by constant tension. At ICSI, a purely academic institution where I served as Director, work perceived as close to a product was unwelcome by most of the theoretical researchers, and the agenda was driven entirely by research grants. At Google I led a large team of R&D engineers in an environment where research and engineering were institutionally separated but collaborated closely. At one of my most recent positions at an enterprise AI company, I led a large AI engineering team that occasionally did interesting research, though the company rarely knew what to do with it.

My long journey as a researcher, engineer, and leader through the most technological aspects of AI taught me something that even highly technical people often miss: research, R&D, and product engineering are not simply the same activity performed by the same people at different speeds and under different levels of pressure. A good friend of mine, and an amazing technologist, once joked that engineering runs on quarters of three months, while research runs on a quarterly of a century timeline. In reality they are fundamentally different jobs, with different goals, different success criteria, and people with different motivations and experience.

The confusion is understandable. From the outside, they all look like smart people working on hard technical problems. But conflating them has real consequences. Organizations that do not understand the difference tend to underfund the work that matters most, overpromise on the work that is hardest to measure, and more importantly chase away talented people who feel they do not fit properly within the company agenda.

Before going further, one clarification. None of what follows is an argument that one kind of work is more valuable than another. A great product engineer who ships reliable software at scale creates enormous value. So does a researcher who spends three years on a problem that may never ship. The mistake is not in choosing one over the other. It is in confusing them, or expecting one to behave like the other.

The technology portfolio lens

A useful starting point is to think of these categories along two axes: impact in case of success, something related to return on investment, and probability of success, directly related to something called epistemic risk, that is uncertainty about whether the knowledge needed to solve a problem even exists yet. These two axes together define a space that innovation portfolio researchers have mapped into four quadrants, a framework developed by Robert G. Cooper and colleagues for R&D portfolio management. The quadrants have names that are worth knowing: Pearls (high probability of success, high impact), Oysters (low probability of success, high impact if achieved), Bread and Butter (high probability of success, low impact), and White Elephants (low probability of success, low impact). If you wonder about the term "white elephants", it comes from the legend of those sacred animals that existed in parts of Asia, and that a king would gift to courtiers he wished to ruin: too expensive to maintain, too sacred to put to work.

The goal of any healthy technology portfolio is to cultivate Pearls, pursue Oysters selectively, keep Bread and Butter work from crowding everything else out, and eliminate White Elephants as quickly as possible. Mapping the three categories of technical work onto this space gives us a useful picture.

Product engineering lives in the Bread and Butter quadrant. The time horizon is short, typically one to six months, epistemic risk is low, and the goal is to take existing technology and turn it into something reliable and useful. Examples are everywhere: fine-tuning a pre-trained model for a specific domain, improving speech recognition accuracy on a known test set, reducing inference latency in a production pipeline. Success is measurable: does it work, does it scale, does it ship on time? Are customers happy?

R&D occupies the Pearl quadrant. The knowledge base exists, the technical direction is reasonably clear, and the goal is to push current systems significantly further. Retrieval-augmented generation after the...