The AI Team You Actually Need Is Smaller Than You Think

The AI team every company thinks it needs is ten people. The AI team that actually works is often three.

The hiring panic is real. Every org chart I see has the AI team growing in the same shape — a head of AI, a platform team, an ML engineer for every business unit, a data science squad, a prompt engineer (a role that didn't exist two years ago and already means three different jobs), and a governance person to watch all of them. The budget is enormous and the output is often a lot of infrastructure that nobody in the business can use.

Here's the uncomfortable pattern from the organizations actually shipping: the AI team is small, the roles are specific, and the size is a feature, not a limitation.

The five roles that matter

The work of AI in an organization breaks into five roles. Notice the roles, not the titles — one person can hold more than one, and most good small teams do.

The builder. The person who can ship — integrate the model, build the pipeline, wire the tool into the actual workflow. This is the engineering role, and it's the one everyone hires first. It's also the easiest role to find, because it's the one that looks like a normal software job.

The evaluator. The person who owns the question “is this good enough?” This is the role that's almost never hired and almost always needed. The evaluator builds the test sets, runs the regressions, tracks the quality bar as models change. It's a strange hybrid — part QA, part data scientist, part domain expert. It's the role that separates teams that trust their AI from teams that gamble on it.

The operator. The person who runs it in production — watches the dashboards, handles the incidents, manages the review queue, knows what normal looks like. The operator is the one who notices on Tuesday that the model started behaving differently, before it becomes a customer problem on Friday.

The domain owner. The person from the business who knows the actual work the AI is doing — the process, the edge cases, the judgment the AI is trying to replicate. This person is not in the tech org at all, and that's the point. They're the source of the quality bar and the voice that says “that output is wrong in a way the metrics can't see.”

The reviewer. The person who signs off on the outputs that matter — the human check on high-stakes results. This role is often the domain owner wearing a second hat, or a rotating set of business people. Either way, it has to exist and it has to be real, not a rubber stamp.

The AI team is five roles. It is not five departments. It's five seats, and the seats that get skipped are the ones that make the difference.

The org pattern that makes three people enough

The pattern that works is a center with spokes. A small core team — builder, evaluator, operator — that owns the platform and the practice. And a set of domain owners and reviewers distributed through the business, attached to the core when their workflow is being automated.

The core team is three people because the platform is the same shape for every use case. The eval harness, the routing, the observability, the escalation path — these are built once and reused. A third business unit adopting AI doesn't need a new builder. It needs a new domain owner, and the domain owner is already in the business unit, already knows the work, and just needs the core team to make the tooling usable.

This is the pattern the big teams miss. They hire ten people in the center and none in the business, then wonder why adoption is slow. The adoption lives in the spokes, not the center. The domain owner who's part of the business team is the one who makes the AI actually fit the work.

Why big teams fail

Big AI teams fail for a structural reason: they replace judgment with process. When you have ten people, you need coordination, so you build ceremonies — intake forms, review boards, prioritization frameworks, roadmaps that need approval from three layers. The ceremonies consume the team, and the distance between the AI team and the business grows until the AI team is building what it imagines the business needs.

The three-person team can't afford the ceremonies. The builder talks to the domain owner directly. The evaluator's test set is defined by the reviewer's judgment. The loop is short enough that feedback travels in days instead of quarters. Small isn't a limitation. It's the structure that keeps the team honest.

The hiring question that matters

When you're tempted to grow the AI team, ask one question: which of the five roles is missing, and can the business fill it without a new hire?

If the answer is builder, you're probably justified — that's the real constraint. If the answer is evaluator, operator, or reviewer, you don't need a hire. You need to assign the role, and the assignment is usually the thing that was never made. The role was there all along, unclaimed.

The five roles, the three-person core, the spokes in the business. That's the shape that ships. The ten-person org chart is the shape that has meetings about shipping. Hire the builder, assign the evaluator, trust the operator, and put the domain owner where they already are. The team that works is the team that's small enough to talk to each other.

Think this argument fits your event? Tell me about the room — the calendar is selective.