Data jobs demystified: what each role actually does

Job posts blur on purpose. “Data scientist” might mean SQL dashboards. “Data engineer” might mean Airflow plus politics. “Analyst” might mean mini-PM with a notebook. Titles are noisy. The work is clearer if you map it to questions, systems, and outputs.

Here is a plain map of common data roles, how they overlap, and how to read a posting without getting dazzled. Pair with analytics vs BI vs data science.

What you’ll learn

What each major role optimizes for
Where titles overlap in small companies
Skills that transfer across roles
How to choose a path based on taste, not prestige
Red flags in job descriptions

Titles blur. Optimize for the work you want to do.

Analyst

Owns questions and clear answers. Pulls data, checks quality, builds tables or lightweight models, and communicates tradeoffs. Success looks like decisions that cite a number people trust. Tools: SQL, sheets, BI, sometimes Python. The best analysts are annoying in a helpful way: they ask what decision the chart is for before they build the tenth version.

BI analyst and developer

Owns scalable reporting and semantic layers. Builds dashboards that do not fall over when ten teams filter them wrong. Success looks like self-serve that stays consistent. Tools: BI platforms, modeling layers, strong SQL. If every team invents revenue in their own workbook, BI has more work to do than a new color palette.

Analytics engineer

Sits between analysts and platform. Turns repeated analysis into tested warehouse models and metrics. Success looks like fewer one-off pipelines and clearer grains. Tools: SQL, dbt-like workflows, git, basic software hygiene. Think “software habits for analytics SQL.”

Data engineer

Owns reliable movement and platforms: ingestion, orchestration, storage, access, cost, and often quality monitors. Success looks like data arriving correctly without heroics. Tools: warehouses, pipes, infra as code, strong software skills. When the pipe is broken, nobody cares about your favorite chart library.

Data scientist

Owns uncertainty: experiments, forecasting, models, causal questions when the business invests in them. Success looks like decisions improved under ambiguity, not just fancy notebooks. Tools: stats, Python/R, SQL, experimental design. If there is no decision owner for the model, you are decorating a slide.

ML engineer

Owns models in production: serving, monitoring, retraining, latency, and failure modes. Success looks like systems that stay correct after the demo. Tools: ML stacks, software engineering, observability. Demos are easy. Tuesday at 3 a.m. after a silent schema change is the job.

Comparison

Role	Primary question	Typical output
Analyst	What should we do?	Brief, chart, recommendation
BI	How do we see the same truth?	Dashboard, semantic model
Analytics eng	How do we reuse trusted tables?	dbt models, tests
Data eng	How does data get here reliably?	Pipelines, platform
Data scientist	What can we predict or test?	Model, experiment design
ML eng	How does the model run in prod?	Service, monitors

Small company reality

One person may wear three hats. That is fine if expectations are honest. It is not fine when leadership expects production ML, executive BI, and 24/7 pipelines from a single hire without prioritization. Write the priority order down. Otherwise the loudest Slack channel wins every week.

Choosing a path

Like storytelling and business context → analyst / BI
Like software craft and systems → data eng / ML eng
Like math under uncertainty → data science
Like modeling business logic in SQL → analytics eng

Job description red flags

Laundry list of ten languages and five cloud certs for one junior seat
“Rockstar” with no mention of stakeholders or quality
Unclear whether success is research or production
No data stack named at all
Unlimited scope with no decision rights

Transferable skills

Across all of these roles, the durable skills are: clear writing, careful definitions, basic statistics intuition, SQL fluency, and the ability to say “I do not know yet” without panicking a room. Tools change. Those habits compound.

Quick recap

Map work by outputs, not prestige titles
Overlaps are normal; ownership should still be clear
Pick paths by taste and problems you enjoy
Small teams blend roles; big teams specialize
Read postings for real success metrics

Write examples from your own workplace. A named dashboard fight teaches more than a generic industry claim, and it keeps the post useful when the logos on the architecture slide change again next year.

If two teams argue about a number, put both definitions on one page with owners and timestamps. Clarity beats a forced compromise that nobody trusts enough to use in a real decision meeting.

Ship a small artifact this week: a definition card, a quality check, a retired vanity chart, or a one-page brief. Momentum compounds faster than another strategy deck about becoming data driven someday.

Teach newcomers where the source of truth lives on day one. Onboarding is a data-system surface. If new hires learn the wrong table first, you will spend months undoing that habit in code review and Slack threads.

When something breaks, fix the rule or the automated test that should have caught it. Heroic manual checks do not scale, and they disappear the week everyone is out on holiday or buried in a launch.

Prefer plain words in meetings until everyone shares a definition. Jargon is fine after that. Before that, jargon is just a way to lose the people who will actually act on the analysis.

Keep a short change log for metrics, pipelines, and critical dashboards. Future you will need the date a definition shifted, and you will not find it in a year-old screenshot buried in a slide archive.

Measure one concrete thing that proves the new approach beats the old habit: fewer reconcile hours, faster ticket answers, lower duplicate rates, or fewer “which number is right” threads per month.

Resist boiling the ocean. One domain, one partnership, one metric strip, or one retrieval evaluation set is enough to learn. Expansion is easier after you have a win people can point at without squinting.

Document the messy edge cases in the open. Hidden footnotes become tribal knowledge, and tribal knowledge becomes an outage when the only person who remembered the footnote changes teams.

If two teams argue about a number, put both definitions on one page with owners and timestamps. Clarity beats a forced compromise that nobody trusts enough to use in a real decision meeting.

When something breaks, fix the rule or the automated test that should have caught it. Heroic manual checks do not scale, and they disappear the week everyone is out on holiday or buried in a launch.

Prefer plain words in meetings until everyone shares a definition. Jargon is fine after that. Before that, jargon is just a way to lose the people who will actually act on the analysis.

Document the messy edge cases in the open. Hidden footnotes become tribal knowledge, and tribal knowledge becomes an outage when the only person who remembered the footnote changes teams.

If two teams argue about a number, put both definitions on one page with owners and timestamps. Clarity beats a forced compromise that nobody trusts enough to use in a real decision meeting.

When something breaks, fix the rule or the automated test that should have caught it. Heroic manual checks do not scale, and they disappear the week everyone is out on holiday or buried in a launch.

Prefer plain words in meetings until everyone shares a definition. Jargon is fine after that. Before that, jargon is just a way to lose the people who will actually act on the analysis.

Data jobs demystified: what each role actually does

What you’ll learn

Analyst

BI analyst and developer

Analytics engineer

Data engineer

Data scientist

ML engineer

Comparison

Small company reality

Choosing a path

Job description red flags

Transferable skills

Quick recap

Sources

Merch on Etsy