The core of interdisciplinary work is disciplinary expertise. There can be no interdisciplinarity without disciplines at the foundation of the effort. Striving to be “post-disciplinary” or a pure generalist leads all too often to mere dilettantism. Rather, my experience over a career of having built and managed interdisciplinary research programs – as the Research Director at for-profit Global Business Network, as the founding executive director of UC Berkeley’s Social Science Matrix, and now as the SVP of Programs at the non-profit Berggruen Institute – is that effective interdisciplinary teams consist of disciplinary experts, but ones with a definite instinct for generating insights from disciplines other than their own.
An effective interdisciplinary team doesn’t come into being simply by putting the best biologist, the best engineer, and the best painter (say) into a room together, and expecting that they will magically find a way to work with one another. Rather, one needs to find excellent people in each of these disciplines who also have an inclination (and knowledge of how) to collaborate with experts from disciplines other than their own. Much of my own work in assembling interdisciplinary teams consists in identifying subject matter experts who also have this personal quality of interdisciplinarity.
But what is that quality?
One way I describe this quality is by an analogy from computer software, namely the application programming interface, or API. APIs are how computer programs communicate with each other. An API represents a “service” to other pieces of software, and it is “exposed” via a document (known as an “specification”) that describes how to communicate with another program. (It is via an API that, for example, a GoogleDoc can be exported to MSFT Word or as an Adobe PDF document.) The API thus constitutes the means through which computer applications “talk” with one another; in other words, APIs are the basis for “interoperability” between different kinds of software. A computer system that meets this standard is said to have a “well-defined” API. Computer applications with well-defined APIs are thus interoperable with many other kinds of software, which makes them much more “extensible” and thus deployable in a wide variety of circumstances. Well described APIs also improve backwards and forwards compatibility with multiple generations of software, which tends to extend the shelf-life of the software.
In other words, an effective interdisciplinary person is much like a piece of software with a well-defined API. Such a person has whatever core functionality that they have – their particular expertise – but they are also able to talk and collaborate effectively with people who have other kinds of expertise (provided that they too have well-described APIs!). Such people tend to be highly interoperable with people with other forms of expertise. They also tend to be able to work with people who are both younger and older than them (e.g. backwards and forwards interoperability) and thus to have long careers because they are able to continuously interface with new forms of expertise. In addition to making them a more effective collaborator, a well-described API also provide the basis for becoming a lifelong learner.
This analogy then yields a pedagogical principle: what we should be doing with students is not only making them strong in a particular discipline (this is their “core functionality,” to continue the software analogy) but also ensuring that they have a well-described API that will make the interoperable and extensible, backwards and forwards compatible. Some might say that this is simply the principle of a liberal arts education by analogy to software, and this is quite correct, but it is also more specific. A person with a well-described API will have learned enough about the basics of a wide variety of fields that they find it easy, indeed delightful, to collaborate with people from those fields. This means appreciating the core operational assumptions of a given discipline other than their own (“how engineers think,” “how historians think,” etc.) as well as the basic vocabularies and techniques of that field. If you want to collaborate effectively with an archaeologist, for example, you need to have some basic knowledge of how archaeologists do their work, which includes some idea of what a field survey is, the techniques of stratigraphy, the power and limits of radiocarbon-dating, etc.
Pedagogically, creating graduates with well-defined APIs is about teaching them how to constantly extend their own APIs to new fields and disciplines. This involves teaching them how quickly to get up to speed on a new field that perhaps they know nothing about. It means showing them how to ask good questions when they meet someone for the first time from a discipline they are unfamiliar with. More subtly, it also involves teaching them epistemic humility, that is, how to know what they don’t know. One must learn both fundamental respect for other people’s expertise, but also have enough skepticism and critical sensibility not to simply swallow the assumptions of those other fields wholesale. Finally, it also means developing a facility for explaining one’s own disciplinary expertise in ways that are accessible to people outside one’s own discipline. For it is only in this way that others can appreciate what you have to offer as an interdisciplinary collaborator.
A graduate with a well-described API will thus find themselves able to work with a wide range of different people, in many different sorts of professional settings, and will be able to constantly retool themselves as they move from one work setting to another. In short, they will be better teammates and have longer productive careers.