Data Engineering vs Data Science vs Machine Learning: Who Does What

Data science, data engineering, and machine learning are often used interchangeably, leading to confused hiring, misaligned teams, and stalled projects. For leaders building a data capability, understanding the distinct functions and critical interplay of these roles is the first step toward building a function that creates durable value.

The roles are not just different labels for "people who work with data." They represent distinct specialisations with different goals, deliverables, and tools. A data engineer enables work, a data scientist performs it, and a machine learning engineer scales it. Getting the definitions, ratios, and reporting lines right is a crucial, company-defining decision.

Definitions and Overlaps

At their core, the roles can be defined by their primary objective:

• Data Engineer (DE): Builds and maintains the systems that collect, store, and deliver clean, reliable, and timely data to the rest of the business.
• Data Scientist (DS): Uses scientific methods, processes, and algorithms to extract knowledge and insights from structured and unstructured data, often to answer complex business questions.
• Machine Learning Engineer (MLE): Designs, builds, and maintains production-grade machine learning systems, focusing on scalability, performance, and reliability of the models created by data scientists.

While these definitions are distinct, the reality on the ground is a spectrum. In a small startup, a single person may wear all three hats. In a large enterprise, these roles can be further subdivided (e.g., Analytics Engineer, ML Ops Engineer, Research Scientist).

The most significant overlap occurs between data science and the other two roles. A data scientist must possess some data engineering skills to acquire and clean data for analysis. They must also have some machine learning engineering understanding to build models that are not entirely untethered from production reality. However, relying on a data scientist to build enterprise-grade pipelines is as inefficient as asking them to manage Kubernetes clusters. The value of specialisation is performing a core function at a world-class level, rather than multiple functions at a mediocre one.

Deliverables by Role

The clearest way to distinguish these roles is by their tangible outputs. A CEO or CTO should be able to look at a team's work and identify who produced what. The primary deliverable of a data engineer is a system, for a data scientist it's an insight, and for an ML engineer it's a product.

In our engagements, a common point of failure is a mismatch between expectation and role. For example, a stakeholder asks a data scientist for a real-time fraud detection system. The DS might build a brilliant model in a Python notebook, but they are not equipped to deliver a system that can handle 10,000 requests per second with 50ms latency. That translation from prototype to product is the core work of the MLE, who depends on the data pipelines built by the DE. For more on building robust pipelines, see our guide on Data Pipeline Architecture Explained (With Patterns That Scale).

Tooling Map

The tools a professional uses are a strong indicator of their daily work and responsibilities. While there's crossover (everyone uses Git and speaks SQL), the core of each role's toolkit is highly specialised.

This separation of tools highlights the separation of concerns. A data engineer thinks about distributed systems and data movement. A data scientist thinks about statistical validity and feature representation. A machine learning engineer thinks about containers, APIs, and production monitoring. Expecting one person to have deep, hands-on expertise across all three columns is the "unicorn hunt" — a search that is almost always fruitless and a distraction from building a functional team.

Hiring Order for the First Four Data Hires

For a company starting its data journey, the sequence of hires is critical. The wrong first hire can lead to months of frustration and little to show for a significant salary investment.

Hire 1: Senior Data Engineer This is almost always the correct first hire. Without a reliable, centralised source of truth, any analysis is built on sand. A data scientist hired without data infrastructure will spend 80% of their time trying to be a mediocre data engineer, fetching CSVs, fighting with APIs, and cleaning data in scripts that live only on their laptop. This is a profound waste of their skills and your money. The first data engineer’s job is to pour the concrete foundation: ingest key data sources (e.g., product database, CRM, analytics events) into a data warehouse and establish basic quality checks. This foundational work is the core of professional data engineering, and it enables everything that follows. For a deeper dive, read our article on What Is Data Engineering and Why Does Every AI Company Need It?.

Hire 2: Data Scientist (with strong analytics skills) Once the data engineer has established a flow of reliable data into a central location (e.g., Snowflake or BigQuery), the data scientist can begin their real work. Their first tasks are typically descriptive and diagnostic: creating dashboards to track core KPIs, analysing user behaviour, and answering urgent business questions. They find the "known unknowns" and begin to quantify business problems. This hire starts to deliver the first visible ROI from the data investment.

Hire 3: Machine Learning Engineer This hire becomes necessary when the data scientist's work moves from analysis to prediction in a way that needs to be integrated into the product. For example, the DS prototypes a recommendation model that shows promising results in an offline evaluation. The MLE's job is to take that model (often a script and a pickled object) and build a production service around it. They handle API design, performance testing, deployment, and monitoring. Hiring an MLE too early is a waste; they will have no models to productionise.

