---
title: Data Scientist vs Machine Learning Engineer
canonical: "https://data-driven.com/blog/i-know-what-a-data-scientist-is-but-what-the-heck-is-a-machine-learning-engineer/"
pubDate: "2019-09-05T00:00:00.000Z"
updatedDate: "2026-08-25T00:00:00.000Z"
description: "An engineer's field note on how data science and engineering roles divide model development, deployment, monitoring, and scale."
tags: [data-science, databricks, machine-learning]
categories: [databricks]
---

The title **machine learning engineer** can be vague. In practice, the role usually connects model development with the software, data, and operational work needed to run a model reliably.

This article began as a 2019 field note. Tooling and team structures have changed, but the central lesson remains: do not ask one title to hide several different responsibilities.

## The data scientist owns the model question

A data scientist often leads work such as:

- translating a business question into a testable modelling task;
- selecting features, methods, and evaluation measures;
- testing assumptions and comparing experiments;
- explaining uncertainty, bias, and model limits;
- deciding whether the evidence supports use.

The role needs access to data-engineering and domain expertise. A good experiment can still fail in production if the source, feature, or decision process changes.

## The machine learning engineer owns the production path

A machine learning engineer often turns a validated model into a supportable system. That can include:

- reproducible training and feature pipelines;
- versioned code, data references, and model artifacts;
- deployment, scaling, and rollback;
- interfaces for applications and downstream services;
- monitoring for service health, data drift, and model behaviour;
- retraining and approval workflows.

This work overlaps with data engineering, platform engineering, and software engineering. The exact boundary should be written for the team rather than inferred from the job title.

## The handoff is part of the design

Teams lose time when model code is handed over without its assumptions, environment, test data, or acceptance criteria. Pair the roles early enough to make production constraints visible during experimentation.

A useful handoff record includes:

1. the business decision and model owner;
2. source and feature definitions;
3. training and evaluation method;
4. accepted quality and risk thresholds;
5. runtime, latency, and availability needs;
6. monitoring, retraining, and rollback responsibilities.

## Build a team, not a stereotype

Some people span both roles; others specialise. Neither structure is automatically better. The right choice depends on the model's consequence, data scale, release frequency, and operating environment.

Name the responsibilities first. Then assign people with the required skills and enough time to do the work. That is more useful than expecting every data scientist to be a production engineer or every engineer to validate the statistical case for a model.