Skip to content

Staffing the Delivery Team

Once your program prioritizes a use case, decide who will own the result before you decide who will build it. Delivery involves two handoffs: from the backlog to the team that builds, and from that team to the people who run the result. Treat them as one design problem.

This page covers the first handoff, and The Handoff to the Owner covers the second. Choosing what to build comes before both. For that, see the intake backlog and the value and feasibility scoring in Running a Workflow Optimization Program.

Name the owner before you staff anyone

Start with the person who will own the result after launch. The Umbrex Chief AI Officer playbook lists a named business owner first among a project's few non-negotiables (Umbrex, 2025). Name that person before you assign anyone to build.

The owner needs the authority to act on the result. The test from When to Embed an Engineer applies: someone who can already redirect budget and overrule a queue. A "product owner" title does not pass that test on its own.

That owner is usually too senior to sit with the team every day. So they name a delegate: someone who runs the workflow today and knows what a correct result looks like. Write down which decisions the delegate can make alone and which go back to the owner.

Who is on the team

Build the team around the workflow the use case changes. Three seats matter:

  • The owner's delegate. This is the domain expert, who decides what counts as a correct output. Sam Bhagwat, whose company makes an agent framework, describes how teams build their tests. They ask this person for a comprehensive list of domain questions (Mastra, 2026).
  • One or two builders. These are engineers who can build with AI tools and connect the result to your systems and data.
  • An architect from the hub. They hold the data, security, and platform standards that Program Architecture keeps central. One architect can often cover several teams part time.

In regulated work, add the compliance or model-risk reviewer at kickoff. A reviewer who first sees the system at launch is how a finished build fails its first review.

The smallest version of this team is two people. McKinsey's Rob Levin describes "a product owner who knows the definition of what good looks like, and a full-stack engineer" (McKinsey, 2026). In the terms used here, his product owner is the delegate. The owner with budget authority still sits above the team.

Treat claims about team size with care. We found no independent study of the right size for AI-era delivery teams. Most figures we found come from firms that sell these teams, and McKinsey sells the transformation work around them.

Two architects who consult on team design say the question is still open. In their words, "we are not going to pretend the data settles it" (Hands-on Architects, 2026). Whether the domain expert is really on the team matters more than its size.

The business owner's time is a cost

The domain expert is the scarcest person on the team. In our reading, most writing on delivery pods leaves their time out of the plan. Budget their hours the way you budget an engineer's: hours per week, for how many weeks, and who covers their normal job.

Then change their objectives to include the result. Otherwise their day job wins every conflict, and the team ends up with a stand-in who can describe the process but cannot change it.

Secure this commitment in the same meeting that sets the priority. In the Umbrex model, the chief AI officer proposes priorities, and business leaders commit sponsorship and benefits ownership (Umbrex, 2025). A business leader who approves a priority but will not release a person has not really approved it.

Run as many teams as you have owners

Your limit is usually owners and domain experts rather than engineers, so six prioritized use cases do not mean six teams. You can run as many teams as you have owners who can give the time.

Where owners are scarce, run use cases one after another through the same team. Run them in parallel only where each one has its own owner and delegate.

More teams bring a coordination cost, such as duplicated integrations and conflicting data definitions. The hub's standards exist to absorb that cost. When the center itself becomes the bottleneck, Running the AI Center of Excellence covers how the model has to change.

What a vendor means by "pod"

You will hear this team called a "pod." In our reading, most published writing on AI pods comes from software firms that sell pods as an alternative to contract staff. Treat their speed figures as marketing claims rather than evidence.

The idea is older than the name. Amazon's two-pizza team is "a small team that fully supports software for a particular business capability" (Fowler, 2023). Team Topologies calls a similar unit a stream-aligned team, aligned to a flow of work from a segment of the business (Team Topologies, n.d.).

This site also uses "pod" for something else. In The Three Accountabilities, a pod is the standing Owner, Architect, and Verifier unit that runs a process once AI does the work. The delivery team builds the system, and that unit runs it. The owner you named first takes that unit's Owner seat. The delegate, whose questions the tests were built from, is the natural Verifier. That continuity is why you name them before anyone builds.

A smaller team does not make the work smaller. In the words of Hands-on Architects: "Generation gets cheap; verification, integration, and judgment get expensive" (Hands-on Architects, 2026). Plan time for review, or the team will get its speed by skipping it.

Sources

  • Umbrex — Chief AI Officer Playbook — The Chief AI Officer Mandate, 2025. Define a minimum viable lifecycle with a few non-negotiables: named business owner, baseline, approved data access, risk review, monitoring plan, and adoption approach. View source · verified 2026-09-13 · primary
  • Mastra (Sam Bhagwat, co-founder and CEO, on the InfoQ podcast) — Tiger Teams, Evals and Agents: The New AI Engineering Playbook, 2026. Typically, the way that we see teams doing it is they'll bring in a subject matter expert. And so they'll ask the subject matter expert, "Can you give us a list of questions that would be reasonably comprehensive of the domain?". View source · verified 2026-09-13 · primary
  • McKinsey (Rob Levin, senior partner, McKinsey Live webinar) — Rewired to win: Reimagining the enterprise with tech and AI (webinar transcript, edited for clarity and length), 2026. It's really collapsing this model of the “two-pizza team” of around eight people, to two people: a product owner who knows the definition of what good looks like, and a full-stack engineer who can work with code writing systems, debug it, and work it into the architecture. View source · verified 2026-09-13 · ⚠ secondary mirror
  • Hands-on Architects (Maciej Laskowski and Tomasz Michalak) — Team Topologies in the AI Era: Where Does the Cognitive Load Go?, 2026. Does the team shrink to fewer generalists - or hold its headcount and own more scope? Both forks are live, and we are not going to pretend the data settles it. View source · verified 2026-09-13 · primary
  • Umbrex — Chief AI Officer Playbook — The Chief AI Officer Mandate, 2025. The CAIO runs the agenda and proposes priorities; business leaders commit sponsorship and benefits ownership; technology leaders commit capacity and platform moves; risk leaders confirm control requirements; finance validates baselines and value logic. View source · verified 2026-09-13 · primary
  • Martin Fowler — Two Pizza Team (bliki), 2023. A two-pizza team is a small team that fully supports software for a particular business capability. View source · verified 2026-09-13 · primary
  • Team Topologies (Matthew Skelton and Manuel Pais) — Key Concepts. Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain. View source · verified 2026-09-13 · primary
  • Hands-on Architects (Maciej Laskowski and Tomasz Michalak) — Team Topologies in the AI Era: Where Does the Cognitive Load Go?, 2026. The harness does not delete cognitive load. It relocates it. Generation gets cheap; verification, integration, and judgment get expensive. View source · verified 2026-09-13 · primary