Hire 4: Second Data Engineer or Analytics Engineer By the time you have a DS and an MLE, the demands on your data platform will have grown significantly. The DS needs more data sources, and the MLE needs production-grade feature pipelines. The second data-focused hire is often another data engineer to increase the platform team's bandwidth. Alternatively, you might hire an Analytics Engineer, a newer role that sits between the DE and DS, focusing on using tools like dbt to transform and model data within the warehouse specifically for business intelligence and analysis.

Worked Example: The Cost of the Wrong Hiring Order

Let's model the cost for a Berlin-based Series A logistics platform over 12 months. Assume a 2026 senior salary of €125,000 for a Data Scientist and €115,000 for a Data Engineer (including all social costs).

Scenario A: Hire Data Scientist First

• Months 1-6: The DS (€62,500 spent) spends ~70% of their time on ad-hoc data extraction and cleaning. They produce a few basic dashboards from manually exported data. The work is not reproducible, and data is often inconsistent. The effective value delivered is from only 30% of their time. This is a direct waste of €43,750.
• Month 7: Realising the problem, the company hires a Data Engineer.
• Months 7-12: The DE (€57,500 spent) builds the initial pipelines. The DS starts to become more effective, but the first 6 months of foundational work were delayed.
• Total Year 1 Cost: €182,500.
• Outcome: Some basic dashboards and a delayed start on real data science. The company is 6 months behind schedule.

Scenario B: Hire Data Engineer First

• Months 1-4: The DE (€38,333 spent) builds the core data warehouse, ingesting data from the production database and third-party logistics APIs.
• Month 5: The company hires a Data Scientist. They land on a platform with clean, reliable data ready for analysis.
• Months 5-12: The DS (€83,333 spent) immediately starts building KPI dashboards, analysing route efficiency, and prototyping a delivery time prediction model. The DE continues to expand the platform.
• Total Year 1 Cost: €179,166.
• Outcome: A functioning data platform, a suite of reliable BI dashboards, and a validated model prototype ready for productionisation. The company is on track and making data-informed decisions.

The direct salary costs are similar, but the value generated and the velocity of the team in Scenario B are dramatically higher.

Team Topologies

How you structure your data teams has a huge impact on their effectiveness. There are three common models, each with distinct trade-offs.

Centralised

A single data team (often called "Data & AI" or "Insights") serves the entire organisation. This team contains all the DEs, DSs, and MLEs, and business units submit requests to a central backlog.

• Pros: Enforces consistent standards and tooling, creates a critical mass of expertise for knowledge sharing and mentorship, clear career path for data professionals.
• Cons: Can become a bottleneck, lacks deep business context for specific domains, may be perceived as a slow "ivory tower" by product teams.
• Best for: Smaller companies or organisations just beginning their data journey, where establishing a consistent foundation is the top priority.

Embedded

Data professionals are hired directly into business units or product squads. A data scientist might report to a Product Manager for the "Search & Discovery" team, and a data engineer might report to the Head of Engineering for the "Logistics" division.

• Pros: Deep domain expertise and business context, high alignment with product goals, fast iteration cycles within the team.
• Cons: Leads to data silos, duplicated effort (e.g., multiple teams building similar pipelines), inconsistent tooling and quality standards, professional isolation for the data experts.
• Best for: Highly mature, large organisations where domains are extremely distinct (e.g., a conglomerate with completely separate lines of business).

Hybrid (Centre of Excellence)

This model attempts to get the best of both worlds. A central data platform team, composed mostly of data engineers and MLEs, builds and maintains the core infrastructure, tooling, and standards. Data scientists and analysts are then embedded within business units but belong to a central "chapter" or "guild" for their specialisation.

               ┌──────────────────┐
               │       CTO        │
               └─────────┬────────┘
                         │
         ┌───────────────┴───────────────┐
         │                               │
┌────────┴───────────┐         ┌─────────┴──────────┐
│ Head of Product A  │         │ Head of Data Platform│
└────────┬───────────┘         └────────┬───────────┘
         │                              │
┌────────┴──────────┐      ┌────────────┴───────────┐
│ Embedded DS/Analyst│      │  Central Data Engineers│
│  (Solid line to   ├──────┤ Central ML Engineers   │
│   Product Manager) │      │  (Dotted line to DS   │
└──────────────────┘      │   for collaboration)   │
                          └────────────────────────┘

Key:
─── Solid Line: Direct reporting relationship
- - - Dotted Line: Guild/Chapter/Collaboration link

• Pros: Balances central governance with local autonomy, enables both deep domain context and high technical standards, provides a clear career path and community for data specialists.
• Cons: Can create matrix management complexities, requires strong leadership to maintain alignment between the central and embedded teams.
• Best for: Most companies of scale (50+ employees) that are serious about data. It is the most robust and scalable model we have observed across our engagements.

