How do you define data people?
The term “data people” generally refers to people working as part of a data team. Data Engineers, Data Analysts, Data Scientists, Analytics Engineers, Data PMs, and Heads of Data teams are the most common titles — let’s refer to these as core data roles.
However, does it imply that someone who doesn’t carry one of these titles cannot identify as a data person?
Let’s shift gears for a second and talk about the Growth function.
I’m sure you have seen “Growth” being used in conjunction with many different titles. I’ve seen Growth (yes, just growth), Growth Manager, Head of Growth, Product Growth, and Growth Marketing to name a few.
Folks who attach Growth to their titles work across Product, Marketing, Sales, Customer Success, and Operations, which I believe is perfectly fine.
IMO, everybody in an org contributes to growth — whether that’s growing the brand, the user base, the revenue, the feature set, the number of paying customers, the number of partners, or even the number of employees.
Similarly, someone who works with data every day to make decisions or to build customer experiences is as much a data person as the one who makes data available in the right place.
There, I said it!
In fact, if you know a good GTM (go-to-market) professional working in a data-adjacent role, it’s likely that they have a good understanding of the data that’s made available to them and are adept at using that data.
Here are some examples of how folks working in data-adjacent roles use data in their day-to-day:
- Product uses data to understand user behavior and build better products
- Growth uses data to build personalized experiences throughout the user journey
- Sales uses data to identify users and accounts they should prioritize
- Marketing uses data to measure the impact (and therefore, the relevance) of the traffic they drive
- Customer Success uses data to proactively reach out to at-risk accounts
As GTM folks become more data-proficient, I expect them to go beyond basic use cases and do a lot of cool things with data.
For those working outside of data teams, it’s unclear what one needs to know to call oneself a data person. And as the data space continues to explode, the divide between data people and non-data people is only getting bigger.
In fact, this divide was one of my motivations behind starting Data-led Academy as I’ve never worked as part of a data team or held a title containing “Data” but having worked with data at scale as a Head of Growth, I do identify as a data person.
For folks who don’t wish to work in one of the core data roles, there isn’t a specific course or learning path to become a data person. However, based on my experience and observations, here’s what I think GTM folks need to know to identify as data people.
Irrespective of one’s role, one should have a basic understanding of the following:
- Where data comes from (sources)
- What is the process of collecting data
- Where is the data stored
- How is the data moved to downstream tools (destinations)
Additionally, folks should master the tools they use to analyze or act upon data:
- Product analytics if they work in product
- CDPs (customer data platforms) and event-based engagement tools if they work in growth and marketing
- Product-led Sales tools if they work in sales and customer success (read more)
A general understanding of data infrastructure combined with expertise in domain-specific tooling should be enough for one to identify as a data person.
Basic SQL — while not a prerequisite — is a complementary skill that folks working in data-adjacent roles can acquire if they wish to go deeper and do more with data without relying on data teams.
There’s been too much talk about empowering data teams and giving them tools that make them productive.
This is important but it’s equally important, if not more, to empower people across an organization to use data, and consume data, and derive insights from data, and drive action on data.
After all, good data infrastructure is only good if non-data teams are enabled to utilize the data in their daily workflows.
I’ve dedicated several issues of this newsletter to this topic so it’s truly gratifying to see more people acknowledge and talk about the current gap between data people and non-data people.
I rarely quote others but I’m compelled to share Tristan Handy’s words from a an issue of the dbt newsletter:
Sometimes this division is used cynically by those with tremendous technical skill in the creation of data assets to talk down to folks who don’t possess those same technical skills. There is a common assumption that all data skills are about creating data assets.
The thing I find so strange about this attitude is that…if you stop and think about it, “consuming” data is the entire point. The right number of data pipelines, data models, notebooks, and dashboards to create is: as few as possible. And yet the industry spends so much time thinking about these activities and the people who do them, while focusing almost none-at-all on the humans at the end of the process who are actually processing the information they contain.
Amen to that!