Five roles on a slide don't tell you what happens when two of them disagree. Here's what that can look like when something comes up that wasn't part of the plan.

Who does what, and what happens when two of them disagree?

That's the real question, and no slide answers it. What you're actually trying to work out is how a decision gets made when something comes up mid-project. Maybe a new feature turns out to be needed that nobody planned for. Maybe the team is halfway through building something and realizes it's going to take a lot longer than expected. That's the moment you find out whether the delivery structure actually works, or whether the problem just lands back on your desk.

So instead of walking you through the roles, here's an example of how it actually works.

Say a company updates its return policy in March. Its AI assistant doesn't know that. It's still telling customers the old policy, because the documents it pulls answers from were never updated. The answer sounds confident. It's just wrong, and it's the kind of wrong that's easy to miss, because nothing about it looks broken to someone scanning it quickly. A lot of companies let something like this sit in the backlog for six weeks: too small to prioritize, and not clearly anyone's job to fix.

On our teams, that same problem doesn't sit for six weeks. It lands on someone's desk by Monday morning.

Somebody has to decide it matters

That person is the Outcome Owner, and their first move is weighing it against everything else in the backlog. Does it touch the deliverable the team is accountable for this quarter? Can it be scoped tight enough to be worth the interruption? If it goes in, the Outcome Owner defines exactly what the fix covers before work starts: which document set, what counts as fixed, and what gets checked before anyone calls it done.

You don't sit in that meeting. That's the whole point of having one Outcome Owner: someone accountable for what ships, which includes deciding what doesn't. The decision reaches you as a short update, not as a question you have to answer yourself.

The design call gets made the same week

Retrieval problems are rarely one problem. Stale answers on a single document set could come from a chunking strategy that split the policy tables badly. Or embeddings generated before a schema change. Or a reranker weighting recency in a way that made sense for news content and makes no sense for policy. Each of those has a different fix, a different cost, and a different chance of moving answers that already work fine.

The AI Delivery Architect makes that call. One senior person owns retrieval, model integration, and eval design together, because those three decisions constrain each other. A chunking change that improves this answer can affect many others, and somebody has to know which ones and whether the trade is worth it. The value shows up on the calendar: the call gets made by Tuesday, because making it is that person's actual job, not something they fit around everything else.

The handoffs are where a team earns its keep

By the time the engineers pick this up, the questions that usually stall a ticket already have answers. They know which document set, which fix, what the eval has to show, what "done" means. Whatever coding tool is in front of them, Claude Code, Cursor, Copilot, speeds up how fast the code gets written. The decisions it gets written against were already settled upstream.

The QA automation engineer isn't waiting on a finished branch. Coverage for the new behavior gets written while the change is being built, so when the retrieval logic moves, there's already a test that says whether those other answers moved with it.

Testing that starts after the build is a schedule risk wearing a quality label.

Then the work goes through review, where QA and the architect look at it together before it reaches your repository. It ships into your codebase, on your standards, and the check happens before it lands instead of after. DevOps and design come in only when the work calls for them. On a retrieval fix that might mean an hour of pipeline work and no design at all. You're never paying for a designer to sit through a sprint that has no design in it.

Why a small group can hold all of this

There's a reason our delivery teams stay small instead of growing into a department, and it has less to do with cost than with how much a group can hold in its head at once. Matthew Skelton and Manuel Pais built an argument in Team Topologies that's held up well: a delivery team does its best work when what it has to track stays inside what a small group can actually manage. Push past that line and the team spends its week rebuilding context instead of using it.

A team that's run the same loop across many backlogs already knows what the others need to move. The architect knows what QA will ask for. The Outcome Owner knows what the architect needs before a call can be made. Nobody writes a handoff document explaining a decision four people were already in the room for on Tuesday.

That familiarity is the actual product, and it's why a backlog starts moving within weeks once the team is running.

The part that stays with you

A delivery team doesn't remove you from the work. Anyone promising that is selling a story that comes apart by week three. Three things stay on your side: deciding what gets built and in what order, giving the team real access to your users, your systems, and your data, and having someone who can settle a product question inside of a day.

That last one does more for a ship date than people expect. The team can make most day-to-day technical decisions on its own, escalating decisions that require broader architectural, security, or business context. It can't decide whether an answer that's slightly less precise, but arrives in half the time, is a good trade for your users. That's a business call, and it belongs with you.

Three questions worth asking anyone you're considering

If you're comparing structures right now and the roles all sound roughly the same on paper, these tend to separate them fast.

Who decides mid-sprint, and how long does it take? You're listening for one name and a day, not a meeting.

Who writes the tests, and when? If testing starts only after the code is written, expect the schedule to absorb the surprises.

What happens in the first two weeks? A team that's worked together before spends that time on your product. A team assembled for your project spends it on itself.

It's the same thing you'd ask about any group taking on work you're accountable for.

A list of five titles never told you who decides. Now you know what to ask instead.