The specialization of roles in data teams is currently a mess, as explained by Erik Bernhardsson in What Is the Right Level of Specialization For Data Teams and Anyone Else.
Core functions
I don’t remember the source of this pic
From 🗣️ Down with Data Science:
Instead, the role titles should refer to the skills people have, which she believes it’s these four: Data Engineer, Analytics Engineer, Data Analyst, and Machine Learning Engineer:
Link to original
Typical confusions / Special cases
Data Engineering and Analytics Engineering
Most of the work nowadays under the umbrella of Data Engineering is in reality Analytics Engineering (or they don’t really have the idea of Data Modeling) because of the Modern Data Stack.
MLOps / ML Engineering
A big chunk of what people call MLOps or Machine Learning Engineering is in reality Data Engineering (featurization, Feature stores are like Metrics layer…). See MLOps is Mostly Data Engineering. • Kostas Heaven on Net.
Business Analysts
Note that Business Analysis don’t appear in “Core functions of a Data team” and rightly so: it’s a role where tech/data skills aren’t the main thing, business skills are. According to the BABOK (The “Business Analysis Body of Knowledge”),
Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. (p. 2)
So they may use data (along with other resources), but it´s not their core activity and that would be the main difference with Data Analysis (even taking into account that the whole purpose of an analysis would be to make a decision about something. See Measuring a data team impact).
BTW, where they really have the most overlap is with Product Management. In fact, in the BABOK it is said:
Other common job titles for people who perform business analysis include (…) product manager.
Though that does not mean that a PM conducts only business analysis. It may be one of this possible activities. In any case, with a “full blown” PM, Marty Cagan doesn´t really like the idea of BAs (Product Manager vs. Business Analyst).
Digital/Web Analysts
We also have Digital Analysts , which could be considered an specialized set of Data Analysts both in terms of the tools they use (e.g., Google Analytics), and particular knowledge. Unlike data analysts, they are also responsible of capturing data with those specialised tools (along with front-end engineers). In fact, most of their time is usually spent there (see Digital Analyst Is Dead. Long Live Digital Analyst!). They could be called “web analysts” too but eventually changed names because they started taking care of additional digital channels.
Other interesting refs
- We the purple people
- Quasi-mystical arts of data & the modern data experience. - by Anna Filippova - The Analytics Engineering Roundup
instead of building cross functional teams of experts in different areas, we ask our data professionals to be experts in all of them (and when this inevitably fails, we ask them to say no, a lot); instead of clear contracts between tools that enable decentralized ownership and reduce the amount of context a team needs to understand to be successful, we ask our data professionals to be human interfaces, constantly negotiating a matrix of complex organizational dependencies. When the boundaries of your role and responsibilities constantly need to be negotiated, it can start looking like what you do is a lot of everything. “Wait, aren’t you Ms. data generalist?” you may ask. Yes, yes I am. This isn’t a call for more role specialization, rather an acknowledgement that the way we distribute work on data teams is misaligned with the social contracts (i.e. the human interfaces) that underpin traditional software production (…). I also don’t think the answer here lies with better tools, or better tools alone, as Erik suggests in his specialization piece from a few weeks ago — we need to be careful not to reinvent the wheel where well established fields of practice already exist (like UX). Instead, we should be thinking more about what are the right social contracts/human interfaces between the people who participate in the creation of a data product, and how do we best facilitate them.