Salary Expectations in Data Science: The Untold Work

The number is real, the context is missing

Every year a new salary survey circulates, and every year I see the same headline figure repeated without qualification: data scientists earn a healthy salary, comfortably above the median for graduate roles. That figure is not wrong. It is just doing far less work than people assume. A single reported average, or even a median, collapses together a machine learning engineer building recommendation systems at a large platform, a data scientist writing SQL reports for a mid-size retailer, and a research scientist prototyping models that may never ship. These are different jobs with different titles that happen to share a job description template.

The problem is structural rather than deliberate. Salary surveys ask people to self-report a title and a number, and titles are inconsistent across companies. One organisation calls a role data scientist when the day-to-day is closer to analytics engineering: writing dashboards, maintaining pipelines, answering ad hoc questions from stakeholders. Another organisation gives the same title to someone doing applied research, reading papers, running experiments, and occasionally deploying a model that touches real users. Both people answer the same survey question with the same job title, and the resulting average tells you almost nothing about which job you are actually being offered.

Consider a concrete illustration. Suppose a survey samples three hundred people with the title data scientist and reports an average salary of forty-two thousand pounds. If a hundred of those people are early-career analysts doing largely descriptive work, a hundred are mid-level practitioners building and maintaining models, and a hundred are senior specialists leading technical strategy, the average is a blend of three genuinely different labour markets. A candidate entering the field sees forty-two thousand and calibrates expectations against it, not realising that the entry tier of that distribution might sit well below the figure, while the number is pulled upward by a smaller group of senior people. The average is accurate and also misleading, both at once.

What the figure hides about the work itself

Beyond the compression of titles, the number says nothing about variance in the work itself, and this is the part that affects day-to-day satisfaction far more than pay. Two roles can pay identically and involve completely different proportions of time spent on modelling versus data wrangling versus meetings versus maintenance. I have seen estimates, informal but widely echoed by practitioners, that a large share of a typical data scientist's week goes into cleaning data, negotiating access to it, and understanding what it actually measures, rather than building or evaluating models. The modelling is often the smallest and most interesting slice of the job, and it is the slice that job adverts emphasise almost exclusively.

This mismatch between advertised work and actual work has a direct financial parallel. Suppose two roles both advertise a salary of thirty-eight thousand pounds. Role A turns out to involve mostly maintaining existing pipelines and fixing broken dashboards when upstream schemas change. Role B involves genuine experimentation: designing a controlled comparison between two candidate models, choosing a leakage-aware validation split, and communicating trade-offs to stakeholders who will act on the result. Both roles pay the same, but the skills you build, the seniority you accrue, and your market value in three years will diverge sharply. The salary figure treats these as equivalent because it only measures the number on the contract, not the shape of the work that number is buying.

There is also a quieter cost that never appears in a survey: the emotional weight of ambiguous impact. In many data science roles, the connection between your work and a measurable business outcome is loose and delayed. You build a churn model, it gets reviewed, perhaps it gets partially adopted, and six months later nobody can say with confidence whether it changed anything, because the team never set up a proper evaluation against a baseline or a holdout period. This is not a failure of the individual scientist; it is a structural feature of how many organisations deploy analytical work. But it means the psychological return on the job, the sense of visible progress, can lag well behind what the salary figure implies about the seniority and impact of the role.

A worked comparison: two offers, same number, different futures

Say you are comparing two offers, both at thirty-six thousand pounds, both titled data scientist. Offer one is at a small analytics team inside a retail company, reporting to a marketing manager, with the mandate to build weekly reports and the occasional forecasting model using a spreadsheet-adjacent toolchain. Offer two is at a slightly larger firm with an established data platform, reporting to a lead data scientist, with structured code review, a proper train and test split enforced by team norms, and exposure to model monitoring once things reach production. The salary line is identical. The trajectories are not.

In the first role, you may become very fast at producing reports, but the skills you accumulate are narrower and harder to transfer into a technically demanding role later. In the second, you accumulate habits around evaluation rigour, version control, and communicating uncertainty that compound over several years and materially raise your ceiling for future roles. If you only compare the number on the offer letter, you will treat these as a coin flip. If you ask about the actual workflow, who reviews your validation approach, how model performance is checked before and after deployment, you get a much better signal about which offer is worth more over a five-year horizon, even though the immediate pay is the same.

The practical way to interrogate an offer, then, is to ask questions that a salary figure cannot answer. What does a typical week actually involve, broken down roughly by proportion of time? Who reviews modelling decisions, and is there a norm around validation methodology? What happens to a model after it ships, is there any monitoring, or does it simply run until someone notices it has drifted? The answers will not show up in any survey, but they predict your actual experience and your future earning trajectory far better than the headline number does.

The practical takeaway

Salary figures are not useless, but they are a summary statistic over a population that is far more heterogeneous than the single title suggests, and summary statistics discard exactly the variation you need to make a good decision. Before accepting or comparing an offer, look past the number and ask about the composition of the work: how much is genuine modelling versus maintenance, how rigorous is the evaluation culture, and how much ambiguity exists between your work and its measurable outcome. A slightly lower salary attached to a role with strong technical practices will often serve your career better than a slightly higher salary attached to a role that teaches you little beyond how to keep an existing system running.