There is a hiring mistake so common in enterprise AI that it deserves a name. Call it the unicorn-first error: the organization decides to get serious about AI, so it opens a requisition for a senior machine learning engineer, waits out the average 89 days it now takes to fill an AI/ML role, pays the premium, and then watches its expensive new hire spend six months asking for data access, use case clarity, and someone, anyone, to define what success looks like.
The engineer was never the missing piece. The team was. AI value is produced by a small ensemble of complementary roles, and the order in which you assemble that ensemble matters as much as the talent inside it. This article is about the roles, the sequence, and the team shapes that actually ship.
The core ensemble
Strip any successful AI delivery team to its load-bearing roles and you find five.
The AI product manager. Owns the “should we” questions: which problem, for which users, with what success metric, at what risk tier. In AI work the product role carries extra weight because the technology is probabilistic; deciding what accuracy is good enough, and what failure costs, is a product judgment, not an engineering one. If you make only one hire from this list, make it this one.
The AI engineer. The builder of the system around the model: retrieval pipelines, agent scaffolds, integrations, and the unglamorous glue that turns a demo into software. Note the title shift: in 2026 most enterprise AI engineering is systems work on top of foundation models, not model training. Hire for production engineering instincts first, ML theory second.
The data engineer. The role every AI plan underestimates. Models are only as useful as the data they can reach, and the pipelines, quality checks, and access controls are a full-time discipline. The Data & AI Strategy track made the case that data readiness separates the 12x performers from the rest; this is the person who builds that readiness.
The evaluation and quality lead. New to most org charts and rapidly becoming non-negotiable. Someone must own the test sets, the accuracy benchmarks, the regression suites, and the honest answer to “is this system actually good?” In small teams this is a hat worn by the engineer; in scaled programs it is a career.
The domain expert. Not a hire, usually, but a secondment: the underwriter, the claims lead, the contract lawyer who knows what correct looks like. Teams without embedded domain expertise build technically impressive systems that answer the wrong question. Treat this seat as mandatory, and staff it with someone the business will miss, because if the business does not miss them, they were not the expert you needed.
Around this core orbit the specialists you add as stakes rise: a responsible AI advisor for high-tier use cases, a security engineer when agents start touching production systems, a UX designer when humans must trust and supervise the output, and an agent operations engineer once autonomous systems run in production.
Figure 1 maps the full role landscape, core ensemble at the center, specialists in the orbit, with the platform team and CoE from earlier articles shown as the shared foundation every delivery team draws on.
The hiring sequence
Sequence is strategy. The same ten hires in a different order produce a different year. Here is the sequence that works, stage by stage.
Stage one: prove value. First the AI product manager, then one strong AI engineer, then the embedded domain expert. This trio, standing on a platform (yours or a vendor’s), can take one well-chosen use case to production. Resist the urge to hire researchers at this stage; you are not doing research, you are doing delivery.
Stage two: make it repeatable. Add the data engineer, because use case two and three will die on data access without one. Add evaluation capability, because the second use case is where “it seems fine” stops being an acceptable quality bar. This is also when the platform team from the previous article starts earning its existence.
Stage three: scale it. Now, and only now, the specialists: responsible AI, security, agent operations, enablement. And crucially, this is when hiring shifts from the central team to the spokes, seeding AI engineers and product managers directly into business units on the hub-and-spoke trajectory we mapped earlier.
The stage-three shift is where career architecture starts to matter. Your best people need a path that does not require leaving, and in AI that means dual tracks: a technical ladder that reaches genuine seniority without people management, and mobility between hub and spokes so that a platform engineer can become a domain team lead and return. The market context makes this urgent: AI skills command a large wage premium, recruiters circle constantly, and replacing a departed senior AI engineer costs you the 89-day search plus the institutional knowledge that walked out the door. Retention is cheaper than recruitment at almost any salary.
Team shapes that work
Roles are atoms; teams are molecules. Three shapes cover most enterprise situations.
The pod. Five to eight people, all five core roles represented, owning a use case end to end from discovery through production operation. Pods are the default delivery shape, and their defining property is completeness: a pod that must borrow a data engineer from another team is not a pod, it is a dependency graph.
The platform team. Covered in the last article; it exists so pods can stay small. Every role a pod does not need to staff, because the platform provides it, is compounding leverage.
The enabling squad. Two or three senior people from the CoE who embed with a business team for a quarter, build the first use case with them, and leave behind skills rather than dependency. This is how the spokes get seeded without cloning the central team.
The anti-shape to avoid: the horizontal layer cake, where data engineers sit in one department, ML engineers in another, and product in a third, and every use case requires a treaty among three managers. AI delivery is iterative and fast-twitch; organizational distance between the roles turns two-day feedback loops into two-week ones.
Figure 2 shows the sequence and the shapes together: the stage-one trio growing into pods, the platform team forming underneath, and enabling squads seeding capability outward into the business units.
Hiring in a brutal market
Every role above is scarce. Demand for AI talent exceeds supply roughly three to one globally, and 2026 surveys put AI capabilities at the top of employers’ shortage lists. Three practical adjustments follow.
Hire for adjacency, not pedigree. Strong backend engineers become strong AI engineers in months; the reverse conversion is slower. Demonstrated learning velocity beats a keyword-matched CV, and degree requirements are quietly falling across AI-exposed roles for exactly this reason.
Grow your own. Organizations are now several times more likely to upskill existing staff than to hire externally for strategic technology skills, and for good reason: your people already know your systems, your data, and your politics. The next article is devoted entirely to this build-buy-borrow calculus.
Sell the platform, not the ping-pong table. Senior AI talent chooses employers by the quality of the problems and the absence of friction. A real platform, real data access, and a real mandate are worth more in a recruiting conversation than any perk, and as Figure 1 hints, candidates can read an org design as fluently as any consultant: they know a layer cake when they see one.
The judgment call
One closing principle ties this together. The teams that perform are not the ones with the most impressive individual resumes; they are the ones where the five core roles trust each other enough to move fast, embedded close enough to the business to know what correct looks like, and standing on enough shared platform that their energy goes into the problem rather than the plumbing. Figure 2’s growth path is really a trust-building path: trio, pod, network.
Build the ensemble, sequence it deliberately, and protect it from the org chart. Then face the question the market forces on everyone: when you cannot hire the talent you need, do you build it, buy it, or borrow it? That is next.