From code to client: insights from a data scientist’s intriguing journey


Lea Helmers joined idalab as a data scientist in early 2016. With degrees in Mathematics, Computer Science and Linguistics, she was destined to specialize in Natural Language Processing (NLP). Her three-year journey at idalab has been a powerful testament of the data scientist’s potential to maximize value for clients by combining data science tools with strategic and conceptual thinking. We asked Lea about how this evolution took place, and how she’s coped with it on a personal level.

Good morning Lea. Thanks for joining us first thing on a Monday.

My pleasure.

Maybe you can start by talking a bit about your background and how you ended up joining idalab.

Well, I studied mathematics and linguistics as an undergrad. When I first heard of Natural Language Processing (NLP), I just couldn’t believe that computers can capture the complexity of human language. So I had to learn more, and that’s what led me to an MSc in Computer Science, where I also developed a strong interest in Machine Learning.

And in terms of my work, I knew I had to do something meaningful to be driven and excited. When I was invited to meet the idalab team, I knew it was the right place for me, since a lot of work was being done for biotech clients. So it all worked out perfectly in the end.

Lea Helmers: ‘The environment was very dynamic, totally different from what I’d imagined – people sitting on their computers writing code’

At that point, you had no previous experience working for a data science consulting agency. Was there anything that struck you about our work?

Very good question. I took a peek through the curtains, so to speak, when I came to the office for my first interview. I realized that people were moving around from room to room, going on calls with clients, having intense discussions. The environment was very dynamic, totally different from what I imagined at first – people sitting on their computers and writing code. When I started working, it didn’t take long for me to confirm my observation. I immediately jumped into client calls myself, had one-on-one sessions with Paul, our Managing Director, and had to adapt to working in a fast-paced environment. It definitely took some time to get used to, but after a few months, it became part of my daily routine. And now, I can’t even imagine working in a role that doesn’t give me that level of exposure and personal responsibility.

And what were you working on when you started?

I’ve always focused on biotech and healthcare, though I’ve also worked on other projects. For the first six or so months, I was doing the kind of work I had expected to do as a data scientist. I mainly wrote code, analyzed data, and implemented models. It was all very execution-oriented. I certainly wouldn’t say it was mechanical work – far from it. I still had to think strategically and creatively. But nonetheless, I was mostly in front of the computer and not so close to clients. But all of that changed soon after.

How so?

Over time, I started noticing the different things that go into the execution of a successful project. It dawned on me that writing code isn’t a black box that can miraculously solve client problems. I saw that other things are actually far more important for overall success. Focusing on the people involved in a project, especially from the client side, is crucial. And by observing my colleagues, I learned that flexibility in communication is key, since everyone is different in terms of personality. Good communication not only creates a positive working relationship with clients, it also opens opportunities for us to understand their problems and elicit their knowledge to create solutions.

But what does establishing close ties have to do with understanding problems?

A lot! Client needs are always ambiguous and vaguely defined at the beginning. The client may have confidence in where he or she wants to get to long-term, but oftentimes this is more of an intuition rather than a clear vision. My job is to dig below the surface and figure out what innovation really means for the client on a practical level. And to do that, a close relationship is key. For example, I often need to navigate the painful situation of revisiting the same question over and over again until I get the answers I need. This can make the client uncomfortable if he or she doesn’t see the relevance of the question. A good relationship can ward off this feeling and incline the client to say more.

And let’s not forget: the heart is as important as the mind, if not more. So a potential solution strategy that is “optimal” in a technical sense but fails to generate enthusiasm is never going to be put into action by clients. At the end of the day, they’re human. As cliche as it sounds, winning hearts and minds is what it’s all about, even in the field of AI.

Very interesting. And how did this observation change your own work?

Before I answer, I should mention something about the end user – in the case of biotech and healthcare projects, the patient or the person who suffers from an illness. In addition to people on the client side, it’s equally essential to envision how our solutions will improve the life of the end user. All of this entails a type of big-picture strategic thinking that requires strong conceptual thinking, knowledge of business processes, and good-old people skills.

So to answer your question, these observations completely turned the tables for me. Instead of just writing code, I became much more interested in broader questions that I personally find very exciting.

Such as?

What’s the real nature of the problem or need from the client side? How will the end user’s life improve with the expected solution? Is the terminology used to describe a situation confusing? If so, how can it be made more accurate? What sort of knowledge do I need to elicit from clients, and how can I convince them that this is a necessary step in creating a solution? How can I create traction within an organisation? These are just a sample – there’s many more questions to ask.

Incidentally, all of these observations really came together during a big healthcare project. I visited the client’s clinic with Erik Schumacher, and saw first hand the complexities of the client’s business. I talked to employees and patients. I was given a tour of the infrastructure. Most importantly, I saw, for the first time, how our solutions can truly impact the lives of patients. That was the eureka moment. I remember being taken away by the thought that in a year’s time, these same patients would be healthier and happier. The real meaning of my work was kind of handed to me on a plate. And I knew that to truly make the kind of change I was imagining, I needed to spend less time on the computer and more time with clients – and, of course, in my own head.

That’s fascinating. It makes sense that your experience in the context of healthcare would bring forth those feelings. Can you pick up on how your work changed in more detail?

