A data scientist spends close to 45 percent of the workday preparing data, not training models. You already do the harder version of that job every time you chase a metric across three systems that disagree about what happened. This series starts from that overlap. If you run infrastructure, keep an SRE rotation, or administer VMware, you are not starting a data science career from zero; you are missing a specific half of one, and this part maps exactly which half.

What a data scientist is paid to produce

Strip away the tooling and a data scientist is paid for one thing: a decision that someone acts on, backed by data rather than opinion. Will this customer churn, so should we call them. Is this transaction fraud, so should we block it. How many nodes will we need in March, so what do we buy in January. That model is only a means to the decision, and usually the smallest part of the work.

Take the capacity question, because it is one you have answered by gut for years. A data scientist turns it into a forecast: gather two years of utilisation, account for seasonality and growth, fit a model, and attach a confidence range so finance understands the risk of buying too few or too many. Same question you field every planning cycle, now answered with a number and an error bar instead of an educated guess. Its value is not the algorithm, it is that the answer can be checked, argued with and improved, which is what turns an opinion into a decision a business will fund.

Anaconda’s State of Data Science survey has measured the split for years, and it stays stubborn: around 45 percent of the day goes to loading and cleaning data, with cleaning and organising alone above 26 percent. Building and selecting the model is a minority of the time. That famous claim of 80 percent spent cleaning is an exaggeration of a real pattern, and the truer number, closer to 45, is still the largest single slice. If you have ever spent a week reconciling timestamps across two monitoring systems, that slice is already familiar work.

Where your current work already overlaps

Four operational habits carry over almost untouched. First, data plumbing: pulling data from SQL, APIs, exports and log stores, joining sources that were never meant to meet, and noticing when a field is quietly lying. That is the 45 percent slice, and you have done it under time pressure. Second, systems thinking: a data pipeline fails the way a service fails, in the seams between components, and you already debug by isolating stages rather than staring at the whole. Third, production discipline: version control, reproducibility, rollback, monitoring and on call are not data science inventions, they are yours, and they are exactly what separates a model that survives contact with production from a notebook that does not. Fourth, the incident instinct: when a stakeholder is standing over you asking why the number moved, you keep working the problem instead of freezing, and that composure is rarer among new data scientists than any algorithm.

None of this is a consolation prize. That Data Science Series spends its back third on serving, monitoring and pipelines, precisely because most data scientists reach production weak in the very skills you use daily. You are entering from the end most people struggle to reach.

A concrete example makes the transfer obvious. A PromQL query that rates and aggregates a counter across labelled series is the same operation as a pandas groupby that resamples and aggregates a column across categories; the syntax differs, the thinking does not. When Part 9 introduces pandas, you will recognise it as a query language you have used for years wearing different clothes. Much of your first month of study is relabelling, not learning from scratch.

flowchart LR
  A[Map and mindset] --> B[Foundation you half have]
  B --> C[Close the ML gap]
  C --> D[MLOps, your strength]
  D --> E[Projects on infra data]
  E --> F[Land the role]

Gaps you will feel in the first month

Honesty matters more than encouragement here, so name the gaps plainly. Statistics is the first: sampling, distributions, confidence and the difference between a real effect and noise. Infrastructure work rewards determinism, and statistics asks you to reason about uncertainty instead, which is a genuine mental shift. Modelling is the second gap: regression, trees, gradient boosting, evaluation, and knowing which to reach for. That toolkit is learnable in weeks, not years, but it is new. A third gap surprises people: mindset. You are trained to want five nines. A model that is right 92 percent of the time can be a triumph, and learning to ship something that is usefully wrong, then measure and improve it, cuts against every instinct that keeps a platform up.

None of the three gaps is a wall, and it helps to size them honestly. Statistics is weeks of focused study to working competence, not a degree. That modelling toolkit is a handful of algorithms you will reuse constantly, learnable by building rather than reading. Mindset is the slow one, because it is a habit rather than a fact, and it shifts only by shipping a model, watching it be wrong in a survivable way, and fixing it. That loop is exactly what the back half of this series puts you through on purpose.

A day in each role, side by side

Put the two days next to each other and the overlap stops being abstract. Same shape of work, different object: you keep a system healthy, a data scientist keeps a decision honest.

What separates the columns is the object of the work, not its rhythm. You keep a system honest against reality; a data scientist keeps a claim honest against data. Both jobs live or die on the same trait, a refusal to trust a number until you have seen where it came from. That habit is the hardest thing to teach a fresh graduate in a twelve week bootcamp, and it is the strongest card you carry into the change.

Three jobs hiding under one title

Data scientist is a loose title covering at least three roles, and knowing which one you are aiming at changes what you study. A data analyst answers what happened, mostly with SQL, dashboards and clear communication. A data scientist answers what will happen or what we should do, adding statistics and modelling. A machine learning engineer makes models run reliably in production, which is the role closest to what you already do. Many infrastructure people find the fastest, best paid landing is the machine learning or MLOps engineer path, because it rewards the operational half you bring and asks for less depth in research statistics. That Data Science Series opening part pulls these three apart in detail, and the AI Engineering Series is effectively the deep version of the engineering track.

Naming the target early also protects your time. Research heavy roles lean on statistics and experimentation you would build slowly; machine learning and platform roles lean on shipping, reliability and cost, which you can demonstrate almost immediately. Pointing your study and your portfolio at the second group means every project you build doubles as proof you can do the job, rather than a certificate that says you studied it. That distinction, evidence over credentials, is the one hiring managers weight most heavily for career changers.

Skill map from infrastructure to data science

Keep this table. It is the reference this whole series is built on: what you already own, what it becomes, and how much new learning each one needs. Reading down the last column tells you where to spend your months.

Where to start, and what to ignore for now

Common advice tells career changers to grind statistics and machine learning theory first, then build Kaggle notebooks. For someone coming from operations, that order wastes your advantage and front loads your weakest area while you are least motivated. Lead instead with the half you already own. Reframe the telemetry you touch daily as a dataset, get it into Python, and only then close the statistics and modelling gap with a concrete project in mind. A realistic part time transition runs roughly 9 to 18 months, and the people who stall are almost always the ones who started with theory and never shipped anything.

Sequence matters more than pace. Reframe your data, get it into Python, and build one small honest thing before you open a statistics textbook, because motivation follows visible progress and dies in abstraction. Keep your current job while you do it, since the move is far easier funded and far less frightening when you practise on systems you already understand than when you have quit to study distributions in the dark. Every part of this series is built to be done on evenings and weekends, against data you already have.

Next part turns this into a plan you can act on, auditing the skills you already have against a real data science job description so the gaps are specific rather than vague.

References

• Anaconda, State of Data Science report, time spent on data preparation
• Data Science From Zero to Architect, the Complete Guide
• AI Engineering From Zero to Production, the Complete Guide

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts