Editor’s note: This is part of a series of articles sharing best practices from companies on the road to becoming model-driven. Some articles will include information about their use of Domino.
The role of the data scientist has taken on rock-star status in recent years. Data scientists are in high demand as companies race to become model-driven. But despite growing recognition on the importance of and need for data scientists, many business leaders have a foggy understanding of what data scientists do and how they build models. They may know, for example, that models involve code but not understand that building models require different techniques and tools from traditional software development.
As a result, there are often inconsistencies in the market in terms of roles and job expectations. A data analyst at one company may be called a data scientist at another. And growing hype around “citizen data scientists” (often talented software engineers and analysts who build models using intuitive drag-and-drop tools) adds confusion to the mix. Citizen data scientists are valuable resources when it comes to some use cases, such as enhancing sales forecasting or redesigning marketing campaigns, where the data is cleanly prepped and consistently structured. But there is no replacement for data science experts when it comes to building advanced models that can truly drive innovation or create a core competitive advantage.
Unfortunately, all of this confusion can make it difficult for companies to move talent across functions as needed, creating significant gaps in the deep statistical, programming, and scientific expertise necessary for developing advanced models, and affecting talent acquisition and retention.
What can companies do to address this? We recently spoke with Red Hat’s vice president of Enterprise Data and Analytics, Heidi Lanford, on the topic. Heidi has steered some of the world’s largest brands (Harley-Davidson and Avaya to name two) in successfully tapping into their data. Now she’s helping put Red Hat, the largest provider of enterprise open source software, on the fast track to becoming model-driven. One of her priorities has been standardizing job definitions and career paths for all data experts, including data scientists, data analysts, and data engineers, to tackle these very issues.
Below is an edited version of our interview with Heidi on Red Hat’s journey.
Heidi Lanford: We have an Analytics Leadership Team that meets monthly. It includes the most senior data and analytics leader in each function (e.g., our People team, Finance, Sales, Marketing, Product and Customer Experience). At every meeting, the topic of roles and responsibilities kept coming up. An individual from one function would be interviewing for an opening in another, and team members were finding disparities across teams between job titles, job levels, and tracks. (We have two tracks – a business and a technical track.) It resulted in different compensation structures for people who had essentially the same skill set, training, degree, experience, and responsibilities, and made it challenging to move talent across functions.
Heidi Lanford: We started by standardizing the data scientist role first. These are the experts who create sophisticated analytic models and derive new insights from data. One team member mapped out a grid for a suggested role progression across six levels of expertise. Each level outlined an expected breadth and depth of knowledge in eight different areas:
Given our open source heritage, we place a high value on collaboration and community-led efforts. Once the Analytics Leadership Team member completed this initial mapping, we put out a pro-forma document and asked for feedback from the rest of the team. We then looked at examples within each function, discussing what criteria a specific individual would meet, then confirmed that we all agreed this was an accurate assessment.
We also brought in experts from our People team early on. They helped ensure our work was aligned with Red Hat’s job descriptions and provided industry benchmarking data for our pay scales.
We then did the same for our data analysts, who use data analysis techniques to solve problems and glean insights across functional domains. And we again repeated the process for our data engineers, who work side-by-side with the data scientist or data analyst to help massage, manipulate, and prepare data.
Heidi Lanford: There’s some overlap between the data scientist’s role and data analyst’s. We expect data analysts to have some programming experience. However, their tools are going to be more on the business intelligence and data visualization side, with some SQL/Adobe Analytics experience.
We also created a new role, called the analytics solutions lead, whose job is to help end users adopt new model outputs. Of course we’re working to enable our technical experts, like data scientists and data analysts, to sell these concepts ahead of time. But we know not everyone is going to be great at that. So we have a solution lead role in charge of helping use cases come to life, communicating what the value and benefits are of the model output.
Heidi Lanford: Typically, I’ve found much of the analytics that organizations do is data analysis and less is predictive modeling, machine learning, and artificial intelligence use cases. There are automated machine learning tools that can be helpful when it comes to data analysis. However, when you get into advanced statistical modeling, for example in our sales forecasting process, business leaders are more confident in the model outputs when expert data scientists develop the models.
Heidi Lanford: Absolutely. The ideal team has a data analyst, a data scientist, and a data engineer all working side-by-side, along with a solutions leader. The data analyst will have more business skills and need to invest a lot of time in understanding what is going on in the business. So if you’re a data analyst on the HR side, you need to not only understand what the numbers mean, but also how HR business processes can be improved or altered based on that information. The data scientist, conversely, is going to have in-depth knowledge of the statistical algorithms that they’re using.
Heidi Lanford: As I mentioned earlier, Red Hat has a very collaborative culture. As a result, when we set out on this task, it was essential that everyone in the analytics community, not just a few people, was invited to provide input. After our Analytics Leadership Team came to consensus on career paths for each role, we shared those documents with our more than 100-plus community members worldwide for their feedback. We received great suggestions that we included, such as sharing knowledge of data science methods outside of Red Hat (i.e., speaking engagements and publishing articles), requiring presentation skills for data analysts, and adding some additional languages that our teams are using.
We also want to make sure business staff who are not in one of these career paths still have a basic level of data literacy; for example, they understand what a forecasting model can do for them, how sample sizes can influence outputs, what confidence bands are, and so on. We realize if we keep things to ourselves, we’re not going to get the kind of adoption and game-changing business behavior we’d want.
Heidi Lanford: Having defined career paths for folks leads to higher employee satisfaction. Data experts can move from one function to another to take on new challenges, and with Domino, we have a standard platform they can use to collaborate with colleagues in other areas of the business.
On the business side, standardizing these roles, getting everyone working off of similar data, and connecting data science across functions, gives us an enterprise view of the business so we can more effectively mitigate risk. Organizations doing data science in dribs and drabs aren’t able to make connections across functions. An enterprise view, however, means if a sales forecast shows trouble in one region a few quarters out, the Marketing team can take action sooner to influence that trajectory, the People team can be sure we’re recruiting enough of the right people, and we can make adjustments to our sales plays or resolve product issues.