Well, first of all, I knew I had to go back to school, but this time I’d be my own teacher. I had to learn more about my client’s industry and any relevant science I needed to pick up on the way. That meant reading books and academic articles on drug discovery and development, biology, chemistry, and new modeling approaches.

Apart from that, my day to day work became more heavily client-focused. And I would divide this into three categories. First, I started communicating my findings and thought processes to clients more clearly, spending a lot of time on honing the message. Second, I focused more heavily on synthesizing the client’s subject matter expertise, what you might call “knowledge extraction”, though that makes it sound mechanical, which it is certainly not. And finally, I had to plan and manage my own work much more carefully, because there are so many tactical and strategic issues to consider when running a project. If I compare my work at the start of my time here to my work at present, there’s a world of a difference.

The idea of embedding the client’s knowledge in the end solution is very interesting, and something people don’t pay enough attention to. Why is it important, and what are some of its challenges?

Developing AI solutions means building models based on the client’s subject matter expertise. For example, if I want to find proteins involved in disease pathways using NLP, I need the relevant scientist’s input on which proteins are important and what sorts of relationships they have to other biological entities. Without this knowledge, we can only take shots in the dark.

So the first task in knowledge synthesis is to identify who’s who in the client’s organization. Who are the different people involved in the project and what sort of relevant expertise do they have? Who are the subject matter experts, who are stakeholders and ultime decision makers, and what political undercurrents are at work? These are the questions I ask myself.

The next step is to communicate with the relevant expert to elicit his or her knowledge. But this can be really tough. The client is typically not used to communicating this knowledge, because it may be too obvious, or because they believe the service provider has all the answers – perhaps even buying into the myth of AI being a silver bullet technology.

The other problem we’ve touched on as well. Every person has their way of communicating, as well as their own level of trust in outsiders. My job is to understand the client and tailor my communication accordingly, building trust over time and convincing them that their knowledge is extremely important. A case in point is a biotech client we worked with closely. Their Chief Scientific Officer had doubts about our approach. Over time, she saw that her domain knowledge, in combination with our expertise in data science, pays dividends in the long run.

Of course, there’s other, more subtle ways of synthesizing expert knowledge. Slide decks, for instance, typically generate multiple feedback loops and slowly bring forth knowledge that was previously hidden. But workshops are important too. Getting experts together in one room and being able to exchange knowledge in a constructive way is extremely valuable.

Earlier, you were saying that your work requires big-picture thinking. What does this entail in addition to establishing strong ties with clients?

To clear any possible confusion, I should say that the client and end-user are important, but without strategic thinking and conceptual rigor, you can’t create outstanding value for the client.

In my view, strategic and conceptual thinking are two distinct processes, yet inevitably come together in the execution of successful projects. Strategic thinking is more akin to a bird’s-eye view, big-picture landscaping process that requires a thorough understanding of the client’s needs, business, and industry. For instance, I recently worked on a client project in the field of drug discovery. In a sense, the client’s request was simple and well-defined – find proteins involved in disease pathways. As the go-to NLP specialist, my job was to write appropriate code that would scan millions of scientific papers with the goal of finding these proteins.

If I had approached the problem myopically and focused exclusively on the client’s request, the project would have failed. The first thing I had to do was think of the complex environment the client operates in, namely the pharmaceutical industry. Who are the client’s competitors? Has their approach enabled them to move down the drug discovery pipeline? This meant looking closely at the competition and thinking of what can be done differently in the case of our client.

I also had to understand who’s who on the client side. Who is the subject matter expert and where is knowledge distributed in the company?

And of course, my goal was to create a solution that the client can intuitively grasp and iteratively use down the line. So how should I write my piece of code to achieve this goal?

Again, this is just a glimpse into the enormous body of questions one has to think of from the get-go.

And what about conceptual thinking?

Oh, thanks for reminding me. So strategic thinking is about understanding client needs and maximizing value for the client. Conceptual thinking is about using logic and analytical thinking skills to structure, simplify, and synthesize knowledge.

As an example, establishing an initial taxonomy is tricky work that requires a very subtle ability to differentiate and draw distinctions. If you’re not careful at this stage, you may end up lumping terms together that don’t belong in the same category, or make distinctions where in reality there are none.

A related point can be made about terminology. For the sake of clarity and simplicity, we need to build a common language that we share with the client in conversations and slide decks. If you’re not attentive, vague and fuzzy terminology will seriously hurt you down the line. So we need to be armed with a high level of attention, and the ability to use logic, reason, and sometimes intuition to make distinctions.

Wow! That sounds tough!

It is. But it would be boring otherwise.

True. Well, we’ve taken a lot of your time already this Monday morning. Can you maybe end the conversation with what draws you to this work, and how you’d like to see it evolve in the future?

At the risk of sounding cliche, it’s all about people. If it wasn’t for the average patient or end user, my work would be empty of meaning. Once I saw this first hand, I immediately grasped the true value of my work. And I haven’t turned back ever since.

In terms of the future, it’s hard to say, because I’m genuinely happy about what I’m currently doing. But if I think of it, I’d love to be in a position where I can put my imagination to work and turn my own vision into reality. I can do that now, to some extent. But to be able to do it fully, I’d have to take up more responsibility and work on a project end-to-end.

But I’m not worried. The day will come.

We certainly hope so. Thank you for your time, Lea.

Thank you!


Hannah Martin


+49 (0) 174 27 18 138


Potsdamer Straße 68
10785 Berlin