Exiled on the Island of Data Science
When I’m getting to know a new data science team, the first thing I ask is where they fit into the org chart. Unfortunately, this innocent-sounding question can often lead to a very awkward silence. Fully one-third of the time, the answer is that they’re not on the chart at all. Or more accurately, the business’s org chart has a little island off to the side, where a lonely group of exiled data scientists live. In fact, I once met a data science group that actually referred to themselves as the “Island of Misfit Toys.”
Another third of the time, there is officially a little arrow pointing from the Island of Data Science to some executive, usually a Vice President of Something. But the arrow is a lie. For all practical purposes, the data science team is totally isolated. They don’t know what’s happening in the rest of the business, and nobody knows what they’re doing.
This leads to failure 100% of the time if it’s not changed. The most common outcome is especially sad. Nobody on the island knows what to do, and so they never accomplish anything that has any impact on the rest of the business. The best people in the data science group get fed up with having no impact, and they quit to work somewhere else. Then everyone else quits or gets absorbed onto another team. The data science team is written off as a failure. Eventually, people look back on the team and realize that of course they failed because they had no support.
You need a product mindset
When there is no meaningful org chart that includes your data science team, it’s a safe bet that the team does not have any concrete goals to produce products that have measurable impact for specific stakeholders. The island and lack of specific goals are mutually reinforcing. The team has no goals because they’re isolated. And they’re isolated because without any goals, they have no stakeholders and therefore no clear place in the business.
You need to end this vicious cycle and give your data science team meaningful connections to the rest of the business. The way to do this is by adopting a product mindset.
The data science team should always be developing a product. This entails that the team has a customer — in data science, this is usually an internal customer. The customer has KPIs that they are committed to meeting, and the mission of the data science team is to create a product that will help that team achieve one or more of those KPIs. Everything else flows from this mission.
Let’s consider a simple example. WidgetCo’s marketing team has the KPI of increasing the click-through rate on its marketing campaigns by 10%. The marketing team is good at using the available dashboards and other off-the-shelf tools for crafting its campaigns, but WidgetCo has the opportunity to use data science techniques to target their online advertisements more effectively. After some initial exploratory work, the data science team commits to building a new tool to help them. In this case, it could be a pipeline that downloads statistics about their marketing campaigns, performs some analysis, and recommends new keywords and price thresholds to deploy in the next iteration of the campaign. The tool is based on a model that optimizes click-through rate, so the data science team’s product is aligned with the marketing team’s KPI.
It is impossible to pursue this approach without making a number of positive changes to the typical data science team. The first change is that the team will need a product manager. In my experience, good product management is the best indicator that a data science team will succeed. There is an unusual amount of cross-team collaboration and strategic planning necessary to build an impactful data science product.
The second change is that the data science team should adopt a “lean” methodology that emphasizes creating an MVP as quickly as possible. They need to start the “build, test, learn” feedback loop right away. For most data science teams, this will be a big change. But in my experience, good data scientists want to have greater impact, and they are very open to any organizational or process changes that will increase their impact.
Getting the “build, test, learn” loop started will usually require additional collaboration with other teams — typically this includes data engineering, dev/ops, and business intelligence. These collaborations will provide necessary expertise that the data science team doesn’t have. The time and effort required by this collaboration will be very high at first, but will go down in the future as the data science team gains familiarity with these other domains.
Conclusion
In short, data science teams should be focused on developing products, not open-ended experiments or vague research projects. As soon as you start thinking about your data science team as engaged in developing products for stakeholders, the rest of the team’s requirements and processes naturally follow.
Leave a Reply