With the pace of scientific and technological progress accelerating, the role of the translator of complex scientific content for use by a wider population is becoming more important. Often, the translator is not an expert and must gain knowledge rapidly first to have meaningful conversations with experts, and then simplify that knowledge for consumption by a less advanced audience. You might be a science journalist writing for a lay audience, or a CEO of a biotech company engaging with scientists first, and then conveying the potential of a medicine to venture capitalists, or a marketing professional in a technology company creating a campaign for end users. At Insight Dojo, we do a lot of work in complex scientific areas – different medical conditions, new technologies, and industrial products. Being a translator is an essential part of our work. Last year, we finished an exhilarating project on genomics where we interviewed cutting edge scientists with highly varied use cases – for instance, one identified mutational signatures for cancer, another ran Bayesian genetic association models for rare diseases, another ran machine learning algorithms to identify patients at risk (we didn’t know the meaning of a few of these terms before the project which is partly why I’m writing this blog). Our task was to understand how these varied goals translated to requirements for data, analytical tools, software, and other IT system level features, and communicate these to our clients. The challenge for us was to take in all the complexity of the field and simplify it without losing nuance whilst presenting our insights.

 

It is worth emphasising that this form of learning where the purpose is to understand a scientific field better without trying to build one’s own expertise is quite distinct from typical expertise building programmes. An analogous situation is immersing oneself in a genre of music to listen better and understand the world of musicians of that genre, rather than attempting to be a musician oneself. Developing expertise in any discipline is inherently a sequential and slow process where one needs to master basics before proceeding further to advanced concepts. The type of learning I’m writing about is less rigorous, fast, and non-linear with the learner grappling with a set of both basic and advanced concepts with the ultimate objective of building a bridge between experts and non-experts. Even with big gaps and blind spots in acquiring such knowledge, it is highly valuable in today’s context. Consider the vast number of business leaders who might not have hands-on experience of running or interpreting a linear regression model, and yet by studying and engaging with experts, they can draw insightful implications on the impact of machine learning on their industries and fuel innovation. (For simplicity, I have used the terms, experts and non-experts, whilst in reality there is a full spectrum of profiles including people who are intimidatingly deep in a field, and yet consider themselves generalists)

 

In this blog, I want to offer suggestions on how one might approach this endeavour to be a good translator systematically, even as the learning process is likely to be somewhat chaotic. Although, the context for this blog is developing insights to solve real world problems, hopefully, the lessons are applicable more broadly.

 

1. Being agile, curious, and gritty: Diving into a field in which you are a novice needs a high degree of intellectual agility. Loving learning makes the process easy. Curiosity provides the inspiration and energy, and the constant receptivity needed to internalise new information. You need grit to persevere through the difficulties, the periods of confusion, and the feeling of getting stuck. Grit also provides the courage and humility to ask novice questions repeatedly. I feel inspired by the Insight Dojo team that role models this mindset. As a company, we are very optimistic about everybody’s ability to grasp complex topics if they are willing to cultivate such a mindset.
 

2. Planning time for learning: In the initial years of Insight Dojo, I was hesitant about allocating and billing clients extra time in a project for learning. We used to cram all the learning during late nights and weekends, and often even before a project began. But, over the years, I realised that clients value the diligence, pattern recognition, and creativity that we bring as insights professionals to projects, and appreciate the need for us to learn the subject matter.
 

3. Being rooted in the context to define the boundaries of knowledge: In the real world, relevant knowledge is highly context-specific, messy, and often at the intersection of many disciplines. It is unlikely to be found neatly organised in textbooks. You don’t know what you don’t know. It is easy to get lost in topics that may not be so relevant, and conversely have a blind spot with respect to something critical. For instance, in the project on genomics, our initial assumption was that the most relevant subject matter was related to molecular biology.  Pretty soon, we realised that there were two other equally critical disciplines, bioinformatics and cloud computing, and we had to change our learning agenda. To determine what is relevant, we recommend immersing in the context of the project. For us that translates to grounding oneself in the environment of the client. We talk to internal experts, understand the product, learn about competitors, read manuals, research papers, and other documents. Having internal expert mentors is really helpful. We are always grateful to the scientists amongst our clients who generously devote time to coach us. Another valuable practice is walking in the shoes of the customer.  Reading market research reports with end-customers, observing customer demos, and trying the product oneself, when possible, are methods that have worked well for us. With that as a starting point one must zoom out and use a wider range of sources – talking to other external experts, reading scientific publications, text books, and using online sources including attending short courses.
 

4. Testing knowledge by getting it out of one’s head: When you are rapidly trying to learn something new, it is very easy to have an illusion of understanding. One helpful practice is to externalise the knowledge by doing the things listed below:

• Get all one’s learnings on a physical medium and organise it on a communal site e.g. share all presentations, hand-written notes, drawings, excel sheets, interview recordings on a cloud based system.

• Map various ideas and the connections, and how they might impact customer experience.

• Take turns in explaining concepts to each other in the team.

• Have question and answer sessions.

• Periodically check in with internal experts.

 

5. Being like a performance artist whilst interviewing expert customers:  The interaction with the expert customers is an important determinant of the quality of the project. This is where all the knowledge is put to test. However, at this stage one must draw inspiration from performance artists like musicians and actors who rehearse a lot, and then attempt to be completely present at the time of performance.  Having done the knowledge gathering, one must allow it to settle in the background, and be completely focused on understanding the expert’s perspective. Given below are a few suggestions to implement this in practice:

• Get into an approach mindset before the interview: You need to be excited about discovering the fascinating new world of the expert. Do whatever it takes to get you there – go for a run, meditate, listen to music. 

• Don’t judge yourself whilst asking seemingly simple questions. If you don’t understand something, ask to clarify: A client recently told us that at first they had assumed that we were asking questions to which the answers were already obvious, and then later were surprised to find that their assumptions were completely wrong. Their lesson was that they should ask many more questions in their own interactions with customers.

• Probe experts on how they make decisions in real situations: To inject fresh thinking and get contextually relevant knowledge in an interview it is important is ask experts how they make decisions in actual practice. This could be done by asking about a past situation, e.g., asking a doctor about a patient they found difficult to manage, or by asking them to react to a hypothetical, yet realistic scenario, e.g., asking a doctor how they would treat a specific type of patient. 

• Don’t frame questions to confirm or display your knowledge: Naïve interviewers often think that their task is to impress the expert customer or an observing client with their knowledge, and are quick to offer their own explanations and hypotheses for confirmation. This type of behaviour blocks insight. That said, it is important to cue your level of knowledge to the interviewee. If the expert thinks you are a complete novice, then the responses will be unnecessarily dumbed down.

• Go with the flow when the expert seems to be deviating from the planned structure of the interview: These unplanned digressions might be sources of new breakthrough insights. 

• Be comfortable with not understanding everything: Often you won’t follow everything that an expert says. It is important to accept the ambiguity and keep the conversation going. One can listen to the interview later, and research the ideas that one didn’t understand. Often these sections are most revealing.  
   

6. Simplifying complexity by progressive abstraction: Having built a rich dataset by completing the customer interviews, the task is to develop insights. Abstraction is at the heart of reducing complexity and developing solutions in different situations – an insightful segmentation of users, a branding framework, an elegant proof of a mathematics theorem, or three lines of code that replace twenty. We like to use this drawing of Picasso’s Bull for inspiration as a visual representation of the process of abstraction (Read about this in the art of insight). The idea is to start with the rich details and then strip away layers iteratively to arrive at something simple, insightful, and useful. This is a rigorous exercise and very different from top-down problem solving processes that attempt to jump straight to a simple solution.