Competing With Data & Analytics
What to Read Next
Amadeus is one of the world’s largest travel technology services, with thousands of clients in the travel industry. In 2013, it stepped up its game by creating an analytics-based travel intelligence unit that has hired more than 40 data scientists — a brand new position at the company.
Finding this kind of talent at a time when many companies would like just one or two data scientists presented an obvious challenge; Amadeus had to get creative. The company pulled some of its data scientists from its operations research group. The rest it hired from outside the company, taking advantage of ties it had with universities, especially in Europe.
But hiring was just the starting point of a process that integrated data science talent into the company’s organizational structure. MIT Sloan Management Review’s Michael Fitzgerald talked with Denis Arnaud, the company’s applied research senior manager, about the process.
Data scientist is a new job title at Amadeus. How did you change your interview process for it?
The process was not different now than what it was 10 years ago, for management and operations research for airlines. My hiring techniques have not changed a lot from 10 years ago. In fact, my feeling is, I always considered it an interview for a data scientist, even though that was not the title.
What sorts of questions are useful to identify the type of candidates the company wanted to hire?
I’m part of the hiring team. Candidates go through five interviews. I’m just one of those! I am an important one, because they will belong to my team.
Because I know that the candidates will be interviewed by other people, I do not view an interview in the classical way.
How do you mean?
Typically an interview with me would last a minimum of four hours, and it could go to eight hours. I am the main speaker. My goal, when I do the interview, is that the candidate is as aware as possible of what will be their daily job, to get the exact feeling of what they will have to do.
I use a lot of examples. And I show them how to dig through data uniques, and it’s a conversation. I ask a lot of technical questions and a lot of functional questions.
To give you a concrete example, we have to deliver data on departures and arrivals to customers anywhere in the world, and any airline would be able to check that the figures we show correspond to what they know. We produce, every month, millions and millions of figures — like the number of passengers who flew between Manila and Jakarta.
My question will be simple: Tomorrow you’re going to work for us, and you will be responsible for the production of that data. How can you be sure that it is accurate enough for every combination for every customer possible?
I ask open questions. So the candidate can ask things, and I try to help them. I just want to see how they think, how they can react. For example: could you tell me how many passengers travel in the world? Or the typical traffic from North America to Europe? The weight of an aircraft? I might ask a code for a New York airport, or for LA, and so on. I want to see, okay, if they don’t know, what do they think, and how would they search for that information?
Most people don’t know the weight of an aircraft. A good answer would be, “I don’t know the weight of an aircraft. I know the weight of a car is, I think, two [metric] tons, 2,000 kilograms. Now a train is something like 20 tons, and then an aircraft could be 100 cars, so it should be along the line of 500 tons.” Just to see that they know they need to compare with something. If they just give an answer, it’s probably wrong. If they tell me the weight of an aircraft, it’s wrong.
For the number of passengers in the world, I figure some people would do a bottom-up and others will do a top-down. Bottom up would be, an aircraft can carry 300 passengers and how many aircraft are there and then do the multiplication. That’s wrong. They would multiply errors by errors. The right approach would be to ask, what is the world population? Seven billion. And then do an assumption of one trip or half a trip per human being in the world. That would be the right assumption.
What I want to detect is whether they are good or not in orders of magnitudes. It’s really a scientific approach. I want them to be proactive and see if their assumptions are good.
What pool did you draw from?
Our goal was to hire around 20 people, because we’d probably get 20 [from] internal [sources]. To build a full team from scratch in Madrid, I thought we’d need three or four additional years to have a functional, operational team. My concern was the amount of time it would take. In fact, it worked, the team was operational much quicker than that.
Why was it quicker?
It will take three to four years to get the full picture of the job and be autonomous in any subject we need. But they are subject-limited. On the technology side they are okay; on the functional side, you need a few years to learn. I think in the past, we were in the operational and innovation units, which were more insulated from the rest of the company. We struggled to have more integrated teams. I always wanted to hire people who are sociable enough to interact with product managers, with sales and account managers and so on.
It’s very important to have a network within the company, and I insist on everyone to build that internal network. Go play soccer with people, go out in the evening, sports, swimming, running, whatever, so they know each other and know the relationship and it’s easier to interact — and when they have questions on technical or functional details, they can go and ask colleagues.
What steps did Amadeus take to put teams together? How did it monitor their cohesion?
I organized the teams, or let them organize themselves, because I have teams spread in different countries. It’s very important that they work well together, so they feel a part of the same group. We have a data science forum that occurs every month or month and a half, and lasts for two to three days. We gather and exchange information on various subjects. I like them to share their experiences and work together on some specific subject.
We invite people from other groups within Amadeus, so they know that they are part of a bigger company and [learn] their point of contact in an area. Then, every three to six months, we have a workshop, a similar event, where people from other business units explain what they do, and so it’s a way to give the bigger picture. We also have events where we get together and work on group cohesion, put the solutions engineers with the data scientists for a couple of hours. And we have some outings — so we have some ways in which we can know each other better.
How do you monitor them?
We watch to make sure what is expected to be delivered is delivered. People are proactive; in fact, if anything goes wrong, they would tell us right away. I insist on a lot of transparency and honesty. It’s democratic, as well. We have tasks, projects, and everyone gets together and [concludes], we must do that for this customer. People pick things corresponding to their preferences and competency. Of course, at the end there are always tasks remaining.
Communications between analytics and business line executives is emerging as a problem. Were there communication gaps between the data scientists and the other team members?
When I hire data scientists, one of the first things I tell them is what Pascal Clement told us during our first workshop: he said, “The sales team should love you, and you should do everything you can do so the sales team loves you. If they don’t love you, we have a big issue — they will not sell your product.” I trust their intelligence to do whatever they can so the sales team loves them. It’s part of the hiring process that they have to be able to explain things to sales.
Still, it happens from time to time. When we do the three-day workshops all together, we can take care of matters. We are all together in a space and we interact, we have eye contact, we say hello and drink coffee together. Everyone see everyone and has opportunities to change and so on. That limits the risk of communications gap. But not everyone fits with everyone.
The good news is, our job is really easy to explain even to 5-year-old kids. We calculate the number of passengers traveling in the world; it’s easy to explain. Anyone can understand that. If we have to repeat it and repeat it and after 10 repetitions, the sales team doesn’t get it, we have to change the way we explain it.
What advice would you give to other people hiring data scientists?
It is very important that your people are good enough technologically and functionally. You have to have the energy and passion to dig through all the technology stuff, do some dirty work in the data. If you don’t care about the data, you will not bring enough quality to your work. But you have to also be passionate about the overall objective. Technology is not the end of the game!