Empowering the Data Analyst
By Alexa Garrison, Director of Data Analytics @ Convene
Over the last decade, large technology companies like Netflix, Google, and Spotify have set the standard for building data organizations with well-defined roles and responsibilities. Their robust organizations are hallmarked by wide-sprawling teams of data engineers, data scientists and data governance professionals all working together with different specializations. Everything from the ETL pipeline, data integrity and privacy, analytics dashboards, and machine learning optimization is expertly managed and maintained from a centralized org with clear data strategy leadership.
While we know what a robust data organization should look like, it is much more common that a company faces challenges in hiring and building a high-functioning data organization. Why is that? When companies have limited resources, they need to know how each member within a data team functions and furthermore how to optimize those roles. Your company may not be able to build out a 50+ person data team, but what companies can do is create a strong culture around data through their functional teams, build a small, but mighty team of data utility players, and empower their analytics teams to think strategically. One of the largest opportunities for mid-sized companies to empower their data organization is to clarify the ambiguity that often comes with a data analyst position.
When searching for analytics roles, the titles that most commonly appear are “Data Analyst,” “Business Intelligence Analyst,” the ever-so-vague “Business Analyst,” and my personal favorite “Strategic Business Analyst” (as if it makes the role of Business Analyst any less vague). If you actually look at the descriptions of these jobs, many of them have overlapping roles and responsibilities, and these four titles are almost never consistent across companies. After pouring over hundreds of job requirements, it seems that these roles will always fall into one of two buckets: a person who provides data and a person who provides insights. In other words, are we using Data as a Product (DaaP) or Data as a Service (DaaS)? Some people believe that this is the core difference between hiring a “data analyst” and hiring a “business analyst,” and for the sake of this post, I will refer to traditional data analysts as one’s intended to provide “data” and traditional business analysts as one’s intended to provide “insights.” However, I will argue that conflating the two is very dangerous because it completely confounds the hiring process.
If you are running an effective and lean data organization, it would be inefficient to have a person dedicated to providing data and a different person dedicated to providing insights. In an absolutely perfect world, an exceptional data analyst that is tasked with providing data will have enough business context to go above and beyond and begin interpreting the data and making product/marketing/sales recommendations to the functional leaders all within the confines of a 9 to 5 because they are super productive and know how to manage their time well! More likely than not, this is not how your company’s data team runs. If you have a data analyst that is confined to pulling, cleaning, and maintaining databases, and a separate business analyst dedicated to using this perfect data set to make decisions, one of two things will happen to the data analyst.
- The data analyst will become complacent while going through the motions of pulling data, cleaning data, maintaining databases and creating dashboards and never have a full understanding of what their stakeholders want/need nor ever feel fully connected to the business mission.
- The data analyst will want to do more, but not see any upward trajectory in their career so they will quit.
The frustrating side of being a DaaP provider is that the baseline measurement of your value to the company is perfection. It is expected and assumed that you have one job and you will, and must, do it perfectly. Data integrity is of the utmost importance, and if you cannot provide data the stakeholder can trust, then what is the point? If you have a different team dedicated to DaaS, your DaaP team has no clear way of adding value other than just doing their current job faster.
One day your DaaP data analyst might be going through their typical routine and provide a stakeholder with information that makes no sense (the average price of one croissant is $450); not because they aren’t smart or aren’t good at their jobs, but because their job is boring. And when your work is boring, it is easy to get lazy and complacent because you are so far removed from the stakeholders and business missions, and there is no business context for you to be able to validate your work (maybe croissants really are $450?). The more disconnected data analysts feel from their stakeholders, the more frequently this will happen.
Consider, in this situation, if the same person was also tasked with extracting insights from the data set they produced — is not likely they’d realize their own error? wouldn’t greater ownership of the ultimate business insight encourage greater attention to detail and greater reliability of the data itself? It would follow then that a DaaS model not only offers the prospect of more productivity from a smaller team, but also more reliability from a more motivated and empowered group of data professionals.
The trickiest part about the DaaP and DaaS conflation is that while DaaP can be boring and repetitive, it takes an extensive amount of technical skills to execute DaaP well. Whereas a traditional business analyst who is given clean data and expected to then provide insights to stakeholders requires a minimal amount of technical skills. You would be lucky to find a traditional business analyst with any type of database knowledge, so oftentimes the data analyst and business analyst operate in a gray area of confusion.
The Gray Area between Data Analysts and Business Analysts:
- What are the needs of our stakeholders?
- What insights are we expected to provide?
- Where is the data coming from?
- What does the data include/exclude, and what is the level of detail?
This gray area is helping us to define the problem and should make you realize that DaaP and DaaS are not equal. If DaaP is Charmander, DaaS is NOT Bulbasaur, but rather Charizard. Strong DaaP, along with the right training and integration, evolves into DaaS overtime.
While technical skills in data cleaning and extraction are absolutely crucial to a strong data foundation, companies should work to create a culture that develops their data analysts with specific functional knowledge so they can begin to apply context to the data they are slicing and dicing. Rather than keeping your data team separate from the functional teams, consider building a data strategy focused on developing the skills of data analysts into strategic business partners.
Interested in learning more about how to scale data at your company? Reach out to Leah and Gabi at Data Culture.
