Archive for January, 2009

Multi-disciplinary Research: Knowing When To Shut Up

January 7, 2009

One of the touchstone issues for multi-disciplinary researchers is the difficulty of communication. Technical terminology from one discipline often has a completely different meaning in another; you only have to look at the word “model” to realise how fraught this can become.

The bulk of my experience is the interface between biologists and computer scientists, although I’ve also seen what happens when mathematicians, engineers, physicists and medics are thrown into the mix. To some extent, the wider ranger of disciplines involved, the sexier the research seems to be but it also becomes harder to make a case that each person is making a unique and useful contribution. Getting things working with two disciplines is hard enough.

The obvious necessary component when mixing disciplines is that each collaborator must be generous with their knowledge and be patient with “stupid” questions. This includes explaining those technical terms but has a bit more subtlety than that. Good collaborators also have a keen awareness of when something that might be obvious to them might be less obvious to somebody of a different discipline. Similarly, they will be aware of when something might be ambiguous or nuanced to the others in the room. Part of this is just good communication, but differences become more pronounced when there is a broader range of training and background.

In my recent meetings, I’ve noticed that another less obvious factor that is just as important in successful collaborations: knowing when to shut up. Multi-disciplinary projects contain the leaders in their respective fields and there is no way each person is going to absorb all the ins and outs of the other’s work in a few short meetings. Each side must be aware what the other needs to know, and hold back on everything else.

For highly trained academics, holding back can be much harder than holding forth. For me, I feel this might be an issue of ego and professional pride. If I’m going to spend the next year designing an all-singing all-dancing computer system, I don’t want that effort and expertise to go unrecognised; I want to tell everybody how clever I am.

To compound the problem computer scientists are notoriously excitable about interesting new problems, and they want to jump up and tell everybody all about how they’re going to solve them. I have been in collaborative meetings with an enthusiastic computer scientist at the white board drawing entity relationship diagrams while a medic made the “this is all over my head” gesture. In many cases, the biologists simply do not need to know how the code is going to work – they just want to know that it does.

Having said that, this problem is certainly not limited to computer scientists. Modern biologists spend all day dealing with the incredibly intricate and complex machinery of living cells operating at a dizzying array of physical and temporal scales. It would not be right for me to work on their data without understanding something of where it came from. This does not mean, however, that I need to know the exact protocol for a Northern Blot or have read the x seminal papers that lead to the discovery of Chromatin. At least not necessarily.

As always, we need the right amount of information to change hands. The computer scientist needs to know, specifically, what data is coming in and what data is going out. The biologists needs to know which bits are difficult and slow and which bits are easy, so that they can choose the right compromise for the final implementation.

The difficult part is the bit in the middle: the context. It can be a good deal easier to write analysis code if you know the source of the data and what it will be used for, because you can make informed decisions about error checking and boundary cases. It also provides excellent motivation – I work in biology because the problems seem a lot more worthwhile than finance or telecoms. Knowing how much context is useful is a difficult problem. I’ve certainly experienced context that was so far outside useful that I nearly made the “way over my head” gesture myself.

The good collaborator will know what the other person needs to know and will present the correct tip of the iceberg. An even better collaborator will, for the sake of their own ego, achieve this abstraction but still let the others know just how big the iceberg is. If you’re lucky, they’ll admire your skill in handling that amount of knowledge and your courtesy in hiding it from them.