Who Should Your First AI Hire Be?
Most companies make the first AI hire the same way. They decide AI matters, they look at what an AI person does, and they hire the profile that most looks like it does AI: someone who builds and evaluates models. It is a reasonable instinct and it is usually the wrong first move.
The argument here is narrow and disagreeable on purpose. Hiring a data scientist before you have anyone who can deploy is the most common way an AI budget produces nothing. Not the only way, and not a certainty, but the most common, and the mechanism is well understood.
The Mechanism: A Model Is Not a System
The clearest statement of why comes from a 2015 paper by a Google research team, Hidden Technical Debt in Machine Learning Systems, presented at NeurIPS. Its central observation is structural: in a real production machine learning system, the model code is a small fraction of the total. The surrounding mass is configuration, data collection, feature extraction, serving infrastructure, monitoring, and process management. The modelling is the visible part of something much larger.
That paper is a decade old and describes classical ML rather than the current generation of hosted models. Its structural point has aged well, and if anything it applies more strongly now. When a team builds on a hosted model API, the modelling work shrinks further while everything around it stays: you still need evaluation, integration, cost control, latency management, failure handling, and a way to tell when output quality degrades.
So the shape of the work is that most of it is not modelling. A first hire chosen entirely for modelling ability is being selected on the smallest component of the job.
What the Deployment Research Actually Found
The complementary evidence is a survey of published case studies, Challenges in Deploying Machine Learning, which reviews real deployment accounts across the machine learning lifecycle and catalogues where projects encounter difficulty.
The value of that survey for a hiring decision is where the problems cluster. They are distributed across data management, model deployment, and post-deployment monitoring and maintenance, rather than concentrated in the model-building stage. The recurring difficulties are practical ones: getting to the data, integrating with existing systems, keeping a deployed model working as conditions change, and maintaining it once it is live.
None of those are solved by a better model. They are solved by someone who has done them before. That is the entire argument of this article, and it is why the first hire's profile should be selected against that list rather than against modelling depth.
The DORA research program, which has studied software delivery performance for over a decade, points at the same underlying capability from a different direction: the organisational ability to get changes into production reliably and repeatedly is the thing that separates teams that ship from teams that do not. AI work does not exempt a team from that, and a first hire who has never operated a production system brings none of it.
The Standard This Article Applies to Its Own Figures
The usual way to open an argument like this is with a failure-rate statistic: some large percentage of AI pilots that never produced measurable value. This article does not use one, and the reason is a rule rather than a judgement about those particular numbers.
The standard is simple: we cite a figure only if we can trace it to a named publication we were able to reach and read. Two of the most widely circulated AI failure-rate statistics fail that test today, in two different ways, and the difference is worth naming because they are not the same problem.
Served, but not found. One figure comes from a research report whose original address no longer returns the report. The URL resolves normally and returns a page, but the page is a research group's general overview, and the figure is not on it. Nothing is blocking access; the document simply is not there any more.
Blocked. The other comes from a publisher whose site returns an access-denied response to automated requests. The document may well be intact and correct behind that barrier. We cannot read it, so we cannot confirm the number or the methodology that produced it.
Neither outcome means a figure is wrong. It means neither meets the standard, so neither appears here. Where a figure on our pages turns out to be unverifiable, it is removed as we find it.
The argument above rests instead on peer-reviewed and openly published work about where deployment fails, which is more directly relevant to a hiring decision than a headline failure rate would be, and which you can check yourself at the links given.
What "Can Deploy" Actually Means Now
The phrase is doing a lot of work, and it means something different than it did when most AI team-building advice was written. If your system calls a hosted model rather than training one, deployment capability is not mainly about infrastructure. It is about five things, and a first hire should be able to describe having done all of them.
An evaluation harness that runs without a human. Not a spreadsheet of good outputs. Something that takes a set of inputs with known-acceptable answers and reports a score you can compare across versions. Without it, nobody can tell whether a prompt change helped, and every release becomes an argument about vibes.
A cost and latency budget. Hosted model calls have a per-request price and a variable response time, both of which move when you change models or prompt length. An engineer who has run one of these in production knows roughly what the system costs per user action. One who has not will be surprised by the first invoice.
Failure handling that is not an exception trace. Models time out, refuse, return malformed output, and occasionally return confident nonsense. Each needs a defined behaviour. The question to ask a candidate is what their system does when the model returns something unparseable, and the answer should be specific.
A way to see what users actually got. Logging inputs and outputs, with whatever redaction your legal position requires, so that when someone reports a bad answer you can look at it. Teams that skip this debug by guessing.
A rollback path. Prompts and model versions are configuration, and configuration changes break things. Being able to put yesterday's version back within minutes is what makes it safe to iterate at all.
None of that is modelling work, and none of it is optional once real users are involved. It is also learnable, which is why the profile to look for is production engineering experience of any kind plus genuine interest in the AI layer, rather than an AI specialist who has never operated anything.
Sequencing the First Three Hires
The practical version of the argument is an ordering.
| Hire | Profile | What they must be able to do | Trigger for the next hire |
|---|---|---|---|
| First | AI or ML engineer with production experience | Take a model or a hosted API and put it in front of real users, with evaluation and error handling attached. | Something is live and people depend on it. |
| Second | MLOps or platform engineer | Own the running system: monitoring, retraining triggers, rollback, cost. Free the first hire to keep building. | The first hire spends more time operating than building. |
| Third | Data scientist or modelling specialist | Improve quality against a metric that is now measurable because the system is live and instrumented. | Accuracy is the observed bottleneck, not an assumed one. |
The third row carries the real point. A modelling specialist is a high-value hire once you can measure what needs improving. Before anything is running, there is no measurement, so the specialist optimises against a proxy and nobody can tell whether the work mattered.
There is a second sequencing question that runs upstream of this one, and it has a separate answer. If your data is scattered across systems that disagree with each other, the first hire may need to be a data engineer rather than either of the profiles above; our guide to hiring a machine learning engineer sets out that test in full. The two arguments stack rather than compete. Data engineering fixes what goes into the system, deployment capability fixes what comes out of it, and modelling depth is worth paying for once both ends exist.
The Objection, Which Is a Fair One
There is a reasonable counter-argument, and it is one we have made ourselves elsewhere on this site: hire an operations-focused engineer too early and they have nothing to operate. An MLOps engineer with no model to deploy is an expensive person waiting.
That objection is correct in the case it describes, and it is why the sequence above does not put a pure MLOps hire first. The first hire is someone who can both build a working thing and ship it, which is a common profile and the one to search for. The dedicated operations hire arrives second, when there is a running system to own.
Where we now think the earlier framing was wrong is in placing a data scientist in the opening pair. That produces a team that can produce a validated model and cannot ship it, which is precisely the failure mode the deployment literature describes. We have revised our remote AI team structure guide to reflect this, and the change is explained on that page rather than made silently.
The objection also has a genuine limit case. If you have already built something that works and it is stuck in a notebook, the operations hire is the right first hire, because the constraint is unambiguously deployment.
How to Screen for It
The profile is easy to describe and easy to get wrong, because most candidates can discuss deployment convincingly without having done it.
Ask what broke. Anyone who has run a system in production has a story about it failing in a way they did not anticipate. Candidates who have only built models describe the training process instead. This single question separates the two populations more reliably than any technical exercise.
Ask how they knew quality was degrading. In production, model output gets worse gradually as the world changes. The answer you want describes a mechanism, however crude, and involves someone noticing. The answer that should concern you is that quality was measured at training time.
Ask what they would remove. Experienced production engineers have opinions about scope, because they have maintained things. A candidate who wants to build everything has not yet carried the cost of doing so.
Ask who used it. The end of the story should involve people. If every project description ends at model evaluation, the candidate has not shipped, whatever the résumé says.
What This Costs to Get Wrong
The cost is not only the salary. A first AI hire who cannot ship produces a well-validated model, a favourable internal presentation, and no production system. When the budget is next reviewed, there is nothing to point at. The project is not usually killed because it failed; it is killed because it cannot demonstrate that it worked.
That is the compounding part. A shipped system, even a mediocre one, generates usage data, a measurable baseline, and an argument for the next round of investment. A model in a notebook generates a slide.
The Bottom Line
Choose your first AI hire for the ability to put something in front of users, not for modelling depth. Add the operations specialist when something is live and needs to stay live. Add the modelling specialist when you can measure what they would improve.
Before any of that, confirm the raw material exists: our data readiness check covers the five things that block a first hire regardless of how well you choose them, and what it costs to run an AI system after you build it sets out the ongoing cost that the second hire exists to manage.
F5 Hiring Solutions places AI and ML engineers from India as a managed remote workforce, starting at $600 per week, all-inclusive, with a shortlist in 7-14 business days. When we scope a first AI hire, deployment experience is what we screen hardest for, for the reasons above. To start, hire remote AI and ML engineers from India or book a 15-minute call with Joel Deutsch at https://calendly.com/joel-f5hiringsolutions/f5.