The team you actually need to build AI (it's not who you think)
Bottom line: Teams staff AI projects as if the scarce ingredient is machine-learning talent — and then watch the project fail for reasons that have nothing to do with the model. AI delivery needs three capabilities held in tension: product judgment, engineering, and domain expertise. The model work lives inside engineering and is rarely the bottleneck. The failure mode is a team with a weak or missing vertex, and the missing one is almost always domain — the capability teams forget to staff because its absence is the hardest to see.
You're hiring for the wrong scarcity
When an organization decides to build something with AI, the first instinct is almost always to hire machine-learning talent. The reasoning feels obvious: this is an AI project, AI means models, models mean ML engineers, so the constraint must be ML talent. Budgets get written, recruiters get briefed, and the scarce, expensive search for model expertise begins. Then the project ships late, or ships wrong, or doesn't ship — and a postmortem reveals that the model was never the problem. The system did the wrong thing, or solved a problem nobody had, or produced output that looked right to everyone except the people who actually knew the domain.
This is the central misdiagnosis of AI staffing. The model is the most visible ingredient, so it is assumed to be the scarce one, but visibility and scarcity are different things. In most enterprise AI work, capable models are increasingly available off the shelf, and the model layer is rarely where projects fail. They fail in the gap between a model that can produce an answer and a system that produces the right answer, integrated into real work, solving a problem worth solving. That gap is not closed by more ML talent. It is closed by capabilities most teams forget to staff because they were busy hiring for the wrong scarcity.
The model is the most visible part of an AI project, so it gets mistaken for the scarce part. It is usually neither the scarcity nor the bottleneck.
Three capabilities, held in tension
What AI delivery actually requires is three distinct capabilities, none of which is sufficient alone and all of which must be present and in genuine tension with each other.
The first is product judgment: the ability to decide what is worth building, for whom, and what "good enough" means — the judgment that points the effort at a real problem rather than an interesting one. The second is engineering: the ability to make the thing real, reliable, and integrated — and this is where the model work lives, as one component among many, alongside retrieval, evaluation, integration, and the data loop. The third is domain expertise: deep knowledge of the actual field the system operates in — what correct looks like, which errors are catastrophic, what context the data doesn't capture. Each of these is a different kind of knowing, and each acts as a check on the others. Product without engineering is a wish; engineering without domain is a confident machine producing subtly wrong answers; domain without product builds something correct that nobody needed. The capabilities have to argue with each other, which means they have to be present at once.
The Capability Triangle
Picture the three capabilities as the vertices of a triangle, with the real work happening in the overlaps between them.
Exhibit 1. AI delivery needs three capabilities in tension. The model work lives inside one of them — and is rarely the bottleneck.
Product sits at one vertex, engineering at another, domain at the third. The edges between them are where value is actually created: product and engineering together make something feasible and worth building; product and domain together make it valuable in the real world; engineering and domain together make it usable and correct in context. And the center, where all three overlap, is the team — not three specialists in separate rooms passing artifacts back and forth, but a genuine overlap where each person understands enough of the other two disciplines to argue well. The strength of an AI team is the size of that central overlap. A team where the three vertices barely touch is three silos with a shared Slack channel; a team where they substantially overlap can move fast and make good decisions because the arguments happen inside the room rather than across organizational boundaries.
This is why the model is rarely the bottleneck. The model is one element inside the engineering vertex, and a triangle can have a perfectly strong engineering vertex — excellent ML talent included — and still fail, because the failure is in a different vertex or in the thinness of the overlaps. Staffing only the engineering vertex, however brilliantly, does not make the triangle strong.
A strong AI team is not three experts in separate rooms. It is the overlap between them — and the overlap is where every good decision gets made.
The missing vertex (it's usually domain)
When an AI team is weak, it is usually because one vertex is missing or thin — and the vertex that goes missing most often is domain.
Exhibit 2. The weak vertex is usually domain — the one teams forget to staff, whose absence is hardest to see.
Product owns choosing the right problem and setting the bar for good enough; without it, you get a technically impressive system nobody needed. Engineering owns reliability, integration, evaluation, and the data loop; without it, you get a clever demo that never survives production. Domain owns what correct looks like and which errors are unacceptable; without it, you get confident output that is subtly, dangerously wrong. The reason domain is the vertex most often left out is precisely the reason its absence is most dangerous: a missing domain vertex is invisible until production, because the system looks right to everyone on the team who cannot tell that it is wrong. A product manager and an ML engineer can both look at a plausible-sounding output and see success; only the domain expert can see that it is confidently incorrect in a way that will matter. Staff the team without that expert and you remove the one person who could have caught the failure before a customer did.
This is the quiet killer of AI projects. It is not the model failing visibly; it is the model succeeding plausibly while being wrong in ways the team is not equipped to notice. The domain vertex is the team's ability to notice, and leaving it out does not make the system more correct — it just makes the team blind to its incorrectness.
What this looks like on Monday
Set two teams side by side, with the same headcount and budget. (This is an illustration, not an account of any specific engagement.)
Exhibit 3. One stacks a single vertex; one balances all three. Illustrative, not a client account.
The first team staffs for the model. Its hire list is three more ML engineers, because the model is assumed to be the point. Missing from the room is anyone who deeply knows what "right" means in the field the system serves. Time goes into tuning a model that was never the bottleneck. The result is a sophisticated system solving the wrong problem — or solving the right one in a way the domain would recognize as subtly broken.
The second team staffs the triangle. Its hires are a product lead, an engineer, and a domain expert, so all three vertices are present and the domain voice is in the room. Time goes into framing the problem correctly and integrating the answer into real work, rather than into model-tuning that the off-the-shelf model made unnecessary. The result is a modest system solving the right problem, in production, because the team had every capability it needed to get there — including the one that could tell right from plausible.
Same headcount. One team stacked a single vertex; the other balanced all three — and only one shipped something that mattered.
Where this argument fails, and what it costs
The triangle has edges worth naming, and one important exception.
Some problems genuinely are model-bound, and the triangle should not be read as "the model never matters." At the frontier — novel architectures, research-grade problems, domains where no adequate model exists — deep ML talent is the binding constraint, and there the engineering vertex must be unusually strong. The claim is about the typical enterprise project, where a capable model is available and the failure is elsewhere, not about every project everywhere. There is also a practical complication on small teams: the three capabilities are roles, not necessarily three separate people, and on a small team one person may legitimately hold two vertices — an engineer with deep domain knowledge, a product lead who can also do the domain reasoning. The triangle is about the capabilities being present, not about a minimum headcount, and a small team that covers all three in fewer people is stronger than a large one that stacks a single vertex. Finally, overlap can be taken too far: you do want genuine depth at each vertex, not three generalists who each know a little of everything and nothing deeply. The discipline is depth at the vertices and enough overlap to argue well, not one at the expense of the other.
That bounds the claim. Weight the engineering vertex heavily for genuinely model-bound problems, treat the vertices as capabilities rather than mandatory separate hires, and keep real depth at each. The point is not to hire fewer ML engineers; it is to stop assuming they are the whole team.
The decision
Here is the move this points to before you staff your next AI initiative, and it is concrete.
Before you write the hire list, map the three vertices and ask honestly which is weakest on the team you have — and be especially suspicious if the answer is domain, because that is the vertex whose absence you are least able to see. Resist the reflex to solve every AI staffing question by adding ML talent; ask instead which capability the project is actually short on, and staff that. Put the domain voice in the room from the start rather than consulting it late, and build for overlap — people who understand enough of the adjacent disciplines to argue well — rather than for three silos that hand work across boundaries.
The scarce ingredient in your AI project is rarely the model, and hiring as if it were leaves you with a strong engineering vertex attached to a weak or missing one. Staff all three capabilities, get the domain expert in the room, and invest in the overlap where the real decisions happen. The best AI teams are not the ones with the most ML PhDs — they are the ones whose three vertices genuinely overlap. Which vertices you build versus buy is the architecture question taken up in the companion piece on the advantage map; which problem the team should point itself at in the first place is the judgment question underneath all of it.
Sources
- McKinsey — The State of AI (annual survey). Talent gaps and the observation that capturing value depends on more than technical AI skill alone. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Deloitte — State of Generative AI in the Enterprise (2024–2025). Talent, domain integration, and cross-functional capability among the determinants of whether AI scales. https://www2.deloitte.com/
Bottom-line summary (one line)
AI delivery needs three capabilities in tension — product, engineering, and domain — not just ML talent; the model lives inside engineering and is rarely the bottleneck, and the vertex teams forget to staff is domain, whose absence is invisible until production.
Suggested LinkedIn hooks (link back to the blog)
- The first instinct when starting an AI project is to hire ML engineers. Then it fails for reasons that have nothing to do with the model. You're hiring for the wrong scarcity. [link]
- A strong AI team isn't three experts in separate rooms. It's the overlap between product, engineering, and domain — and the overlap is where every good decision gets made. [link]
- The vertex teams forget to staff is domain — and its absence is invisible until production, because the system looks right to everyone who can't tell that it's wrong. [link]