I started off as a developer and architect, then became a program manager, department manager, IT organization manager, and finally head of analytics as a hired executive and as part of consulting companies. In these roles, I’ve hired various profiles of people, including data scientists. My teams, generally speaking, do the heavy lifting “industrial” work, the global, enterprise-scale work that companies need to run effectively, to find new markets and adjacent businesses and so forth.

My journey with data really started in 1998, when it was still called reporting and business intelligence. At that point I was primarily working with SAP tools and in SAP, everything is centered around a business domain like logistics, finance, material management, supply chain and so forth. I could see that my successful implementations were the ones where I had functional or domain knowledge, and the not-so-successful ones had strong technical teams but with less knowledge of what things meant from a business perspective. So, around the year 2000 I started to assemble teams with leads in the relevant domains, functions or processes, who also understood data. I aligned these people with others who implemented the process. And secondly, they would add the data domain to this. I built on this, adding more analysts to my teams and started to introduce analytics services.

Starting from around 2016, the analysts slowly became domain scientists. And even if they formally weren’t data scientists, they had strong mathematical backgrounds and were able to use the tools. So, it was a natural progression of the idea of having functionally oriented leaders leading teams of developers. So many implementations fail because they are totally technology driven. The people know the technology and data inside out, but not how to assemble it in a way that makes sense to the business partners. The next step, which we began working on since 2019, is how to translate this to an organizational setup. Because scale has now become an important question. How do we set up a federated organization with pockets in the business and think about scalable self-service, so that we can deliver speed? So, my journey was perhaps a reaction to learning in the beginning. And then it was a concentrated effort to scale up the skills of the functional or domain scientists.

It’s very important to know the domain one is working in. I use the term “domain scientist” to emphasize this. When I speak to data scientists about what makes them successful, I find that the mathematics and tools are secondarily important because these are so easy to pick up today. In my area, there’s not a lot of requirement for programming in Python or R because one uses tools that are basically, for lack of a better word, a data science workbench.

So, it’s more important to understand what the industry needs. For example, with one major cosmetics brand, our domain scientist understood that he could use algorithms to identify influencers. If he had only known algorithms, he would have had no idea how important influencers are in that industry. My recommendation to data scientists outside of hardcore autonomous driving or active safety and so forth, is that they come with good domain knowledge.

I would first look to see whether a data scientist has knowledge about the domain. Next would be knowledge about modern tools that use mathematical algorithms in the background. And then R and Python would be a plus.

The other thing I like to say is that nobody comes out of this business smelling like roses. It’s because there’s more failure—let’s call it test-and-learn—and adaption. And that’s why I believe following an agile approach is very good because you can test and learn and adapt, rather than trying to define everything for three years down the road, when the world has anyway changed by that point in time.

For me, it always has been the opportunity for organizational change. The second aspect is building teams. And the third one is connecting the dots. Whenever my children ask me what I do, I say that I am in the business of connecting dots. There are knowledge islands in organizations and my teams connect them. It’s important to find the right mix of team members, be it the data scientists, developers, the visualization expert or most importantly, the people who deliver change.

With analytics, you can deliver all the insights for data-driven decisions you want. But if people don’t use them, you don’t get any benefits. So, the organizational change component is the ultimate satisfaction for me. For example, it is a matter of great personal satisfaction that we were able to save a major pharmaceutical client $4 billion in working capital per year by bringing in some domain solutions, including one warehouse domain solution around contract compliance and profitability.

With analytics, you can deliver all the insights for data-driven decisions you want. But if people don’t use them, you don’t get any benefits. So, the organizational change component is the ultimate satisfaction for me. For example, it is a matter of great personal satisfaction that we were able to save a major pharmaceutical client $4 billion in working capital per year by bringing in some domain solutions, including one warehouse domain solution around contract compliance and profitability.

One, which in my mind is the hardest at the moment, is that we are at a major change in terms of technologies. So, the general analyst becomes the domain scientist. Either people make that jump or, most likely, they won’t. A career in data is always something where you have to fight resistance. People don’t want to change.

When you look at data at the enterprise scale, one has to have a common minimum understanding of what it means. But this is really difficult and it’s very easy for things to fall apart. So, this is the area that I would say we fail the most, or where we seldom reach a sustainable goal. I must believe that for the Facebooks, Amazons, and Googles of the world that’s second-nature. Their product is data. But for more classical industrial companies, their product is a car. It’s a product of steel or whatever and data is new for them.This is the area with the most opportunities, but sometimes the message the data brings can be quite difficult to hear.

