Getting people to try AI is one kind of work. Managing what happens once they start building is another. My experience spans both: teaching people to build, building agents myself, and helping put an operating model around the work that follows.
Start with the work people already do
I’ve led process-mapping work with the people doing the job: the handoffs, the systems, the time spent, and the places where work gets stuck. That gives a team something much more useful to build against than a list of AI ideas.
Sometimes the best result is removing a step. If a team can stop producing a report nobody uses, it doesn’t need an agent to produce that report faster. I want that option on the table before anyone starts building.
Participation creates a different problem
Hands-on build sessions, training, and recurring time to share work helped turn interest into practice. I’ve taught the tools while building with them myself. That matters when someone needs help getting through a specific problem.
As more people build, the questions change. Are two teams solving the same problem? Who supports a useful tool when its creator moves on? Which ideas deserve engineering time? Enthusiasm creates a pipeline of possibilities. It doesn’t decide where the investment should go.
A decision I had to make
After recurring build sessions got teams working in parallel, participation was no longer the main problem. Teams were duplicating effort, and useful ideas were competing for support. Running more build sessions would not resolve who should own the work or which problems deserved investment.
I helped put an intake and ownership model around that activity: personal tools could stay with their makers, team solutions needed a team owner, and broader initiatives needed a path to an execution team. The decision was to keep room for experimentation while giving shared dependencies a different level of support.
That changed the question from ‘who has an AI idea?’ to ‘what kind of responsibility are we taking on if other people start depending on this?’ It is one of the operating decisions behind scaling AI that rarely appears in a demo.
Give different kinds of work different support
The transition matters. Before a team tool becomes a shared service, someone needs to own its data connections, access, evaluation, maintenance, and response when it fails. A successful demo is a reason to investigate those responsibilities.
Make the return a testable question
I look at the work the business gets back: time, capacity, cost, and speed of decisions. Then I look at the work we’ve added: integration, checking outputs, handling exceptions, and keeping the system running.
An estimate helps decide what to test. It isn’t a measured result. I want a baseline, a bounded workflow, and a way to compare the result after people actually use it. If human review eats the time saved, that changes the business case. If the bottleneck simply moves to another team, we need to see that too.
A worked example: when I would hold off
The following numbers are hypothetical. They illustrate how I would test a business case; they are not results from Rivian or any client.
Suppose a team handles 100 tasks a month at 20 minutes of human effort per task. A pilot brings the average down to 8 minutes, including review, corrections, and failed tasks that fall back to a person. That releases 20 hours a month. Six hours of recurring support leaves 14 hours of net capacity.
At an illustrative labor value of $50 an hour, that capacity is worth $700. Subtract $300 of incremental monthly software and model costs and the estimated monthly net value is $400. With $2,400 in one-time implementation costs, simple payback would be six months, if those assumptions hold. This is a capacity-value estimate, not cash saved.
Now suppose real use needs 14 minutes of human effort per task instead of 8. The same calculation leaves four hours of capacity after support, worth $200 against $300 in recurring costs. The labor-based case is now negative before recovering the implementation cost.
I would hold off on expanding it on that basis. First I’d investigate the review burden and test whether a narrower task helps. Better quality or faster decisions might justify the cost, but those benefits need their own evidence. We shouldn’t keep claiming a time-saving business case after the test stops supporting it.
Keep learning after the first rollout
My operating principle is to expand responsibility as the evidence improves. Decide what a good result looks like, make failures visible, and keep a person accountable for the decisions that matter. The agent finishing its task is only one signal.
The work I find most interesting is connecting all of this: what to build, how to test it, who owns it, and whether it makes the organization work better. That is what managing an organization with agents starts to involve.