Two numbers published a year apart tell you where this career is heading. Stack Overflow reported an average United States salary of about 159,000 dollars for data scientists in its 2024 developer survey and about 145,000 dollars in 2025, a fall of roughly nine percent. In that same 2025 survey they stopped counting data scientist and machine learning specialist as separate roles and folded both into an AI/ML engineer group, which reported about 189,500 dollars.

Nothing about the work got less valuable in twelve months. What changed is which version of the work gets paid for. A gap of roughly 44,500 dollars sits between a title that is being absorbed and a title that is doing the absorbing, and that gap is almost entirely about scope: whether you own a model or you own the thing that runs models. This last part is about crossing it.

Numbers behind the job title change

Two independent sources point the same direction, and they disagree in a way that is informative rather than confusing. Bureau of Labor Statistics data describes a large, fast growing, generalist occupation: a May 2024 median wage of 112,590 dollars for data scientists, 34 percent projected growth to 2034, and about 23,400 openings a year. Compare that with computer and information research scientists, a much smaller and more senior classification, at a 140,910 dollar median, 20 percent growth, and only about 3,200 openings a year.

Read those two rows together and the shape of the market appears. Volume sits at the entry and mid levels. Money sits where the population is thin. A roughly seven to one ratio in annual openings between the generalist role and the senior research classification is the clearest statement anyone has published of how narrow the top of this profession is. That narrowness is the opportunity, not the discouragement, because the barrier is evidence rather than headcount.

What a data science architect owns

Job adverts describe this badly, so here is a working definition from practice. A data science architect owns the decisions that are expensive to reverse. Which serving pattern the organisation standardises on. Whether a feature store is worth its operating cost. What the retraining cadence is and who pays for it. Which model risks require independent review before release. How much GPU capacity gets reserved and how much stays on demand.

None of those are accuracy questions. Every one of them is a commitment question, and commitment questions have a property that model questions do not: you find out whether you were right eighteen months later, in front of people who remember what you promised. That is why the register of this job changes. A senior data scientist argues with data. An architect argues with a finance partner, a risk officer and three engineering leads, and has to be right in writing.

Our running churn project is a compact illustration. By Part 25 we had a model in production with drift monitors on it, and by Part 28 we had sized the compute underneath it. A practitioner asks whether the model still separates churners from non churners. An architect asks a different question: if fourteen more teams want what this team has, does the pattern we chose scale to fourteen, or did we build something that only works once. Answering that badly is how organisations end up with nine bespoke pipelines and no platform.

Four ladders out of senior data scientist

Careers branch here, and most people branch by accident because a vacancy appeared. Four routes are genuinely distinct, and they reward different things.

flowchart LR
  A[Senior data scientist] --> B[Data science architect]
  A --> C[ML engineering lead]
  A --> D[Applied research]
  A --> E[Analytics or DS management]
  B --> F[Owns platform, cost and risk commitments]
  C --> G[Owns serving, pipelines and reliability]
  D --> H[Owns method quality and publication]
  E --> I[Owns people, hiring and roadmap]

Here are my verdicts, since a neutral survey would waste your time. Architect is the ladder I would pick for most people reading this, because it compounds: every platform decision you make correctly buys credibility for the next one, and the skill transfers across employers and even across domains. ML engineering lead is a close second and is the better choice if you enjoy systems more than stakeholders, with the honest caveat that it pulls you toward software engineering depth and away from statistics.

Applied research is the one I would avoid unless you are joining an organisation that genuinely funds it. Outside a handful of labs, research titles in industry quietly become delivery roles with worse tooling, and BLS data hints at the scarcity: roughly 3,200 annual openings in the research classification against 23,400 in the general one. Management is the one I would avoid entering by default. Taking it because it was offered, rather than because you want it, costs you technical depth within about two years, and coming back is much harder than leaving.

Skills gap between practitioner and architect

Nobody hands you a list of what changes, so here is mine, built from watching people make the jump and from making an expensive mistake myself.

My own worst call sits in the bottom row of that table. I sponsored a feature store rollout on the strength of a proof of concept that took two weeks and looked excellent. Eleven months later, two teams out of nine had adopted it. Ingestion for the remaining seven needed backfills nobody had budgeted, and the platform team was spending roughly a day and a half a week on support for a system serving under a quarter of its intended users. We reversed it and shipped a shared feature library instead, which covered most of the benefit at a fraction of the running cost. Cost of the wrong turn was close to a full engineer year.

What I got wrong was not the technology assessment. It was scoping adoption from a friendly pilot team rather than from the least willing team, and never writing down the adoption number that would have triggered a stop. If I had committed in advance to a review at six months with a threshold of five teams onboarded, we would have cut it five months earlier. I now write that trigger into every platform decision record before the build starts, and I would tell anyone moving into this role to do the same. Reversal criteria written in advance are the single cheapest thing an architect can produce.

Evidence that gets you the role

