Most first AI teams are hired in the wrong order. A company decides to "do AI", recruits a data scientist or two with impressive research credentials, and waits for results. Six months later it has notebooks, a promising demonstration and nothing in production, because nobody on the team was hired to build the pipelines, interfaces, evaluation and monitoring that turn a model into a product. A decade ago Google engineers described the problem precisely. In their 2015 NeurIPS paper on technical debt in machine learning systems, D. Sculley and colleagues wrote that "only a small fraction of real-world ML systems is composed of the ML code", and that "the required surrounding infrastructure is vast and complex."
Foundation models have changed which skills a first AI team needs but not that underlying truth. Building an AI team today usually starts with engineers who can build applications on top of existing models, evaluate them and ship them, not with people who train models from scratch. Chip Huyen, whose 2025 book AI Engineering is one of the clearest treatments of the shift, describes AI engineering as focused on "building applications on top of foundation models", through prompt engineering, context construction and parameter-efficient fine-tuning, while traditional machine learning engineering centres on data annotation, feature engineering and model training.
This piece is for founders, CTOs and business-unit heads hiring their first AI team. Its original contribution is a role-sequencing table that sets out which roles to hire at each product stage, what each hire is accountable for, and which roles to defer or skip. The stage boundaries and team sizes are illustrative assumptions, stated so they can be adapted.
Start with the problem, not the people
Martin Zinkevich's Rules of Machine Learning, published by Google, open with advice that remains the best filter for any AI hiring plan: "do machine learning like the great engineer you are, not like the great machine learning expert you aren't." Rule 1 is "Don't be afraid to launch a product without machine learning", and Rule 2 is "First, design and implement metrics." Zinkevich's point is that a simple heuristic often captures much of the value, and that without measurement no one can tell whether a model is an improvement.
Applied to hiring, the rules imply a sequence. Before recruiting anyone with AI in their title, a company should be able to answer three questions: which decision or task will the system improve, how will improvement be measured, and is the data needed to do it available and lawful to use. If the answers are unclear, the first hire is not an AI specialist. It is a product owner with enough technical literacy to define the metric and enough authority to get access to the data.
This also explains a pattern in McKinsey's research. The editor-verified State of AI 2025 survey found that the roughly 6% of respondents it classed as high performers were nearly three times as likely as others to have fundamentally redesigned individual workflows. Workflow redesign is product and operations work. Teams that hire only modelling talent rarely get there.
The roles, defined
Job titles in AI are unstable, so it helps to define roles by what they own.
AI product owner. Owns the problem definition, the success metric, the evaluation set and the decision to ship. In small teams this is often a founder or a senior product manager.
AI engineer. Builds applications on foundation models: prompts, retrieval, tool use, agents, guardrails and the interfaces around them. Huyen's definition of AI engineering describes this role. LinkedIn data reported by IANS in April 2026 showed AI engineering job postings in India up 59.5% year on year, which signals both demand and competition for it.
Data engineer. Owns the pipelines that collect, clean, label and serve data to models, and the permissions around it. In most enterprise AI projects this is the role whose absence causes the longest delays.
Machine learning engineer. Owns training, serving and monitoring of models in production. Google Cloud's MLOps architecture guidance distinguishes this work from that of data scientists, who "focus on exploratory data analysis, model development, and experimentation" and "might not be experienced software engineers who can build production-class services." The ML engineer is the person who closes that gap.
Data scientist or applied scientist. Owns analysis, experimentation and, where needed, custom models or fine-tuning. Valuable when the problem needs a model the market does not offer, or when causal questions about impact must be answered rigorously.
Platform and MLOps engineer. Owns shared infrastructure for many models: pipelines, feature stores, deployment automation and cost controls. Google's guidance describes three maturity levels: level 0, where the process "is entirely manual"; level 1, which automates the training pipeline for continuous training; and level 2, which adds automated CI/CD for pipeline components. Platform engineers matter most when an organisation moves past level 0.
Research scientist. Advances methods. Necessary for companies whose product depends on model capabilities nobody else has; unnecessary for most others.
AI governance and risk lead. Owns policy, documentation, regulatory mapping and incident handling. A separate PanScience Research piece on AI governance for boards covers the oversight structure this role reports into.
A role-sequencing table for building an AI team
The table is an original framework for this piece. Stages describe the product, not the company: a large enterprise launching its first AI product is at stage 1, however big it is. Team sizes are illustrative.
Four principles sit behind the table.
Evaluation is owned from stage 1. The single most useful habit in a first AI team is to build a test set of real examples with agreed correct answers before the prototype is finished. A separate PanScience Research piece on evaluation before deployment covers how to construct one. Without it, every later decision becomes a matter of opinion.
Data engineering comes before machine learning engineering. Teams usually reach the limits of their data before the limits of their models. A strong data engineer at stage 2 removes more risk than a second AI engineer.
Production skills arrive before research skills. The Sculley paper's warning about the surrounding infrastructure applies with special force to systems built on foundation models, where the model is bought and almost all of the work is around it.
Governance is a role, not a review. By stage 3, someone must own the documentation, the regulatory mapping and the incident process. Bolting this on after launch is more expensive than designing for it.
What to skip, or at least defer
Several hires are common, plausible and usually premature.
A chief AI officer before the first product ships. A senior title without a team, a budget or a live system tends to produce strategy documents. The role makes more sense once there are several AI products whose priorities need arbitrating.
Research scientists before data. Hiring researchers before the data pipeline exists leaves highly paid people waiting for inputs. It also shapes the culture of the team towards experiments rather than delivery.
A standalone prompt engineer. Prompting is a skill every AI engineer needs, not a separate job. Teams that separate it create a hand-off where there should be a feedback loop.
A full MLOps platform for one model. Google's level 1 and level 2 automation repays its cost when an organisation runs many models or retrains often. For the first model, a well-documented manual process with good monitoring is usually enough. A separate PanScience Research piece on the unit- cost model for enterprise AI covers when platform investment pays back.
Training a foundation model. For nearly every company, the right first move is to use an existing model, open or proprietary, and invest in data, evaluation and integration. A separate PanScience Research piece on small language models covers when a smaller, specialised model is worth building instead.
Hire, reskill or share
The roles in the table can be filled in three ways, and most organisations should use all three.
Reskilling. McKinsey's report on its State of AI 2022 survey of 1,500 companies, summarised in January 2023, found that reskilling existing employees was the most popular talent strategy, used by nearly half of respondents. Engineers who already understand a company's systems and data can often become effective AI engineers faster than outsiders can learn the business. Product owners almost always should come from inside.
Hiring. The roles hardest to grow internally are production ML engineers and experienced data engineers, because the skills come from having run systems at scale. A separate PanScience Research piece in this cluster on AI talent in India sets out where these engineers currently work and why they are scarce.
Sharing. Some functions a first AI team needs are not AI functions at all: product management, infrastructure, go-to-market, operations, finance and legal. PanScience Innovations reports providing six such shared in-house functions, product, technology, GTM, operations, finance and legal, to the ventures it builds; this is company-reported. The relevant point for any organisation is that a first AI team does not need to own everything it depends on. An enterprise can draw on its central security, legal and data platform teams; a startup can use fractional or shared specialists for legal, compliance and finance. What the AI team must own directly is the product, the evaluation and the production engineering. A separate PanScience Research piece on the venture studio model covers how shared functions are governed across a portfolio.
How the sequence differs for enterprises and startups
The same table applies to both, but the bottlenecks differ.
In enterprises, the stage 0 to stage 2 transitions are slowed by access to data and by approvals. The most valuable early hire is often a data engineer who knows the enterprise's systems, and the most valuable early ally is the security team. A separate PanScience Research piece on AI operating models covers whether the team should sit centrally or within a business unit.
In startups, data access is easier but production engineering is scarce. The founder usually plays the product owner. The second or third engineering hire should have run a production system before, even if not an AI one, because reliability habits transfer and are hard to teach under pressure.
In both, the team should be small for longer than feels comfortable. The table's illustrative sizes are deliberately modest. A team of four with a clear metric, a real evaluation set and access to data will ship sooner than a team of twelve without them.
Conclusion
Building an AI team is a sequencing problem more than a recruiting problem. The evidence from Google's engineering guidance and from the Sculley paper is that the model is the smaller part of the system, and the shift to foundation models makes that more true, not less. The role-sequencing table puts the hires in an order that matches the work: a product owner and data audit first, AI engineers to prototype, data and backend engineers for the pilot, ML, platform and governance roles for scale, and scientists only when differentiation demands them. Skipping the premature hires, a chief AI officer without a product, researchers without data, a platform for a single model, saves money and, more importantly, keeps the team focused on shipping something measurable.
Methodology and sources
This article draws on engineering guidance and published research and adds an original role- sequencing table; stage boundaries and team sizes in that table are illustrative assumptions, not observed benchmarks. The technical-debt quotations are from Sculley et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS 2015 (proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf). Martin Zinkevich's rules are quoted from Google's Rules of Machine Learning (developers.google.com/machine-learning/guides/rules-of-ml). MLOps maturity levels and role descriptions are from Google Cloud's architecture guide on MLOps (docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine- learning). Chip Huyen's definition of AI engineering is from the companion repository for AI Engineering, O'Reilly, 2025 (github.com/chiphuyen/aie-book). The reskilling finding is from McKinsey's blog of 20 January 2023 on its State of AI 2022 survey (mckinsey.com/about-us/new-at- mckinsey-blog/ai-reinvents-tech-talent-opportunities), and the high-performer finding from McKinsey's State of AI 2025, which is on the editor-verified list. AI engineering posting growth is from IANS, 24 April 2026 (ianslive.in/ai-engineering-hiring-in-india-jumps-595-pc-as-demand- spreads-beyond-metros--20260424121646). PanScience's shared functions are company-reported, from panscience.xyz.