Let Them Help Cook

Humanizing AI implementation

My kids are more willing to try dinner when they helped make it. They washed something, stirred something, or decided it needed more cheese. It’s partly theirs now.

This works on me, too. I’ve yet to meet a team leader it doesn’t work on.

Now picture an AI rollout. An organization buys the licenses. A vendor gives a polished demo. IT sends the login instructions. When usage drops, leadership wonders why people are resisting change.

Nobody was invited into the kitchen.

David Hume wrote that “Reason is, and ought only to be the slave of the passions.” A business case can explain why the organization should invest. The people using the system need a reason to care, too. Helping them shape something that makes their work easier is a good place to start.

Here’s how I approach that work, from preparing the ingredients to serving the table.

1. Prep the kitchen

Before planning dinner, we check the fridge. What’s fresh? What’s missing? What should’ve been thrown out last month?

I start with a forensic review of the information the AI will depend on: databases, file systems, document management, and access permissions. We look for duplicate records, stale information, misfiled documents, and gaps between systems. Then we address the problems that would undermine the work.

We check what the AI can actually access, not just what the organization’s policies say it should. That means configuring and testing who can use which information, what the AI can retrieve on their behalf, and where access must stop.

Connect AI to bad data and you get the same mistakes faster, in better prose.

2. Ask what everyone is hungry for

Next, I sit down individually with people across the departments involved. I ask about their day. What takes too long? What gets entered twice? What do they enjoy? What makes them want to leave early?

People describe the organization they think they have. The data shows the organization they actually have. The gaps between the two are where I start asking better questions. Some reveal a broken process; others reveal work the systems never captured.

Together, we decide what kind of help each task needs:

• Templatize the behavior. We define how the AI should approach recurring work: what to look for, which steps to follow, how to check the result, and when to ask for human judgment. We build that method into a reusable skill or set of instructions, then test it.

• Build the solution. We connect those behaviors to the systems and workflows they need to do useful work.

• Keep the human responsibility. We agree which judgments, relationships, and approvals stay with a person, including where AI can help prepare the information.

One workflow may need all three. The people doing it help us decide. They’re choosing what belongs on the menu and what they want help preparing.

3. Cook in saucepans

Each dish needs its own pan and attention. I build the AI support in manageable pieces, each with a defined job and a result we can inspect. An intake skill can be developed and tested without rebuilding the entire organization.

We move between the pans as the meal develops. Intake information might feed an onboarding workflow. Billing might draw on information maintained by the records team. When pieces belong together, we connect them.

We test those connections as well as the individual pieces, including missing information, awkward exceptions, and restricted access. A working part does not prove a working system.

With smaller organizations, we can start with one useful piece and expand as the results justify it. We plan for the connections and upkeep, so the first pan leaves room for the rest of dinner.

4. Taste as you go

I bring the people who described the work back to taste it. We test representative cases and the awkward ones. Does the AI find the right information? Can they check its sources? Does it follow the intended steps and ask for help when needed? Does the result fit the next stage of the job?

Then we count the effort honestly. A tool that saves ten minutes of typing and adds twenty minutes of repair needs another turn at the stove.

We use their feedback to change the behavior, improve the information, or redesign the connection. The team needs time to test and enough influence to change the recipe. A feature that keeps creating more work than it saves hasn’t earned its place.

As they refine it, they learn what the AI does well and where it needs supervision. Their experience is becoming part of how it works.

5. Serve the table

Once the pieces work together and the pilot team can use them reliably, we introduce the system to the wider group. The people who helped build it can explain the task it solves, demonstrate how it helps, and show what still needs checking.

We back that up with training, time to practice, and a clear place to get help. Pilot participants shouldn’t inherit an unofficial second job as the entire support department.

We keep tasting after the meal reaches the table. We watch whether people use the system, where they return to manual work, and whether review time or errors are eating the benefit. Then we ask why and adjust.

Why this pays off

Buy, deploy, train, hope. It looks quick on a project schedule. The work that gets skipped comes back as corrections, abandoned tools, and another implementation.

We measure the payoff in the work: time saved after review, fewer corrections, smoother handoffs, and continued use. The people who helped shape the system can also tell us when it stops helping. We keep listening to them.

That’s how I want AI to enter an organization: as a useful helper shaped around the work, with people who understand it and have a say in improving it.

Let them help cook. They’ll eat.

References and further reading

The psychology below offers context for participation, motivation, and ownership. The five-step walkthrough is my application of those ideas to AI implementation.

• Motivation and self-determination. Richard M. Ryan and Edward L. Deci (2000), “Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being”. American Psychologist, 55(1), 68–78. Examines how autonomy, competence, and relatedness support motivation.

• Psychological ownership. Jon L. Pierce, Tatiana Kostova, and Kurt T. Dirks (2001), “Toward a Theory of Psychological Ownership in Organizations”. Academy of Management Review, 26(2), 298–310. Develops a theory of how people come to feel that an organization, or something within it, is theirs.

• The IKEA effect. Michael I. Norton, Daniel Mochon, and Dan Ariely (2012), “The IKEA effect: When labor leads to love”. Journal of Consumer Psychology, 22(3), 453–460. In experiments, people valued things they helped make more highly; successful completion mattered.

• The opening quotation. David Hume, A Treatise of Human Nature, 2.3.3.4, on reason and the passions.