Interview panels for architect roles do not test whether you can build a gradient boosting model. They test whether your judgement survives contact with constraints, and they do it by asking about something you actually decided. Which means the preparation is not study, it is collection. Most strong practitioners have made two or three real platform calls and can remember none of the numbers, so the story lands as an opinion rather than as experience.

Keep a decision log. One page per decision: what was proposed, what you chose, what you rejected and why, what it cost, what the reversal trigger was, and what happened. Six of those, covering a serving pattern, a build against buy call, a cost reduction, a risk or governance call, a retraining policy and one reversal, will out perform any certification in an interview. A reversal entry is worth more than the five successes, because it proves you measure outcomes rather than defend choices.

One more piece of evidence carries disproportionate weight, and it comes from the analyst side of the house rather than the modelling side. Being able to state a business metric precisely, and defend how it is computed, separates people who are trusted with budget from people who are not. If that muscle has weakened while you were modelling, my statistics an analyst actually uses and data modeling basics parts from the Data Analyst Series are the fastest refresh, and both take under an hour.

Twelve month plan from here

Concrete beats aspirational, so here is a year laid out in quarters. It assumes you are employed as a data scientist and cannot simply change jobs to acquire scope.

Notice what is absent from that plan. No certification, no new framework, no fifth gradient boosting library. Technical study still matters, but by this stage it is maintenance rather than progress. Two hours a week reading primary documentation and release notes for whatever your organisation actually runs will keep you current. Everything else in the year goes into scope.

Where thirty parts have taken you

Worth a moment to look back, because the shape of the series was the argument. We began in Part 1 with what the job is, moved through the Python working setup and data handling, then the statistics and core models that most jobs actually run on, then deep learning and the specialised areas, then production, and finally platform, cost and governance. A single customer churn project ran the whole way through, from first load to monitored production to the compute bill underneath it.

flowchart TD
  P1[Phase 1 Foundations, parts 1 to 6] --> P2[Phase 2 Statistics and core ML, parts 7 to 13]
  P2 --> P3[Phase 3 Advanced ML and deep learning, parts 14 to 20]
  P3 --> P4[Phase 4 Production and MLOps, parts 21 to 26]
  P4 --> P5[Phase 5 Architect level, parts 27 to 30]
  P5 --> N[Next: own one platform decision end to end]

If you worked through it in order, you can now take a business question, get the data, engineer features, choose and evaluate a model honestly, ship it, watch it decay, and reason about what it costs and what it risks. That is a complete practitioner. Everything in Phase 5 was about the layer above, where the questions stop having correct answers and start having defensible ones.

Common ways this move stalls

Three failure modes account for most of the people I have watched get stuck at senior practitioner for five years or more, and none of them is a lack of technical ability.

First is becoming indispensable to one model. If you are the only person who understands the churn pipeline, your employer has every incentive to keep you exactly where you are, and you will be praised for it right up until you notice that nobody has offered you anything bigger. Counter it by documenting yourself out of the job deliberately. Hand the model to a colleague, stay available for questions for a month, then stop. Feeling briefly redundant is the price of scope.

Second is treating cost as somebody else policy. Plenty of very good modellers cannot say what their training runs cost, and that single gap disqualifies them from platform conversations faster than any missing algorithm. Finance partners do not need you to be an accountant. They need you to arrive with a number and a range, which is why Part 28 exists at all. Ask for read access to your own workload billing this week. It takes one email and it changes how people talk to you.

Third, and most common, is confusing being consulted with being accountable. Getting asked for an opinion on a platform decision feels like progress. It is not. Accountability means your name is on the document, the reversal trigger is yours, and you report on the outcome. Until that is true, you are advising, and advisers do not get architect offers. When a decision is being made near you, ask to own the write up rather than to review it. That request is almost never refused, and it is the cheapest promotion lever in this profession.

Recommended next step after this series

Pick the architect ladder, and start the twelve month plan this quarter rather than next. Concretely: in the next four weeks, choose one decision your team is about to make, volunteer to write it up, include a reversal trigger with a number and a date, and circulate it to someone senior enough to disagree. That single page is the smallest complete unit of architect work, and producing it is worth more than another six months of modelling practice.

If you want a second technical direction alongside it, go deeper on cost and serving rather than on modelling. Those are the two areas where practitioners are consistently weakest and where an organisation notices improvement within a quarter. Part 22 and Part 28 are the ones to reread with a pen.

That is the end of the series. Thirty parts, one churn project, and no shortcuts I know of. Write your first decision record this month and reply to tell me what you chose and what you rejected. I read every one.

References

• Data Scientists, Occupational Outlook Handbook, U.S. Bureau of Labor Statistics. Source for the 112,590 dollar May 2024 median wage, 34 percent projected growth from 2024 to 2034 and about 23,400 annual openings
• Computer and Information Research Scientists, Occupational Outlook Handbook, U.S. Bureau of Labor Statistics. Source for the 140,910 dollar May 2024 median wage, 20 percent projected growth and about 3,200 annual openings
• Stack Overflow Annual Developer Survey 2025. Source for the consolidation of data scientist and machine learning specialist into an AI/ML engineer category, and for the reported United States salary averages used in Table 1

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