The most common AI staffing mistake is not hiring the wrong person, it is hiring the right people in the wrong order and at the wrong scale. Companies announce an AI initiative, open five requisitions at once, a data scientist, an ML engineer, an MLOps engineer, a data engineer, a product manager, and six months later have a full team, a large payroll, and no shipped system, because the work at month one only needed two of those five. An AI team should grow the way the project grows: start narrow, ship something, and add roles when the work actually demands them.
The roles an AI project actually needs
Strip away the title inflation and most applied AI projects draw on six functions. Not six people, functions: at small scale one strong person covers several of them.
- AI/ML engineer: builds the models or LLM pipelines and the software around them, and takes them to production. On modern applied projects, especially LLM-based ones, this is the load-bearing role.
- Data engineer: makes the company's data reachable, clean and reliable, pipelines, quality checks, access. Chronically underestimated; on most projects this is where the schedule is won or lost.
- MLOps/platform engineer: deployment, monitoring, retraining, cost control, the difference between a demo that ran once and a system that runs every day.
- Product owner with AI literacy: owns the business problem, decides what "good enough" means, and protects the team from scope drift. Does not need to code; does need to understand what models can and cannot do.
- Domain expert: the person who knows the process being automated, part-time, but non-negotiable, because they define ground truth and catch nonsense outputs no metric will catch.
- Data scientist/applied researcher: needed when the problem is genuinely open, custom models, novel methods, not for wiring proven models into products, where an ML engineer covers it.
The order matters: engineer first, then data, then ops
The sequencing that works, across most applied AI projects, is a staircase rather than a big bang.
- 1Phase 1, validate (weeks 1-8): one senior AI/ML engineer plus a part-time domain expert and a product owner who already exists in your organization. The goal is a working end-to-end slice on real data, not architecture.
- 2Phase 2, harden (months 2-5): add data engineering, because by now the pilot has revealed that the data is messier than anyone admitted, and a second engineer if the surface area grows.
- 3Phase 3, productionize (months 4-8): add MLOps capability, monitoring, deployment automation, evaluation pipelines, often fractional at first, full-time only when there is enough operational load.
- 4Phase 4, scale (month 6+): only now does it make sense to talk about platform teams, dedicated researchers or multiple squads, and only if there is a portfolio of use cases to justify them.
Team shapes by project size
| Project scale | Typical team | Size | Notes |
|---|---|---|---|
| Pilot / proof of value | 1 senior AI/ML engineer, part-time domain expert, existing PO | 1-2 FTE | Goal is evidence, not architecture; resist adding specialists |
| Production feature | 2 AI/ML engineers, 1 data engineer, fractional MLOps, PO with AI literacy | 3-5 FTE | The most common healthy shape for a single shipped use case |
| AI platform / portfolio | Use-case squads (2-3 each), shared data & MLOps platform team, AI lead | 6-10+ FTE | Justified only by multiple live use cases, not by ambition |
The classic over- and under-staffing mistakes
- Hiring a data scientist to do an ML engineer's job: the project needs shipped software, and analysis skills alone leave a prototype-to-production gap nobody owns.
- Building the platform before the product: an MLOps engineer and a feature-store initiative in month one, before any use case has proven value, is the most expensive form of procrastination.
- The lonely genius: one engineer carrying modeling, data plumbing, deployment and stakeholder management alone, it works for eight weeks, then it becomes the project's single point of failure.
- Hiring for the org chart, not the phase: five simultaneous requisitions because the target picture shows five boxes, while the current phase has work for two.
- Forgetting the domain expert: teams that skip structured access to the person who knows the process end up optimizing metrics that do not matter and shipping outputs the business quietly ignores.
When fractional or embedded beats full-time, role by role
Not every function on the list deserves a permanent seat, and pretending otherwise is how AI initiatives become fixed-cost problems. A practical split: the roles that carry the system across its whole life belong in-house full-time; the roles with spiky, phase-limited or fractional load are better filled with embedded or freelance experts. Concretely: the core AI/ML engineer on a system you intend to keep should trend toward permanent. MLOps is usually fractional until operational load justifies a full seat. Senior data architecture is often a set-up problem, intense for a quarter, then advisory. And an embedded senior engineer at the start of a project, working alongside the people who will own the system later, buys speed now and leaves knowledge behind, which is a very different transaction from renting output.
