the method
Adoption is a teaching problem, not a documentation problem.
Every failed AI rollout I've ever audited had documentation. Guidelines existed. The wiki page was written. What was missing was capability — people who understood the system well enough to run it, improve it, and defend it when things got busy. This page is the method I use to build that capability, refined across nearly two decades and every engagement on the proof page.
five moves, one arc
1Diagnose
Before anything gets built, I audit the business ecosystem: how work actually flows (versus how the org chart says it flows), where knowledge lives and where it dies, what governance exists and what's merely assumed, and where the friction genuinely comes from. The presenting problem is rarely the real one — “we need AI training” usually turns out to mean “our workflow can't absorb a new tool.”
You get: a precise map of the problem, not a restatement of your request.
2Redesign
Workflows get reshaped around how the work actually happens — where AI earns a place in the process and, just as deliberately, where it doesn't. Operating models, decision rights, and hand-offs are designed on paper before anything is configured, because a bad process automated is a bad process accelerated.
You get: a future-state design your teams recognize as their real work, improved — not a theoretical workflow imported from a slide.
3Build
This is where Techtuition differs from most transformation consulting: I build what I design. Governance frameworks, evaluation criteria, standards, playbooks — and the technical infrastructure itself: agentic AI workflows, MCP-based integrations, RAG architectures, evaluation systems, workflow automation. Not as a software agency delivering to a spec, but as the same person who diagnosed the friction, building in production with your team so the system fits the organization it has to live in.
You get: a working system, not a recommendation to go build one.
4Enable
People learn the system by running it — workshops inside real work, office hours, train-the-trainer pathways, and materials tiered from individual contributor to executive. This is the move most engagements treat as an afterthought and I treat as the point: the ~200 practitioners I trained at Coursera are why that system survived my departure.
You get: teams that can operate, improve, and teach the system themselves.
5Leave
Independence is the exit criterion, planned from the first week. Ownership transfers to named people, measurement stays behind to prove the change held, and the engagement ends. A system that still depends on the consultant is a system that failed.
You get: your organization, more capable than I found it — and no ongoing dependency to pay for.
the framework
Eight parts, taught for four years, before it had a market category.
The diagnostic backbone of this method is an eight-part AI Enablement framework I created and taught across a four-year engagement with the UX Content Collective — training hundreds of practitioners supporting Fortune 100/500 organizations. It teaches teams to assess organizational design, business functions, governance, and knowledge ecosystems as the foundation for AI adoption — because adoption succeeds or fails on the organization, not the tool. Alongside it sits a companion eight-part Content Operations framework covering operating models, governance, workflows, decision rights, and collaboration practices. Both predate the current wave of “AI enablement” as a job title. The market caught up to the method; the method didn't chase the market.
what this isn't
not ai training
Trainers leave after the workshop, and nothing changes Monday. Training here is one move of five — the delivery mechanism of capability, never the product.
not an automation agency
Agencies build automations; organizations quietly stop using them. My method exists because adoption is the hard part — behavior change is the deliverable, and the technical build serves it.
not traditional consulting
The deck-then-depart model ends exactly where the difficulty begins. I stay through implementation, and my proof points are systems still running years later — a claim the slide-deck model structurally cannot make.
Unlike transformation consultants, I can move from strategy into implementation. Unlike technical vendors, I build the organizational system around the technology — governance, training, ownership — that determines whether it gets used at all.
See the method against your problem.
Thirty minutes, no deck. Bring the workflow that's stuck or the mandate that's stalling, and I'll tell you honestly which move it needs first.