Approach · how I run AI enablement and transformation

The work doesn't run in a line anymore. It runs in loops.

The work gets more interesting when a team can touch something early. Every version gives us evidence, every round of testing ends with a clear decision about what to change next, and the people doing the work stay inside the loop.

01

So what does it mean to get loopy?

Three loops. Miss one and the other two stop paying off.

  • Human in the loop. People bring the judgment, the taste, and the leadership; AI needs more of them, not fewer. The decision stays with a person at the kickoff and at every handoff: three approvals on intake, "flag, never silently correct" as a logged ruling, thresholds that route the uncertain cases to a person. The approval is cheap; deciding what to send through it is the design.
  • Feedback loop. Measure what success looks like for the person using it, not the dashboard. Engineering was the acceptance test for the intake skill: if an engineer couldn't start a POC from the output, it wasn't working. Reader tests with editors on live reports. The corrections are the requirements.
  • Continuous improvement loop. A new model every week, and people learning at warp speed. The intake skill took one to two months of refinement as I did more intake. Freeze, batch, run variants, replay, then decide. A faster draft that adds risk downstream isn't a win.

In the middle sits what keeps them honest: what good looks like, written down before the first draft. Without it, a loop just spins.

One hand-drawn loop through the work, with three named loops on it: human in the loop at the gates, feedback where it is used for real, and continuous improvement where it is refined. An orange dot travels the loop. record the call extract · 22 fields build v1 · a week use it on real work refine on feedback they own it ① humanin the loop ② feedback ③ improve what good looks like written first · pass/fail · per job and a log of every ruling, with a named verifier
One turn through the work. A person decides at the orange points, the work reports back from real use, and the next turn is better than the last.
02

What changed, in one table

The line (how it used to run)The loops (how I run it now)
How the ask arrivesA deck, then three or four intake calls, then weeks of research. About two months to an intake, and another month or two to turn business asks into technical requirements.We record the working session. A skill turns the recording and transcript into a structured story—requirements, open questions, and talking points—the same day. With those requirements in hand, I know whether I can build the first version myself or hand it to an engineer.
Who does whatPM, then design, then engineering. Sequential handoffs. Engineers start from a blank page.User, PM, and engineer on the same recording. I propose a first-draft solution and they correct it live. The corrections are the requirements.
Cycle timeIntake in two to four months; a POC a month or two after that.One intake, and a week later a working POC.
How "good" gets definedAfter the demo, by whoever is loudest.Before the build, in writing: pass/fail rubrics and release thresholds per job. A person decides inside each loop, and every ruling is logged.
03

Steps to get loopy

The five steps drawn as one thread of five loops. Define the problem and triage sit in the feedback loop, build or reuse in the improvement loop, and what good looks like and enable are human gates where a person decides. An orange dot travels the thread. define the problem triage build or reuse what good looks like enable the feedback loop the improvement loop human in the loop · a person decides
Five steps on one thread: the first two turn in the feedback loop, the third in the improvement loop, and a person decides at the last two.
Define the problemRecord the real work. Evidence behind every claim.
TriageWanted, buildable, needed? Then start, stop, continue, or defer, in writing.
Build or reuseUse what exists. Build only the part that's yours.
Define what good looks likePass/fail rubrics and thresholds before the demo, not after.
EnableCo-build with the team, then hand it off. You own it.
04

The weave: the loops, laid end to end

Zoom out from one loop to a whole project and this is what the loops look like: one thread from research to launch, with something working at every turn.

The same work gets a prototype at every turn, and the arrows that matter most run backwards—each prototype teaches us something that improves the step before it.

The process as one thread from research to a better launch: research, ideation, concept prototype, spec, detailed design, design prototype, technical prototype, a better launch. The three prototypes are drawn as loops where a person decides; a dashed hand-drawn arrow runs back from the design prototype to the step before it, and a long dashed arrow returns from the launch to research. research ideation conceptprototype spec detailed design designprototype technicalprototype a better launch then around again, with the next thing each prototype improves the step before it
Research to a better launch as one thread, with a prototype at every turn.

Where

Christine Nguyen · Austin, Texas.
Open to Head of AI Enablement, Director of AI Transformation, and AI adoption leadership. Don't let the titles lock you in: if the work matches my skills, I'm open to it.

If you've read this far, we should probably talk.

Bring me the AI problem your team is still trying to explain.

Click to copy.

Email

christineqnguyen@gmail.com

LinkedIn

Open LinkedIn

Résumé

Coming soon

Open source

GitHub