How to build a data science team

There are good reasons to google the phrase “Data science is a team sport” make appear so numerous entries. The skills required of a data scientist are so varied that it would be nearly impossible to find them in one person.

And even if you could find someone who embodies all of these qualities, you’ll probably have to pay top dollar for it. But suppose you’re not in a big market like North America, and your search becomes even more impossible. This was the challenge facing Vodafone NZ (New Zealand) when he was Head of Data Analytics and Strategy David Bloch had to build a data science team. He presented his saga in front of the Teradata Partners conference this week.

In a country of less than 5 million people, it’s no surprise that the national telecom provider is probably the one with the largest Hadoop cluster and the most ambitious big data analytics program in town. According to Bloch, the traditional HR approach of finding specialists with years of experience just wouldn’t work when you’re in a small market. “They would probably filter who you want to talk to,” Bloch said.

Instead, he called for adopting a startup mentality, combining events like meetups and hackathons for people whose interest and enthusiasm outweighed their actual experience. Instead of traditional interviews, a more informal process was the best way to find these people. Bloch had a good idea of ​​what he was talking about given his experience with several data-related startups before joining Vodafone.

Bloch has defined a series of roles to fill its data science team, encompassing engineers, hackers, analysts, statisticians, storytellers and change agents. Roles were not necessarily mapped to individual positions; for example, the analyst and the change agent, or the hacker and the engineer, can be the same person.

Specifically, the engineer is the “automation wizard” of the team. As someone with DBA or ETL experience, this is the person who works with the hacker to create data streams and ensure that technically the trains are running on time. In many teams this would be called the Data Engineer. The hacker is the R or Python developer who builds the approximate model, even if they don’t necessarily understand the science behind the model. The latter is the job of the statistician, the deep thinker who possesses the scientific method of identifying and validating patterns. He’s probably the person most likely to have “data scientist” on his business card.

Then you need someone who is the subject matter expert and the data digger: that’s the analyst, who acts as the “Indiana Jones” of the team. This is the person who is comfortable with writing SQL and who would most resemble the business analyst. Finally, there’s the storyteller, who has the creative side (and probably a knack for working with visualization tools like Picture), and the agent of change. The person holding the change agent role acts as an influencer who builds business cases, liaises with leaders, and ensures models connect and impact business processes. According to Bloch, the agent of change is the role that many data science teams often overlook.

Making it all work requires a consistent process that at different stages involves different team members. First, the business challenge must be identified, a task involving the change agent and the analyst. Next comes exploration and ideation, where the strategy for gaining insight is formed; this is where the analyst and the hacker meet. Next comes data mining, where the engineer, analyst and statistician get involved. Now is the time to test and develop the model itself, where the statistician, analyst and change agent collaborate. The home stretch is to tell the story, involving (unsurprisingly) the storyteller and the analyst, and then making the results actionable. Here, the change agent and the hacker collaborate to ensure that the results of the model are actually absorbed and hopefully change the business.

Although the team has many roles, you don’t want it to get too big. Since its inception, it has found that a dozen people becomes the practical upper limit, beyond which collaborative efforts become unwieldy. But in a pinch, he’s seen this model work with as few as two or three people. Take a silver ball-like the approach, don’t dwell on paper qualifications; skills and enthusiasm go much further in a job market where you sometimes have to improvise.