A mid-sized European logistics company wants to predict late deliveries. Customers complain, penalties under service-level agreements are growing, and the leadership team has read that machine learning can flag risky shipments before they go wrong. The head of people is asked to hire a data scientist. The job ad lists Python, gradient boosting, time series forecasting and “PhD preferred”. Four months later an excellent candidate starts.
The first week goes on getting read access to the transport management system. The second and third on discovering that shipments booked through the customer portal and through account managers carry different customer IDs, and that “delivered” means “scanned at the depot” in one country and “signed for by the customer” in another. In month two the new hire writes scripts that export data every night into a shared drive, because there is nowhere else the data can meet. In month five there is a first model, but the operations team does not trust it: its late-delivery rate does not match the figure in the weekly operations review. After a year the data scientist leaves and updates their profile to say “built data pipelines”.
This is an illustrative scenario, not a description of any particular company, but the mechanism is easy to recognise. This article is for CTOs, heads of IT and HR business partners who need to fill a first or next data role. The thesis: the order in which you hire a data team is set by your data maturity, not by board ambition or a fashionable job title. In most organisations that are just starting, the first data hire should not be called a data scientist. But the rule cuts both ways: in a company that already has trusted data and a well-framed question, hiring yet another data engineer instead of a data scientist is the same mistake in reverse.
What does a data scientist actually do, and why is the title misleading?
The most concise definition comes from the US Bureau of Labor Statistics, whose Occupational Outlook Handbook describes data scientists as people who use analytical tools and techniques to extract meaningful insights from data. The same source reports a median annual wage of USD 120,230 in May 2025, 275,600 jobs in the occupation, and projected employment growth of 35% between 2025 and 2035, much faster than the average for all occupations. Those numbers explain why the title is attractive both to candidates and to companies that want to signal they are “doing something with data”.
The definition, however, carries a hidden assumption: that the data from which insights are extracted already exists, is accessible and can be trusted. A data scientist, in the strict sense, works on data, not on building it. They form a hypothesis, choose a statistical method or a model, design an experiment, test whether the model beats a simple rule, and explain the result to the people making decisions. Their output is an answer to a question, or a prototype model with an honest assessment of its quality.
The title misleads because in the market it covers at least three different jobs. The first is analytics: reports, metrics, answers to “how many, where, when”. The second is data science proper: predictive models, experiments, causal inference. The third is engineering: building data pipelines and deploying models. A “data scientist” ad at a company with no shared data layer is in practice looking for someone to do the first and third jobs, described in the vocabulary of the second. That is where the disappointment on both sides comes from.
For an HR business partner the practical conclusion is simple: before writing the ad, ask the hiring manager what specific output they want to see after three months. If the answer is “a delivery performance report everyone agrees on”, that is not a data scientist role. If it is “a model that flags late shipments better than our current rule”, it is, provided the data for that model already exists.
How do data engineers, data scientists and ML engineers differ day to day?
The easiest way to tell the roles apart is by what each delivers and who gets the call when something breaks. Titles vary between companies; accountability varies much less.
A data engineer builds and runs the path data takes from source systems to the place where it can be used. They pull data from the ERP, the CRM, the e-commerce platform and partner systems, load it into a warehouse or a data lake, keep pipelines running every day, and react when a source system changes a table structure. They are accountable for data being complete, current and consistent. When Monday’s dashboard is missing weekend data, their phone rings. Our glossary entry on data engineering covers the discipline in more depth.
A data scientist works on data the engineer has prepared. They are accountable for the correctness of the conclusion: whether a result is statistically meaningful, whether the model is learning from information that will not exist at prediction time, whether the experiment was designed properly. When a model predicts badly, the question “why” goes to them.
An ML engineer is accountable for the model working in production as well as it did in the notebook. They build how predictions are served (an API, batch scoring, integration with an application), monitor prediction quality and input data drift, version models and enable safe rollback. When a model worked last week and returns nonsense today, it is their on-call shift. The discipline around this is known as MLOps.
Between these roles sit two more that often solve the problem more cheaply than expected. A data analyst answers business questions with reports and queries. An analytics engineer is a role popularised by dbt Labs: someone who transforms, tests and documents data to provide clean datasets to end users, bridging the gap between data engineering and analysis. In many companies that are just starting out, an analytics engineer, or a data engineer with strong SQL, is the most important missing link.
The distinction matters for hiring for a simple reason: each of these people will be unhappy and ineffective when given another’s job. A data scientist forced to write pipelines does it worse than an engineer and leaves sooner. A data engineer asked for a predictive model builds something that runs but lacks a rigorous assessment of whether it helps. An ML engineer with no model to deploy builds a platform nobody uses.
Why does hiring order follow data maturity rather than ambition?
Because each role needs something the previous role produces. Monica Rogati described this in 2017 in “The AI Hierarchy of Needs” as a pyramid. At the bottom is data collection: knowing which data you need, whether it is available, and whether interactions are being logged at all. Above that is data flow: reliable pipelines, storage, easy access. Then exploration and cleaning, then analytics, meaning metric definitions and preparing training data, then experimentation and simple baselines, and only at the very top advanced machine learning. Rogati writes plainly that more often than not companies are not ready for AI, and that some have hired their first data scientist to less-than-stellar outcomes.
The same conclusion, framed from an engineering perspective, appears in Martin Zinkevich’s “Rules of Machine Learning” published by Google. Rule one: do not be afraid to launch a product without machine learning, because machine learning requires data. Rule two: first design and implement metrics, and track as much as possible in your current system before formalising what the learning system should do. Rule four: keep the first model simple and get the infrastructure right. The order of those rules is a hiring sequence in miniature: first someone who builds logging and metrics, then someone who builds a simple model, then someone who makes the infrastructure around the model solid.
A third source shows why the last step is not a detail either. A Google team led by D. Sculley described in “Hidden Technical Debt in Machine Learning Systems”, presented at NIPS 2015, how easy it is to incur massive ongoing maintenance costs in real-world ML systems. The paper lists data dependencies, hidden feedback loops, undeclared consumers of model outputs, configuration issues and changes in the external world. None of these risks concerns the choice of algorithm. All of them concern data and production, which is the work of data engineers and ML engineers.
Board ambition matters because it sets the goal. But the goal does not change the order of the steps. A company that wants to predict late deliveries but has no single source of shipment events must build that source first, however much it wants the prediction. The question is not “should we hire a data scientist” but “which level of the pyramid are we standing on today”.
How can you assess your company’s data maturity in an hour?
You do not need a consultant or an audit for this. One meeting with someone in IT who knows the systems and one business process owner who has a problem to solve is enough. Ask them seven questions and write down the answers without flattering yourselves.
- Can we answer a simple numerical question within a day, such as how many active customers we had last quarter? If the answer needs several people, several exports and a debate about what “active” means, you are near the bottom.
- Does data from different systems meet in one place automatically? A warehouse, a lake, even a single reporting database. If it meets in a spreadsheet by hand, that is not yet a data layer.
- Do the key metrics have one written definition? When sales and finance report different revenue for the same month, the problem is not the model.
- Is someone accountable for data quality, and do they know it? A named person who receives the ticket “since March this table has been missing every tenth record”.
- Is the data a predictive question would need actually being recorded? Predicting churn requires a history of contacts, complaints and order changes. If nobody records those events, there is nothing to model. In the EU this question has a second edge: under GDPR’s purpose limitation and data minimisation principles, data collected for one purpose cannot simply be repurposed for another, so “we have it somewhere” is not the same as “we can use it”.
- Is there a specific question a report cannot answer, with an owner who will change a decision based on the answer? “We want to use AI” is not such a question. “We want to know which shipments to reroute tomorrow morning to avoid SLA penalties” is.
- Is any model or data-driven rule running in a process today, and does someone maintain it? A simple scoring rule in the CRM counts.
The answers usually fall into one of four levels. Level 0: data scattered across systems and spreadsheets, no shared layer, no shared definitions (no to questions 1–3). Level 1: a shared data layer and reports exist, but trust in them is limited and nobody owns quality (yes to question 2, no to 3 or 4). Level 2: data is trusted, definitions and a quality owner exist, and a specific predictive question with an owner has emerged (yes to 1–6). Level 3: a model or rule runs in a process and needs maintaining, improving and multiplying (yes to 7).
One caveat: score pessimistically. Companies tend to overrate their own maturity by one level, because the warehouse “exists” although nobody uses it, and definitions “exist” although every department has its own. If you hesitate between two levels, pick the lower one. Erring low costs a few weeks of engineering work that has to be done anyway. Erring high costs a year of someone hired to do work that cannot be done yet.
Who should you hire first at level zero, when data still lives in source systems?
At level zero the first hire should be a data engineer, or, in a smaller company whose data fits in one warehouse and a handful of sources, an analytics engineer with strong SQL and the ability to talk to the business. The first months’ task is modest to describe and hard to deliver: bring data from the two or three most important systems into one place, agree definitions of a few key metrics with process owners, and deliver a few reports the leadership team will believe.
This choice is often challenged on the grounds that a data engineer “will not deliver business value” because they deliver infrastructure rather than answers. That is a misunderstanding. The first shared, trusted figure for revenue, margin or on-time delivery is, for many leadership teams, a bigger change than any model, because it ends the monthly argument about whose numbers are right. Zinkevich puts it in rule two: before you build a learning system, measure what is happening in the current one. Without that you cannot even tell whether a model improves anything.
Our article on AI team structure sets out the core AI roles and how team size should grow with maturity. This article narrows the question to the very first data hires and adds one condition worth taking seriously: the first data engineer needs explicit authority to request changes in source systems, otherwise they will sit in other teams’ priority queues. Authority is what makes the first hire effective; maturity is what decides which hire it should be.
At level zero, do not hire a data scientist or an ML engineer yet. If the board is pushing for “something with AI”, the more honest response is a short exploratory project on data that already exists, given to an external specialist for a few weeks, rather than a permanent role that spends six months building data. How to split data work between an internal team and outside help is covered in our piece on data management services.
At level one, where a shared data layer exists but trust is limited, the second hire is usually a data analyst or another engineer, not a data scientist. What is missing is not models but people who use the data every day, report errors and build the habit of working with numbers. A data scientist at this level spends most of their time validating data, and every result they produce is dismissed with “the data is wrong”. A well-designed data model helps a great deal here; why its mistakes cost more than a poor technology choice is the subject of our article on data modelling for business.
When is a data scientist the right first hire?
This is where the thesis cuts the other way, and it is the part most often ignored. The now-popular advice “always start with a data engineer” is as mechanical as the earlier fashion of “hire a data scientist”. There are situations where a data scientist is the first missing role and another engineer would be wasted money.
First situation: the company is at level two. It has a warehouse that departments actually use, definitions are written down, someone owns quality, and reports have long answered “how many and where”. A different kind of question appears: “what happens if” or “who is likely to”. Which customers are likely to churn, what demand will a new product see, did a price change lift sales or merely coincide with the season. A report will not answer these and neither will another engineer. You need someone who designs an experiment or a model and honestly evaluates the result.
Second situation: the product is data-driven from day one. A company selling scoring, recommendations or forecasts as a service has a different problem from a company that wants to run its warehouse better. Here the methodological question, whether the phenomenon can be predicted with the required accuracy at all, is a question about the viability of the whole business. It must be answered early, before infrastructure is built. A data scientist can work on a sample, even one assembled by hand, and decide whether building infrastructure makes sense.
Third situation: the company needs an answer, not a system. A one-off analysis, for example whether a loyalty programme increases customer value or merely rewards customers who would have spent more anyway, requires causal inference methods, not a data pipeline. Here a data scientist, often on contract, is the right and only hire.
In all three cases, check one condition: does the question have an owner who will change a decision based on the answer? A data scientist without such an owner produces interesting analyses that change nothing, and after a year the data team is seen as a cost rather than an investment. Zinkevich’s first rules are not about algorithms but about objectives and metrics. That is no accident.
When should an ML engineer come before a data scientist?
The classic sequence assumes the model must be invented before it is deployed, so the data scientist comes before the ML engineer. That sequence stopped being obvious once many use cases started relying on ready-made models, bought as a service or downloaded as open-weight models, and adapted to a company’s own data.
If a company wants to use a large language model to classify support tickets, search internal documentation or handle first-line customer queries, it does not need to invent a model. It needs to deploy one: connect it to its own data, build the serving layer, monitor answer quality and cost, handle security and make rollback possible. That is ML engineering, not data science. In this situation the order is: data engineer (the data still has to exist and be accessible), then ML engineer, and a data scientist only when there is a need for rigorous quality evaluation at scale or for fine-tuning on the company’s own data.
The second situation in which the ML engineer comes earlier is level three of the maturity test: the company already has a working model, built by a data scientist or a vendor, and the model starts to degrade. Input data has shifted, the process has changed, nobody is sure which version is running in production. Sculley and his co-authors show this is not an exception but the natural fate of ML systems without engineering around them. Another data scientist in such a company builds another model that will have the same problem a year later. An ML engineer builds the way all models are deployed, monitored and replaced.
There is also the opposite case, in which the ML engineer is hired too early. A company at level zero or one, impressed by an MLOps platform demo, hires an engineer who builds a model registry, training pipelines and monitoring before the first model worth deploying exists. The platform is technically sound and empty. Zinkevich’s rule four says keep the first model simple and get the infrastructure right, but that infrastructure should serve a specific model, not hypothetical future ones.
What does the hiring sequence look like at each maturity level?
The table below brings the previous sections together. Treat it as a starting point for the conversation with your leadership team, not as a recipe, because a specific business question can change any of these recommendations.
| Maturity level | How to recognise it | First hire | Second hire | Do not hire yet | Output after 90 days |
|---|---|---|---|---|---|
| 0: scattered data | A simple numerical question needs several people and exports; no shared definitions | Data engineer or analytics engineer with authority over source systems | Data analyst | Data scientist, ML engineer | Data from 2–3 key systems in one place, written definitions for a few metrics, first trusted reports |
| 1: shared layer, limited trust | A warehouse exists but departments report different numbers; nobody owns quality | Another data engineer or analytics engineer accountable for quality and definitions | Data analyst embedded in a business team | ML engineer | Data quality tests, a named quality owner, reports used weekly by at least one department |
| 2: trusted data, predictive question | Definitions written, data trusted, a specific “who is likely to” question with an owner | Data scientist | ML engineer, once the model has to go into a process | Another platform role without a model | A model or experiment evaluated against a simple rule, and a decision on whether to deploy |
| 3: model in a process | At least one model or rule runs in a process and needs maintaining | ML engineer | Another data scientist for a new question | Another model without engineering around the existing ones | Quality and drift monitoring, versioning, a rollback procedure |
| Exception: off-the-shelf model | A use case built on a large language model or another ready-made model, with no need to build one | Data engineer if data is not accessible; ML engineer if it is | Data scientist for quality evaluation at scale | Data scientist as first hire | A working deployment on production data with quality and cost monitoring |
Two observations about the table. First, moving between levels does not happen through hiring alone. A level-zero company that hires a data scientist does not jump to level two; it has a data scientist at level zero. Second, the last column matters most in the leadership conversation. Instead of approving a headcount, the board approves an output after 90 days and a criterion by which it will judge whether to keep hiring.
How much does each role cost and what does that mean for the budget?
Rates are best taken from one checkable source. On ARDURA’s pricing page a senior data engineer costs EUR 370-520 per day (net, 8 hours) and a lead EUR 520-705 per day. Over 21 working days that comes to roughly EUR 7,770-10,920 a month for a senior. The Python developers page lists senior Python ML engineers at EUR 445-650 per day, or roughly EUR 9,345-13,650 a month on the same 21 days. ARDURA’s pricing does not list a data scientist rate, so we do not quote one here; it depends on specialisation and scope. The factors behind data engineering rates in Poland are covered in our article on data engineering developer rates in 2026.
For a sense of the market behind the US figure quoted earlier: the BLS median of USD 120,230 a year is a salary, not a fully loaded cost, and it excludes benefits, payroll taxes, recruiting fees and the time a role sits empty. Comparing it directly with a contract day rate is not like for like, but it does show why companies in the US and Western Europe increasingly look at nearshore contract specialists for the build-out phase.
Rates, however, say less than the cost of hiring in the wrong order. Take the opening scenario as an illustration. A data scientist hired at level zero spends the first six months mostly on engineering work. We do not know their exact rate, but even assuming they cost the same as a senior data engineer, the company pays for half a year of work an engineer would have done faster and more durably, with monitored pipelines rather than nightly exports to a shared drive. Add the cost of recruiting and onboarding a replacement if the person leaves, and the cost of the leadership team’s lost confidence in the whole data area. That last one is often the highest, because the next data budget request meets the argument “we already tried that”.
The practical budgeting rule follows: at levels zero and one the data budget is mostly an engineering budget, and a “data scientist” line should appear only in next year’s plan, conditionally, once the level-two criteria are met. At levels two and three the proportions reverse, and that is where investing in data scientists and ML engineers pays off.
It is also worth counting the costs that do not appear in rates. The business process owner’s time, spent agreeing definitions and answering questions, is real and often larger than the plan assumes. Warehouse, orchestration and model service licences grow with volume. For use cases based on ready-made models, usage costs are often underestimated because the pilot was priced on a small sample. Put these lines in the plan next to the headcount rather than discovering them after the first quarter.
How do you write a job ad that attracts the right role?
The job ad is the first filter and the most common place where hiring order goes wrong. The title “data scientist” attracts research-minded candidates who want to work on models. If the real job is building pipelines, the ad attracts the wrong candidates and puts off the right ones, because data engineers have little reason to open an ad with that title.
An HR business partner can use a simple method: open the ad with the output, not the technology list. Instead of “we are looking for a data scientist with Python, SQL and machine learning”, write: “In your first quarter you will bring shipment data from our transport management system and customer portal into one warehouse, agree a definition of on-time delivery with operations, and build the report that replaces three existing spreadsheets.” The candidate immediately knows whether this is their job, and the hiring manager is forced to say what they really want.
A few specific pointers for each role:
- Data engineer: describe the source systems (ERP, CRM, e-commerce, partner systems), data volumes and whether the candidate will be able to request changes in those systems. Experience with systems the candidate does not control is worth more in this role than familiarity with the newest tool.
- Analytics engineer: emphasise work on metric definitions, data quality tests and documentation, and contact with business teams. This is a role for someone who likes it when the numbers reconcile.
- Data scientist: state the specific business question, describe the available data (history, volume and known gaps) and name the decision owner. A good candidate asks about the data before asking about the technology.
- ML engineer: describe which model has to go into production, in which system, and with what latency and cost requirements. If the model does not exist yet, that is a signal the role may be premature.
Keep the PhD requirement for genuinely research-oriented work. In most business applications it narrows the candidate pool and raises cost without a proportional benefit. A better signal is a candidate’s account of how they checked whether their model beat a simple rule, and what they did when it did not. If you hire internationally, also be precise about location and employment model: a remote contractor in another EU country, a local employee and a contractor engaged through a staffing partner come with different legal and tax consequences, and candidates screen ads on that basis. More on structuring the assessment stage itself is in our guide to assessing data engineering developer skills.
How do you tell a data engineer from a data scientist or an ML engineer in an interview?
Titles on a CV are unreliable, because the same names mean different jobs at different companies. The stories candidates tell, and the questions they ask, are more reliable. A few questions quickly establish who you are talking to.
Ask about the last problem they solved. A data engineer talks about a pipeline that broke because a source system changed format, about duplicate customers, or about cutting load times. A data scientist talks about a question, a hypothesis, a method and whether the result was meaningful. An ML engineer talks about a model that worked in testing but returned poor results in production, and how they found out.
Ask what they would do in their first week. A data engineer asks about source systems, access and data owners. A data scientist asks about the business question and what data exists. An ML engineer asks where the model has to run and how software is deployed today. A data scientist candidate who wants to choose an algorithm in week one, before seeing the data, is a warning sign.
Ask about a failure. A good data scientist can describe a model that did not beat a simple rule and that they recommended abandoning. A good data engineer, a pipeline they designed badly and had to rebuild. A good ML engineer, a deployment they had to roll back. A lack of such stories after several years of experience usually means the candidate has not been close to production.
Set a role-specific practical task. For a data engineer: design a data flow from two systems with different customer identifiers. For a data scientist: here is a dataset and a question; how would you check whether it can be answered, and what is a simple baseline? For an ML engineer: a model works in a notebook; describe what has to happen for it to run in production for a year. The task need not be long. What matters more is what the candidate asks before starting.
An HR business partner does not need to judge the technical correctness of answers; that is the technical panel member’s job. They can, however, check whether the candidate’s stories match the output described in the ad. It is the simplest filter against hiring the right person for the wrong job.
When should you hire permanently and when should you bring in a contract specialist?
The decision about role order and the decision about employment model are linked. The first hire at a given maturity level is often a build job: something has to be put in place and then maintained with less effort. Such work suits an external specialist well, while a permanent team is best built around roles whose work never ends. When the question is a one-off feasibility check rather than a permanent role, see when to hire machine learning consulting.
Some situations where a contract beats a permanent hire. Testing whether a predictive question is viable before hiring a permanent data scientist: a few weeks of a specialist’s work on existing data tells you whether a team is worth building. Building the first data layer when the company does not yet know how large an engineering team it will need for ongoing maintenance. Putting the first model into production when the company has a data scientist but not yet a full-time ML engineering workload. Covering a recruitment gap: hiring a senior data specialist can take months, and the work does not wait.
With staff augmentation, ARDURA provides a specialist in about two weeks, with a two-week free replacement guarantee, a replacement within 5 working days if the specialist leaves during the engagement, and a 30-day notice period. For a company unsure of its maturity level, that flexibility matters in practice: if after three months it turns out a different profile is needed, the change does not require terminating an employment contract, which in several EU countries is a slow and costly process.
Permanent employment wins where knowledge of the company’s data is capital that should not walk out the door: the data quality owner, the person who knows the definitions and history of the metrics, the data team lead. A good setup often combines both: a permanent person accountable for the data and its meaning, and external specialists for build work and for roles needed only for a while at a given maturity level.
One warning: an external specialist does not replace authority. If the first data engineer, permanent or contract, has no right to access source systems and request changes in them, they will get stuck just the same. Authority has to be secured on the company side before the specialist starts.
What are the key takeaways before filling your first data role?
The question “data scientist, data engineer or ML engineer” has no single answer, but it has a single method: first establish which data maturity level your company is at, then hire the role that will move it to the next. The order follows from the fact that each role needs the previous role’s output: a data scientist needs trusted data, and an ML engineer needs a model worth deploying.
Remember six things. First, tell roles apart by output and accountability, not title: the data engineer owns the data, the data scientist owns the correctness of the conclusion, the ML engineer owns the model in production. Second, assess data maturity with seven questions and pick the lower level if you hesitate. Third, at levels zero and one hire engineering and analytics, not a data scientist. Fourth, at level two hire a data scientist, but only for a specific question with a decision owner; another engineer would then be the mistake. Fifth, with off-the-shelf models and at level three, the ML engineer comes before the data scientist. Sixth, write job ads around the output after 90 days, and ask the board to approve that output rather than a headcount.
If you want to test whether a predictive question is viable before making a permanent hire, or you need a data engineer for the build-out of your first data layer, see how we provide data and ML specialists through staff augmentation, or book a call. We start by establishing which level you are at and what output you need after the first quarter.