How to work with other disciplines and remain productive.
Multi-disciplinary collaboration does not need to be as hard as it seems.
Hunched over a desk in a 19th century lecture hall, the daughter of Lord Byron, Ada Lovelace was busy translating Charles Babbage’s lectures on analytical machines.
She saw the beauty in his technical concepts and wanted to transmit that beauty to others.
Trying to explain how analytical machines could be used, she wrote down an algorithm and that algorithm is now considered to be the first computer program (1).
So, here it was, the first piece of code, written by the daughter of a poet who was essentially trying to describe the beauty of a technical piece of work.
Software engineering was thus born out of a multi-disciplinary effort.
And it began not with a concept, strategy or a plan.
It began with a prototype.
Multi-disciplinary collaboration: the best practice you love to hate.
There is no shortage of people lauding the value of multi-disciplinary efforts in research and innovation, but in practice, integrating the thinking of different disciplines is difficult.
In fact, many just walk away from the challenge. They hand off what they have done and hope that the other discipline knows what to do.
This was the suboptimal approach we used in one of the earliest projects that I supported.
Its all about relevance.
We needed to integrate the perspective of computational modelers with the perspectives of biologists and clinicians.
It was mid-project and we were having a face-to-face meeting. The lead of modeling work package stood up, enthusiastic. They had a model and it linked to both biology and a clinical setting.
Indeed, they had done a nice piece of work validating the computational modeling with the scientific literature and in vitro experiments. But what they did not have was quickly pointed out by one of the clinicians.
Clinical relevance.
What they had modeled was hardly useful. It could not be used for helping to make clinical decisions.
It was not that the two groups had not talked, they had. It’s just that they were not clear about what each other was saying.
The way to communicate between disciplines
In another more recent consortium project, during the first online meeting, less than one week into the official start of the project, the partners had already met in smaller groups several times including a meeting between the data management work package and a clinical study work package.
The lead of the clinical study work package pointed out that after an all-day meeting she appreciated that the data scientists and the clinical scientists were speaking a different language.
There was also a gap in expectations.
Some of the technology developers wanted to make an app that was capturing unique types of data from the start.
The clinical study experts just wanted it to help capture the surveys they needed for the study and did not want to go through the delay of waiting for the novel measures of physical activity to be brought online.
The elegant solution was to work in an iterative manner, producing early more practical versions of both the data management and the data capture app.
This helps the clinicians understand what the data scientists need and the data scientists to know what is clinically relevant.
Simple terms like data model are a foreign language to a clinical researcher. For data scientists, it’s difficult to know which of the myriad of clinical measurements is clinically relevant.
It also helps the technology developers build an innovative piece of technology that is grounded in being useful to those who will use it.
Prototyping to the rescue.
Iterative cycling is one of the principles of highly interactive consortia I describe in Assembled Chaos.
A prototype or a minimal viable product is a great way to communicate between different disciplines who are speaking a different language.
A prototype or first iteration is also valuable for communicating and engaging stakeholders such such as patient stakeholders.
Being able to see what others are thinking moves us immediately beyond underlying assumptions and beliefs.
A prototype is also an invitation to ask questions, and questions are like Spring rain that brings out the worms that make the soil of people’s thinking fertile.
I now know that the rapid cycling of prototypes is a powerful approach to consortium project interaction.
Making the impossible possible
Being able to communicate between disciplines is one of the most powerful skills you can possess, and that is because it can make the impossible possible, or even feasible.
“It points toward something that is often forgotten, that what many people call ‘impossible’ may actually only be a limitation of imagination that can be overcome by better design thinking.”
Buchanan and his co-authors point out that for complex multi-stakeholder problems, often a sense that particular outcome or goal is impossible is simply due to not looking at the problem from different perspectives.
So, solving the problem of getting multiple disciplines to work together is much more than an improvement in operational efficiency, it is major determinant of how much you achieve in complex research and innovation projects.
Takeaway
Don't wait to show a polished output to a multi-disciplinary group.
Iterate as soon as possible.
Create a prototype which can be a drawing, a graph or even just a draft.
It is important to do this early while things are still rough.
Then just repeat as many times as needed.
I am building a free email course on how to identify grant funding opportunities for both EU and US medical researchers.
If you are interested comment below and let me know your biggest frustration with identifying new funding opportunities.
References
The Innovators, Walter Isaacson, Simon and Schuster
Buchanan, R. (1992). Wicked problems in design thinking. Design Issues, 8(2), 5-21.