Choosing the right topology is a strategic decision that depends on company size, maturity, and culture. It's a common and high-stakes topic we address in our AI consulting with leadership teams.

Common Structural Mistakes

Over the years, we've seen several recurring anti-patterns in how companies structure their data functions.

1. The "Data Science is a magic wand" fallacy. A leadership team, excited by AI, hires a team of expensive data scientists without any data engineering support. The team gets bogged down in data prep, produces nothing of value, and morale plummets. Within 18 months, the team is disbanded, and leadership declares that "data science didn't work for us."
2. Confusing Data Engineering with IT. Data platform development is a product development activity, not a cost centre. The data platform team needs product management, agile processes, and a roadmap driven by business needs. When it's buried under a traditional IT department focused on cost-cutting and ticket-based systems, it cannot innovate or respond to business needs effectively.
3. The Lone Unicorn. A company tries to hire one brilliant person to do everything. This person is impossible to find, and even if found, they become a single point of failure. They cannot possibly be an expert in distributed data processing, causal inference statistics, and low-latency model serving. This approach doesn't scale.
4. No Clear Ownership of Production Models. A data scientist builds a model, "throws it over the wall" to a software engineering team to deploy, and moves on. When the model drifts or fails in production, the software team doesn't know how to fix it, and the data scientist has moved on. The ML Engineer role exists specifically to solve this problem by owning the entire lifecycle of the production model.

Worked Example: Staffing a Project Correctly

A European insurer wants to improve its claims processing by using AI to flag potentially fraudulent claims for human review. The project goal is to process 90% of incoming claims automatically and route the riskiest 10% to investigators, aiming to increase the detection of fraudulent claims by 50%.

A poorly structured approach would be to assign this to a single data scientist. They would struggle to get the data and have no path to production.

A correct, modern approach, as we would structure it, involves a cross-functional team:

• 1 Senior Data Engineer (€115,000/year): Responsible for building a reliable pipeline from the core claims system and external data sources (e.g., location data, vehicle history) into a feature-ready format in the data warehouse.
• 1 Senior Data Scientist (€125,000/year): Explores the historical data, identifies features correlated with fraud, and develops and validates several candidate models (e.g., Gradient Boosting, Neural Network) to identify the most predictive ones. Their deliverable is a model file and a detailed report on its accuracy and fairness.
• 1 Senior Machine Learning Engineer (€130,000/year): Takes the winning model from the DS. They build a secure, scalable API around it, integrate it with the claims processing workflow, and set up monitoring to track its performance and detect data drift.
• 1 Product Manager (part-time): Defines success, prioritises features, and ensures the final solution meets the needs of the fraud investigators.

This team structure ensures that all aspects of the problem—data foundation, statistical modelling, and production robustness—are handled by experts. While the upfront salary cost seems higher, this is the structure that actually delivers a working, valuable system. Investing in a modern data platform is the prerequisite for this kind of success.

Frequently asked questions

Should we hire a data engineer or a data scientist first?

You should hire a data engineer first in almost every case. A data scientist's primary value comes from analysing clean, accessible, and reliable data to uncover insights or build models. Without a data engineer to build the foundational pipelines and data warehouse, the data scientist is forced to spend the majority of their time on low-level data extraction and cleaning—tasks they are not specialised for. This leads to brittle, non-reproducible work and extreme inefficiency. Investing in the data foundation first unlocks the full potential of every subsequent data hire.

Key takeaways

• Roles are distinct specialisations: Data Engineers build the system, Data Scientists generate insights, and ML Engineers productionise the output. Don't expect one person to be an expert in all three.
• Hire a Data Engineer first: Building a solid data foundation is the most critical first step. Hiring a data scientist without data infrastructure is a recipe for frustration and wasted investment.
• Structure follows strategy: Your team topology (centralised, embedded, or hybrid) should match your company's size, maturity, and goals. The hybrid model is often the most effective for scaling organisations.
• Deliverables define the role: Judge the function by its outputs. DEs deliver pipelines and platforms, DSs deliver insights and models, and MLEs deliver production AI services.
• Data is a product, not an IT cost centre: Your data platform team should be run like a product team, with a roadmap, agile processes, and a clear focus on delivering value to the business.
• Avoid the "unicorn" hunt: Building a team of specialists who collaborate effectively is far more scalable and robust than searching for a single person who can do it all.

Defining these roles and structuring your team correctly is a foundational element of a modern data strategy. It's the difference between a data function that fuels growth and one that becomes a bottleneck. If you are in the process of defining this strategy or scaling your team, a brief discussion with experienced practitioners can help clarify the optimal path for your specific context.