Common Data Roles (Engineer vs Analyst vs Scientist)

Most data teams divide the same work among a familiar set of roles, and the clearest way to tell them apart is by where they sit relative to the data warehouse. Product teams own the source systems feeding it. Data engineers own the pipelines, integrations, transformations and scheduling that get data into the central hub. Data analysts sit on the far side, turning that data into reports and answers for the business. Analytics engineers are the hybrid in the middle, and data scientists build predictive and statistical work on top of whatever the engineers have modeled. Titles vary by company, but the division of labor is fairly consistent.

The high level picture

I use a simple visual for this, what I call the three pillars of data engineering. It is a useful way to see where each person operates in a data platform.

The three pillars are:

• Sources. The systems where data originates.
• The central hub. Call it a data warehouse or a data lake, plus all the transformation happening in the middle.
• Insights. Data visualization, machine learning, and anything else consuming the output.

Every role below maps to one of those three, or to the handoff between two of them. I go through the pillars themselves in more detail in The 3 Pillars of Data Engineering.

Product and the source system owners

Start before the warehouse. Something has to own the systems your data comes out of.

That might be Salesforce, QuickBooks, MailChimp, Google Ads, or internal databases. Anything that acts as a source for your data team has an owner, and typically that is a product team.

How this usually splits

Depending on company size, there may be several product teams covering different sources, or one team covering all of it. One team owning everything is unlikely, so expect it to be broken up.

You might call them software developers instead of product, especially if you have in house application developers. The label matters less than the boundary.

These are the people responsible for everything before data reaches your central hub. If a schema changes upstream, this is who you talk to.

The data engineer

This is where I imagine most of us are operating. The data engineer owns the pipelining and the back end work.

That means getting sources into the central hub, building the integrations, building the data transformations, scheduling all of it, and generally getting data moving into something the rest of the company can use.

Who the engineer works with

A lot of the job is working with the people on the product side, whether you call them software engineers or product owners.

You are talking to them to understand schemas, to confirm that logic is correct, and to find out what is changing before it breaks a pipeline.

The data analyst

Skip forward past the gap in the middle for a moment, which we will come back to.

The data analyst sits between the data architecture, meaning the central hub and the technical work behind it, and the insights going out to stakeholders, business users, and sometimes external users.

The bridge role

Their job is bridging technical and business users. That means communicating requests back toward the engineers so everyone is working from the same understanding.

It also means owning whether the output is actually useful. Analysts make sure what comes out of the central hub meets the needs of the business, which is a different question from whether the pipeline ran.

How technical analysts are

Technical enough to build reports and dashboards and write their own queries. Often technical enough to use a tool like dbt to generate custom models and custom data for their own analysis.

That range is exactly why the next role exists.

The analytics engineer

The analytics engineer was relatively new when I recorded this, and it fills the gap I skipped over.

It is a hybrid between a full data engineer working on integrations and back end systems, and a data analyst who is more forward facing and user facing. A bit more technical than a typical analyst, though that is not to say analysts are not technical, because very often they are.

Why the role appeared

Tools like dbt specifically brought this to the forefront. More people became skilled with data, SQL and automation, and that work became accessible to more than just the back end specialists.

As a result, data engineers have gradually pushed further back toward integrations and infrastructure. The data engineer and the analytics engineer usually end up working very closely together.

A common split of the work

One arrangement I see often:

• Data engineer. Back end integrations bringing the sources in, the system itself, automation and scheduling, and often the core data model.
• Analytics engineer. Works on top of that core model to build more user facing custom models.
• Data analyst. Connects to those models and takes the analysis further.

Or the analytics engineer is also the analyst. That is entirely up to the company. The concept is simply something sitting between those two poles.

The data scientist

Data science gets confused with data engineering constantly, and they are not the same thing.

Data science is machine learning, predictive work, and statistical, math driven analysis. It is a way of gathering insight that is quite different from reporting.

What it depends on

It is typically built on top of the structure and back end that the data engineer designed, modeled and put together.

The algorithms and statistics underneath it are not something a data engineer would normally be concerned with. They are also not usually what a data analyst is doing, since the analyst is more focused on dashboards, reporting and custom models.

It is not always this clear cut

Real teams are messier than this. Plenty of companies fold two or three of these roles into a single title, and smaller teams almost always do.

The point of the buckets is to give you a way to think about where the work lives. From there you can decide what fits you, how you want to structure a team, or simply how to operate inside the one you are in.

Related reading

• The 3 Pillars of Data Engineering
• What Every Data Team Lead Should Know
• The Long-Term Impact of The FIRST Data Team Hire
• Data Engineer: Employee vs Consultant

Final takeaway

On the small teams I work with, one or two people usually cover four of these roles at once, and the titles matter far less than knowing where each piece of work belongs. Map the work to the pillars first, then decide who owns what.