Reflections on Bell Labs: Part 2

May 19, 2024. In this post, I ponder how to perform creative applied research in a small (but not distributed) environment.

Live in the future.
— Paul Buchheit

Live in the future, then build what's missing.
— Paul Graham

Live in the future, find what's missing, and leave the rest to the development team.
— The ghost of Mervyn Kelly

Contents

  1. Who: core-forward
  2. What: problem choice
  3. How: collaborative management
  4. Where: environment
  5. When: funding and development

Last time, I suggested that it might be possible to do great applied research in a distributed fashion, like open source software development. I wish that were true! But the more I think about it, the more it seems like many of the factors that made Bell a success—focus, mission, creative and intellectual latitude—don’t mean much unless they are built into a job description. Put differently, no one is going to invent the transistor in their free time; the required quanta of effort and attention are too large. The only realistic option is to pay people to think about these problems full time.

The two traditional approaches are academia and industrial R&D. Universities are slower, clunkier, more hidebound and inward-looking; industry is more constrained by revenue and other research-exogenous factors. Neither path is ideal. And while Bell had the best of both worlds, its material circumstances are unrepeatable. But maybe you don’t need a state monopoly to enjoy the merits of both Ivory Tower and boardroom. While open sourcing is scaling down too far, I’ll consider how we might realize the recipe in a startup or nonprofit.

1. Who: core-forward

I’ll lead in with a little elevator pitch. We have a bunch of hard, important, and unsolved problems. Many remain unsolved not so much because they are hard, but because they are too applied to excite a professor, and too far from turning a buck to excite a CEO. This may seem like a notrivial prior about problems, but it’s supported by a simple empirical experiment: look at what people work on. The problems lie, in other words, in the dead zone between academia and industry that Bell mined so successfully. Thus, it makes sense to emulate the Bell recipe: hire a bunch of smart people, put them in rooms with sunlight, keep them stimulated, focused, and well-fed, and ultimately, by management and judicious organizational structure, get them to solve problems in creative ways. It worked for Bell.

We can flesh this out using the grade school strategy of “wh-“ questions, starting with “who”. At Bell Labs, they hired scientists who could also have gone on to good postdocs; I’m guessing that a flair for applied research, a porousness to new ideas, and compatibility with existing personnel, were prerequisites in addition to academic pedigree.

In a small-to-medium size organization for creative applied research, the structure will be initially different, and the requirements will change with it. Rather than build out labs from the get-go, I suspect it is better to develop a tight-knit core team of researchers with overlapping but complementary areas of expertise, exemplary synergy, interdisciplinary spirit, and the ability to make a killer slide deck, i.e. to explain themselves clearly. Each researcher may have a primary domain, but will be radically attentive to the possibilities of overlap with other domains, since combinatorics and indeed common sense favour the notion that new ideas live in the gap between disciplines. Why should the universe obey our rules?

The goal of the core team is exploratory, not completist; they sketch out the global shape of the problem space, things like technical lacunae, points of intersection, roadblocks and avenues of attack. Although they do not produce finished research, they need to be able to go technically deep and take core samples. Pun intended. Once the core team reaches a threshold level of strategic clarity, some core members will differentiate into “research leads”, and start to build out the teams to pursue these strategies. At this point, hiring might begin to look more like Bell.

That said, some core members should continue articulating the shape of problem space, full-time, since that shape will change as new data comes in. The individual research teams will not only be drilling core samples, but expanding and connecting those narrow shafts into wells; they will feed their local data to back to center and receive global data in return. To facilitate this, research leads should remain loosely coupled, part-time members of the core. The hope would be to replace superhuman managerial insight with a natural flow of information between core, research leads, and teams. Of course, the core itself will still require oversight and leadership, which I’ll get to below.

This approach is driven by a few considerations. First of all, having a core flanked by specialized teams gives a natural outline and hierarchy to management; second, it makes synergy and interdisciplinary critical mass a central part of the strategic vision; finally, it lets the organization start out small and flexible. Although being “lean” is more often associated with software development, it also makes sense in a research context where both methods and problems are in flux.

2. What: problem choice

3. How: collaborative management

4. Where: environment

5. When: funding and development