The one full-time owner rule for AI in production
A feature owned by someone at 10% of their time gets 10% of an owner's attention. AI features degrade quietly, and a part-time owner is structurally too distracted to catch it. The math is unforgiving.
The one full-time owner rule for AI in production
A director of engineering at an insurance company told me about the pattern he kept repeating until he named it. His team would ship an AI feature, and ownership would land on whoever had a little slack, as a side responsibility on top of a full job. It seemed reasonable. The feature was live and mostly working, so how much attention could it need? The answer, every time, was more than 10% of a distracted person. The feature would drift, the cost would creep, the edge cases would pile up, and the part-time owner would notice weeks late because the feature was never actually their priority on any given day.
He arrived at a rule he now defends. A production AI feature needs an owner who owns it, not an owner who owns it when nothing more urgent is on fire. Because with an AI feature, the fire is slow, and a part-time owner is exactly the person who will miss a slow fire.
Part-time ownership and slow failure are a bad match
AI features do not fail loudly on day one. They degrade. The output drifts as the world changes, the inference bill climbs with usage, and the trust erodes one bad answer at a time. Catching that requires sustained attention, someone watching the slow signals on a schedule. A part-time owner, by definition, is giving those signals partial attention while their real job pulls them elsewhere. The failure mode is arithmetic, plain and simple.
This is a big part of why so many features that reach production still deliver no measurable return. They are technically live and functionally unwatched. The org counts them as shipped and moves the owner’s attention to the next thing, and the feature quietly gets worse with no one whose job it is to notice.
Sizing the ownership honestly
- Match the owner’s time to the feature’s needs. A live AI feature that touches customers is not a 10% job. Size it honestly before you assign it.
- Make the slow signals someone’s actual priority. Drift, cost, and trust erosion need scheduled attention, not leftover attention.
- Do not let ownership be the thing that gets dropped. When the owner has a full job plus the feature, the feature loses every time there is a fire. Plan for that or prevent it.
- If you cannot fund a real owner, question the feature. A feature no one has time to own is a feature the org is not actually ready to run.
How we approach it at Density Labs
In our AI Opportunity Assessment ($2,500), we size the ownership a feature will need in production and check that the org is prepared to fund it. A feature that degrades quietly needs an owner whose attention it actually has, and we would rather flag a part-time owner before launch than watch a slow fire burn for a month unnoticed. Naming the real cost of ownership up front is part of deciding whether the feature is worth building at all.
A production AI feature is a commitment, not a deliverable. If no one has the time to own it, the feature is a slow fire you lit and walked away from.