Topic 50

The ML Job Map

Concept

Eleven chapters ago, Iris could not have told you what a model was. Now she understands the work — and discovers, scrolling job ads on a slow Friday, that she still can't name who does it. "Data scientist." "ML engineer." "Data analyst." "Data engineer." Four titles blurring into one buzzword soup, sometimes all four in a single posting. If the work is clear by now, the org chart deserves to be too — and this page is that org chart, told by what each role actually does all day, using only machinery the book already built.

A professional kitchen solves the same sorting problem with a brigade. Someone sources the ingredients. Someone develops the recipes. Someone runs the line, plating four hundred covers a night without dropping one. And someone reads the tickets and the tastes, working out what the dining room actually wants. Data teams divide exactly this way: the data engineer sources, the data scientist develops recipes, the ML engineer runs the line, and the analyst reads the room — and in a bistro, one cook does all of it. Here is each of the four stations, in the terms of what it actually does all day.

Four roles, four working days — and the chapters that describe each
Data analyst
Answers "what happened?" with data and dashboards. Your chapters: 6 and 10 — honest measurement, careful reading.
Data scientist
Frames, features, trains, evaluates. Your chapters: 2–7 — this book's spine is the job description.
ML engineer
Deploys, monitors, retrains at scale. Your chapters: 7 — plus the software world of Topic 51.
Data engineer
Builds the pipelines under everyone. Your chapters: 2 — the data reality, made permanent plumbing.

The Data Analyst: What Happened?

Start closest to the business. The data analyst answers questions about what already happened: did weekend orders rise after the coupon? Which cities lose customers fastest? Is the new menu layout actually changing anything? The tools are data, dashboards, and reports — usually no models at all — and the customers are managers who need a number they can trust by Thursday.

The skill underneath is exactly the literacy this book spent Chapter 6 and Chapter 10 building. An analyst runs Topic 48's caution as a daily tool: this correlation is real, but is it actionable? What third variable might be driving both lines on this chart? The analyst is the role closest to the business — and, in practice, often the entry door into the whole field.

The Data Scientist: Will This Work?

The data scientist is the experimenter. They frame the fuzzy business wish into a trainable question (Topic 30), engineer the features a model can actually use (Topic 31), train candidate models, and evaluate them honestly against baselines and held-out data (Chapters 3 through 6). If that list feels familiar, it should: the arc you read from Chapter 2 to Chapter 7 is this job's description.

The texture of the week is experiments over pipelines: hypotheses tried and mostly discarded, feature ideas that don't pan out, one candidate model that finally beats the baseline honestly. When Plateful's churn model was born in Chapter 7, everything up to "it works on held-out data" was data-scientist territory. What happened after that belongs to the next station.

The ML Engineer: Keeping It Alive

The ML engineer takes the model that won the experiments and makes it survive contact with the real world: deployment behind an API (Topic 33), monitoring for silent aging and scheduling the retrains (Topic 34), plus speed and scale — answers in milliseconds, for millions of requests, without falling over on Friday night. This is the software-engineering wing of the discipline: less "will this model work?" and more "will this model still be working at 3 a.m.?"

Notice where that places them in this catalog: the DevOps and Cloud material the next page maps out is an ML engineer's native ground. If Chapter 7 was your quiet favorite — the shipping, the monitoring, the lifecycle — this door is the one with your name on it.

The Data Engineer: The Pipes Under Everyone

The data engineer builds and runs the pipelines that collect, clean, and deliver the data everyone else stands on — Topics 08 and 09, run at industrial scale, every day, forever. When the analyst's dashboard updates overnight and the scientist's training set arrives fresh and de-duplicated, that is data engineering working so well it's invisible.

It is the least visible of the four roles, and here is the one honest sentence this page owes you: when ML projects fail, the missing ingredient is more often the data engineering than the modeling. Garbage in, garbage out was Topic 10's law; the data engineer is the person hired to keep the garbage out.

Small Shops, One Hat

At Plateful's size, these are four different people. At a five-person startup, one person wears three of the hats before lunch — sourcing the data, training the model, and shipping it themselves, like the bistro cook who shops, preps, and plates alone. Task coverage is what matters; headcount is a luxury of scale.

Which yields the practical skill this page has been building toward: read job ads by their task lists, not their titles. The titles are packaging — one company's "data scientist" is another's "ML engineer" and a third's "member of technical staff". The tasks are the stable reality: if the ad says dashboards and business questions, it's the analyst's day; if it says framing, features, and evaluation, the scientist's; if it says deployment, monitoring, and scale, the engineer's; if it says pipelines, the plumbing under everyone. You now know all four days from the inside.

Common Confusions
  • "Data scientist is the senior version of data analyst." Different task bundles, not a ladder. Analysts explain the past; scientists model the future — and seniority exists within each role, up to very senior analysts and very junior scientists.
  • "ML engineers train the models." Mostly they productionize and operate them — deployment, monitoring, retraining pipelines, speed, scale. Training is the data scientist's core work, though in practice the border has plenty of traffic in both directions.
  • "Every ML team needs all four roles." Every ML effort needs all four kinds of tasks covered. Small teams multi-hat; large teams specialize. Headcount follows scale, not the checklist.
Why It Matters
  • Job ads, org charts, and "we should hire a data person" conversations decode instantly once you can match a title to a working day — and spot when a single posting has quietly bundled three separate jobs into one.
  • If you're eyeing a career move, this page is the map of doors: four roles, four daily realities, and the chapters of this book that describe what each one feels like from inside.

Knowledge Check

Someone at Plateful spends the day building a dashboard to answer "did the new coupon change weekend orders?" Which role is this?

  • Data scientist — dashboards are how models get evaluated
  • Data analyst
  • ML engineer — coupons are a production feature
  • Data engineer

Which role's daily work is described by this book's own arc — framing the problem, engineering features, training, and evaluating honestly (Chapters 2–7)?

  • The data analyst
  • The data engineer
  • The data scientist
  • The ML engineer

A colleague says "the ML engineers are the ones who train the models, right?" What's the accurate correction?

  • ML engineers don't really work on ML — the title is marketing
  • There's no correction needed at all — everyone on a data team spends their days training models
  • Mostly they deploy and operate models in production; training is chiefly the scientist's job
  • ML engineers only label the training data

A startup posts an ad for a "Data Wizard". Following this page, what's the useful way to read it?

  • Skip it — a made-up title means the company doesn't know what it's doing
  • Assume it's a data scientist role, since that's the most common title
  • Check the salary — pay reveals which of the four roles it really is
  • Read the task list and match it to the four working days — titles are packaging

You got correct