Building Data Science Teams: What Do You Need to Know?

Building a data science team from scratch involves more than just a list of requirements scraped from HR. Your data science team needs to solve problems and provide real business value, necessities that are difficult to describe in the traditional job posting. At ODSC East 2019, Haftan Eckholdt, chief data science officer at Understood, outlined how a company can use a milestone approach to outline the user experience of data science teams for a better representation of the job. His approach involves a combination of questions and design choices. In basic user experience, there are a few different ways you can measure customer choice. You can ask them questions directly, or you can monitor their choices indirectly. Designing an experience so that they must make choices, you can infer a lot of information just based on the content they consume. Eckholdt uses these types of markers to inform how he begins to build teams for an organization.

[Related article: Here’s Why You Can’t Hire a Data Scientist]

Building A Data Science Culture Before You Hire

There are four different critical benchmarks for data. Before you begin building your team, you must consider how data will provide real value in these four areas.

• Prospects (pure acquisition): who is the next customer? Where are they coming from? What attracts them?
• Customers: Who do we know? What are their needs?
• Product: Where do they land? Where do they go? Why do they stop?
• Content: what do they want? What do they need? What can we offer?

So what is the state of your data? As you’re curating your data, your team comes into focus. You must highlight the immediate need for data curation but also the business vision for the next five years and beyond. Things like how you report and what models you need should inform the type of teams you’re building, followed by an eye on scale for future expansion.

Building An Operational Flow As You Hire

Think of your operational flow as a two-sided funnel. You have people coming in one side of the funnel and content coming into the other side. One side is your business operation, and the other is your data. Your marketing team has a stake in data for example, as does your sales team. On the other side, your operations team needs to know how to deploy these new initiatives. How are these two sides of the funnel getting addressed within your data science team? Your team is building models that address needs across the funnel. Data teams should also consider people of diverse background knowledge to align more closely with your department. Team Structure reflects the scope of work with areas of focus falling within the grid below: Higher dimension modeling — lower latency/automated analytics/lower dimension — scheduled reporting/ad hoc experimentation From here, you connect the dots between the initial data capture with modeling and then align it with functions within your team. For example, the principle stakeholder for something like SEO is going to be the marketing team. The data team must communicate projects through that team for SEO research and data capturing, for example.

Retention and Goals

You aren’t just finding people. You must consider the types of projects you’ll deploy to find the best team fit. In addition to the job description, you’re also measuring three things:

• Impact: is building a model going to create a few percentage points of improvement or an order of magnitude? This helps you see how information is really being used, and it forces you to compare notes across the organization. This concept also helps you build risk management.

• Interest: This area is a vital part of team feedback because boring models tend to be bug-filled. You can mitigate this type of work to maintain your momentum and morale.

• Difficulty: Inconsistency across your team often appears in what one person finds difficult and what the other finds easy. Transparency here builds trust, which is a vital piece of recruiting and retention. Diligence and empathy for how you’re picking your models and deploying them within the team give members a sense of choice.

[Related article: Why You Still Need Business Intuition in the Era of Big Data]

Model Review – Improving Business Objectives

Most companies don’t have a culture of model review. However, this process is a vital part of your data deployment. You need a systematic way to look at the opportunity, host it, and maintain it. A precise method of review assigns authorship. Your model review should be clear to answer and lead teams through production.

• How old are the inputs? How old should they be?
• How old are the outputs? How old should they be?
• Are the outputs non-missing?
• Are the outputs present and diverse?
• How old is the model? How old should it be?
• Did the model actually update?

These questions are simple to answer and head into a report. You’ve got a productionalized way to look at each model, allowing you to see right away what’s going on when something breaks and steam lining trouble-shooting with anyone on the team, not just the author. The result of the internal process is a white paper of sorts for internal consumption. The first few pages should be non-technical for shareholders in the business. The rest should be technical for your data teams to consume and understand the scope of your models.

Building Overall Company Data Culture

Without proper documentation, your data science team could languish in isolation, unable to see how their skills fit into the company and unable to communicate how their technical work fits into the context of business value. You need to have a functional matrix in place to help team members connect their job functions to growth personally and organizationally. Designing a skills matrix can help your employees understand their forward movement throughout the quarter. For example, a team member may move from predictive modeling to ensemble modeling. Sometime during the quarter, you can check that box for forward movement. A skills matrix helps teams understand what they’ve gotten by being on the team. It’s beyond organizational goals. Instead, they can see clearly how their skillsets and research lines up to the organization itself. It helps put their work in context for non-technical members and build trust.

The Takeaway

Once you understand the deep functions of what you need on your team above, you can reverse engineer a job description that fits into your documentation. Moving away from requirements in your job descriptions and aligning a job description with the matrix you’ve created for skill sets and problem-solving can help invite applicants who will fit into your company culture instead of missing those who don’t have a language “requirement.” Think of your team as it aligns with your company’s culture and business mission instead.

Want to learn more about the art of building data science teams? Check out the Ai x Business Summit at ODSC East 2020 this April and learn more about implementing AI into your organization today.