Expert Exchange: Adding Structure to Support Our Future Data Science Organization

Client Inquiry:

We're creating a roadmap for our data science organization. What small steps should we take now in structuring and hiring to get us to where we want to be in five years? Specifically, we're considering both a centralized and federated structure, and if we should focus on generalist or specialist data scientists.

Expert Takeaways:

Centralization Misnomer

Deciding whether to adopt a centralized or a decentralized data science organization is a bit of a misnomer because either way you will have to align with the business units (BUs).

• When organizations restructure, they are often really trying to address people issues. Address the people issue first, then decide if you still want to reorganize.
• When data science operates only in the BUs, you get team replication and products that are lesser solutions. The teams are smaller, and the hiring practices aren't as stringent.
• To minimize replication, create an enterprise solution in which the central team takes on projects that will result in solutions that can be used across the company. The central team has bigger pools of money to design single solutions.
• Within a centralized model, the question of embedding data scientists still exists because teams often need solutions fast.

Org Structure

It's a question of whether solid-line reporting goes up through the central data science function or up through the BUs.

• Analytics talent supporting operational functions might report through the central team, but physically they sit within the teams they support. For example, the marketing analytics team sits with marketing but reports through central.
• Within data science, you may have teams that align with engineering. For example, a digital product team working on search engineering may have a search data science team sitting with it.
• Think horizontally too: a data science team that works in service of other data science teams. Maybe they work on reusable models to avoid replication of effort through the BUs.
• The horizontal piece becomes more important as your data science maturity grows.
• If your verticals are areas like search and target marketing, the horizontals might be areas such as labeling, data visualization, and prototyping and innovation.
• Development moves to a horizontal team when a vertical team develops a solution that other teams want to use. Vertical teams tend to welcome the help because the projects will receive more resources.

Creating structure is like children's clothes: You buy clothes that are a little too big so kids will grow into them. Design the org chart to look like where you want to be a year from now. It will feel specialized at first and two years later not specialized enough. Since you're in growth mode, you want to maximize the time you can live in one org chart.

Specialization

I'd be reluctant to organize around specialization, especially for machine learning (ML).

• Exceptions could include a research lab, individuals who are exceptional in a specialization they've chosen for themselves, economists, and data labelers.
• In general, data scientists don't want to be told they can't do things. If you're working on automated machinery, would you want to be limited to only working on the vision component or the speech component?
• From a career path perspective, specialization can be limiting too. Would you prefer the label "ML scientist" or "computer vision scientist"?