The biggest fear I have is that I will clone myself. So, I never conduct interviews. Instead, I give the sales pitch, and I have other people conduct the interviews. I don’t need myself, I need others who compliment me and work much better than I do. We may think we need one skill or another, but generally people can adjust to that. It’s really the cultural component. For me it’s all about the balance of leaders, supporters, and motivators. Diversity of cultures, diversity of everything is very important because it’s easy to be blinded by one’s own experience. And it’s very good to get different reflections and points of view and pushback.

Secondly, having attended so many interviews, I know I can adjust to almost any kind of interview very well. I can generally get hired, but that doesn’t mean I can do the job. So, from my perspective, it’s very important to get recommendations from people in the network. It’s not that I want to hire friends of friends. But I like to understand in my network, if there’s somebody who fits the bill.

What I look for is the person having worked for several companies. I have trouble looking at somebody who’s been with one company for 20 years. Alternatively, they should have increasing roles and responsibilities within one company, so I know they have done many different things. If they have done many different things, they can not only bring one recipe, but maybe 10 variations of that recipe.

Next, since I mainly deal with transformations, I see if they have been part of transformations. Because that tells you a little bit about their energy for going through difficult paths. Third, there is domain competence. Are they good at what they’re doing? Fourth has to do with the cultural side. What culture do they bring to the mix? Does that fit in right?

Finally, I have about 30 seconds to find these things in a person’s resume. So, the structure of the resume is super important, so that it entices me to read it a second time.

What I interview for is cultural fit. I make a sales pitch for the job and try to read between the lines whether the person is truly interested in that kind of work. So, I test them for ideas about transformation. Or I might ask them about a difficult situation where they had to manage ambiguities. If I hear that they just did what people told them to do, I would know they weren’t the right person. But if somebody talks about how they used different working styles in different cultures, I would take notice. Finally, if I recognize that they can replace me at any point in time, then I’m very interested in them. Because as a good manager, you have to have a team that is able to replace you, or you can never move on.

I would say understand the job requirements, domain and tune your answers accordingly. So, let’s say we’re talking about Industry 4.0, talking about your consumer experience is of limited value. However, if you can apply certain aspects of that consumer experience to preventive maintenance, for instance, that’s important.

I also try to coach people to answer with relevance and to the point. For me, I’m what is called the reforming director. So, I’m ok if you have some high-level ideas and some clear explanations that support the idea. So, I would say try to read the personality of the person who interviews you. There are people who want to understand detail and there are people like me.

I also use these interviews as education. At a previous firm, when we were hiring a whole new team in Dublin, I had to ask people about infrastructure and networks. I asked them to explain to me how I could effectively move something from the edge to a data lake or to a Glacier. I may not know all the technical details, but I can understand the logic of the argument. And whether that person can sell the idea to a person like me, who has to go get the funds for it.

Finally, don’t be afraid to talk about failures. Nobody who comes to an important level has all good projects behind them. People make mistakes, especially if they are in the business of transformation. When you talk about a failure and what you learnt, that helps me understand that you won’t repeat this failure in my shop.

Let’s say they are data scientists coming from the university, and they have learnt a bit of finance or some other subjects on the periphery. I think they should figure out what their domain of interest is. Or, perhaps they could go through a rotation of a few domains, a domain a quarter, to find their way. Then, they should dive deeper into that one domain.

Second, they should not be afraid to be hands on. That doesn’t necessarily mean that I want to make developers out of them. But in my area, if we are talking about doing something on an industrial scale, it’s different when one talks theoretically about this. One has a very different authority when they can say, “I’ve done something like this before,” and can quickly demonstrate it. This kind of agility is what I would look for from somebody coming from the university.

I can give you my own example. I was very bad in school and I had a degree that did not allow me to go to university. So, I ended up in the military, where I got my bearings. Then, I attended summer sessions at Harvard and at Stanford, and went to the University of Massachusetts for my master’s degree. My first hiring manager called me in for the interview just to figure out how a little German soldier ended up at UMass.

So, do something that stands out. Don’t do what a million other data scientists do. Find something that is different, so that when a manager reads through your resume, he sees something interesting and unexpected. Because people who do that, they have guts, are not afraid of the unknown, are learning or willing to learn, and stretch into areas they don’t like. Often, people who go through a normal career, a textbook career, they fall the moment the wind blows differently because they are not used to failure, difficult things, or if the world is not the way they think it is.

What I tell people is that I cannot guarantee that we will be successful in all our projects, but all of them will have a higher market value because we are doing very interesting, difficult things. I can guarantee that they will learn, become better specialists, will have solved unique problems, or may not solve them but will have learned new ways of how to think of them in the future, which will make them more successful.

When you look at the functional scope, we own everything from the output of R&D data all the way to classical enterprise data. So, we get to think with truly end-to-end company data. And that is very unique.