Staffing an AI feature: the roles teams forget to fill

An engineering manager at a B2B software company told me how he staffs AI work now, which is very differently from how he staffed his first one. That first project had a data scientist and two engineers, and on paper that looked complete. It was not. Nobody owned the evaluation, so quality was whatever the last person checked. Nobody owned the workflow the feature lived inside, so it worked in isolation and broke the moment it touched a real process. Nobody owned the customer-facing failure, so when the output was wrong, support improvised. The model was the easy part. The roles around it were the part he had not known to fill.

He put it in one line. He used to staff the thing that builds the model and assume the rest was overhead. Now he staffs the thing that keeps the feature honest in production, because that is where the work actually is.

The org chart the demo hides

A working demo needs only the people who build the model. A production feature needs several roles a demo never reveals, which is a large part of why roughly 88% of proof-of-concept projects never cross into production. The staffing that got you the demo is structurally incomplete for what comes next, and teams discover the missing seats one incident at a time.

Someone has to own evaluation, the ongoing job of deciding whether the output is good enough and proving it. Someone has to own the workflow, the integration into how people actually work, because a feature that ignores the workflow gets ignored back. Someone has to own the operational failure, the escalation and the customer answer when the model misses. And someone has to own adoption, because a feature no one uses is a staffing failure dressed as a product one. None of these are the data scientist’s job, and all of them are load-bearing.

The seats to fill before you build

An evaluation owner. Accountable for the good-enough standard and for re-checking it as the feature and the data drift. Quality with no owner decays.
A workflow owner. Someone who understands the real process the feature enters and owns making it fit, not just making it run.
An operations owner. The person who owns monitoring, escalation, and the answer to the customer when the output is wrong.
An adoption owner. Someone accountable for whether the feature is actually used, not just shipped. Usage is a role, not a hope.

How we approach it at Density Labs

In our AI Opportunity Assessment ($2,500), we map the full staffing a feature needs to survive production, not just to demo. We name the evaluation owner, the workflow owner, the operations owner, and the adoption owner, and we flag every seat that is empty. Finding those gaps on paper costs a conversation. Finding them one production incident at a time costs the project.

The model is the seat everyone remembers to fill. The reason your feature stalls is the four seats next to it that no one thought to staff. Fill them before you build, not after it breaks.