I recently visited both locations on the same day. PARC, of course, is the legendary research wing that created the graphical user interface, the personal computer, object oriented programming, the mouse, Ethernet and the laser printer. It was at PARC that Steve Jobs saw the interface that would eventually form the OS foundation for the Macintosh. Every time we touch the technology that today we take for granted, we should give thanks to the many people who have called the unassuming campus on Coyote Hill Road home.
But in 1969, when PARC was first created, there was a different attitude towards R&D. Research required isolation and distance from the regular business rhythms of the mother ship. Xerox could not have put more distance between its head office, in Rochester, N.Y., and its new research arm, 3,000 miles away. When it came to innovation, the choice of location was fortuitous. PARC, together with HP and other Silicon Valley pioneers, tapped into the stream of talent that was coming out of Stanford. In fact, PARC is located on land leased from Stanford. It soon became an innovation hotbed, thanks to the visionary leadership of Bob Taylor, who headed up the Computer Science division. But Xerox’s track record of bringing its own innovations to the market was dismal. As great as the physical distance was between PARC and the executive wing of Xerox in upstate New York, the philosophical distance was several times greater.
efforts, under the leadership of Peter Norvig, is taking a much different direction, likely due to lessons learned from PARC and others. Research is embedded in the ever-expanding Google campus
that currently sprawls along Amphitheatre Parkway and Charleston Road. There is a free flow of traffic and communication between current product engineering teams (many riding brightly colored Google
bikes) and those working on longer-term projects. The distance between “today” and “tomorrow” is minimized at every opportunity.
Norvig commented on this in a recent interview with me: We don’t have a separate research entity whose job is to be isolated from the rest of the company and think about the future. Rather, everybody’s job, regardless of their job title, is to make our products better or invent a new product. So the distinction between being a researcher versus an engineer is not how academic you are, it's not how forward-thinking you are -- whether you're looking at this year or next year or the year after. It’s more in terms of the area that you work in. If you work in core search or in core distributed computer systems, then your title’s going to be software engineer, even if you're a Nobel Prize-winning professor.
Google has taken a hybrid approach to research, in which even long-term projects are developed at production scale, minimizing the risk of projects failing during the technology transfer phase. Norvig touched on this in a recent article: Elaborate research prototypes are rarely created, since their development delays the launch of improved end-user services. Typically, a single team iteratively explores fundamental research ideas, develops and maintains the software, and helps operate the resulting Google services -- all driven by real-world experience and concrete data. This long-term engagement serves to eliminate most risk to technology transfer from research to engineering.
This was exactly the trap that PARC ran into, when some of the most innovative advances in the history of computing failed to significantly contribute to Xerox’s bottom line. Google has thrown the doors open for internal research teams to access the full power of complete data sets and production scale systems while espousing the practice of agile development. The goal is to ensure that all innovation that happens at Google is not too far removed from the goal of either diversifying Google’s revenue stream with new products, or contributing to existing ones.