Implementation & Enablement · First 90 days

How I'd stand up AI adoption — and prove it fast.

Most AI-enablement hires aren't let go because they can't do the work. They're let go because they measured activity instead of outcomes, or chased an org-wide rollout and had nothing concrete to show by month three. This is how I'd avoid both: a 30/60/90 plan built to land one measurable, visible win early — then scale a proven playbook, not a hopeful one.

A reusable methodology · internal AI-adoption program or vendor-side customer rollout · works the same way

Why enablement stalls

Three failure modes — and the one principle that beats them

The reason "we rolled out AI and nothing changed" is so common isn't mysterious. It's almost always one of these three, and they're all avoidable with a plan that's designed around them from day one.

Failure 1

Measuring activity, not outcomes

Reporting logins and license counts. Leadership doesn't fund "people opened the tool" — they fund hours saved and work that got better. If you can't connect usage to a result, you have no story.

Failure 2

Boiling the ocean

Trying to enable the whole org at once. Effort spreads thin, no single team gets to a real win, and by month three there's nothing concrete to point at. Breadth without depth reads as no progress.

Failure 3

No baseline, no pre-agreed target

Starting without measuring where things stood, and without agreeing up front on what "good" means. Success becomes an argument after the fact instead of a number everyone signed off on early.

The principle: land one measurable win in one team first — against a baseline, on a metric leadership pre-approved — then scale the playbook that worked. Depth before breadth. A proven motion before a big rollout.

The measurement stack

"Track adoption" isn't one system — it's six layers

Before deciding to build or buy a tracking system, it's worth seeing that adoption is a stack. The first three layers are largely given to you — the enterprise AI vendors already ship the telemetry. The bottom layers are where real work, and a real differentiator, live.

Provisioning
Who has access — seats assigned
SSO / identity (Okta, Entra)
Given
Activation
Who actually logged in and used it at all
Vendor admin console
Given
Usage depth & breadth
How often, how deep, % of org active weekly
ChatGPT Enterprise · Claude · Copilot analytics
Given
Proficiency
Are they actually any good at it
Assessment + certification / survey
Buy or build
Workflow integration
Is it embedded in real work, or just dabbling
Use-case inventory + champion reports
Build (light)
Outcomes & ROI
Hours saved, cycle time, throughput, business metric moved
Stitched sources vs. baseline
Build

The build-vs-buy call follows from the stack. Don't build what's commoditized — usage telemetry is solved, and bolt-on platforms cover proficiency and roadmap reporting. Spend the build budget on the one layer no tool can sell you: stitching your org's specific data together and tying usage to your outcomes. That last mile is where a custom build beats off-the-shelf — and it's the layer that produces the ROI story leadership actually wants.

The plan

First 90 days, end to end

Three phases, each with a single job. Month one finds the target and the baseline. Month two lands the win. Month three turns one win into a repeatable system. Every phase ends in something visible.

DAYS 0–30

Baseline & beachhead

Job of the month: know exactly where things stand, and pick the one team where a fast win is provable.

  • Stand up the baseline in week one from telemetry that already exists — vendor admin consoles, no engineering required. You can't show change you never measured the start of.
  • Run a listening tour and use-case inventory: where's the repetitive pain, who's already curious, what work would visibly improve. This is reconnaissance for the beachhead.
  • Pre-negotiate "good" with leadership: agree on 2–3 target metrics before touching anything, so success is a number everyone signed off on — not an argument in month three.
  • Pick the beachhead: one high-pain, high-visibility team. The deliverable of month one is a target, not a rollout.
Visible by day 30: a baseline dashboard and a named first-win team with a leadership-approved target.
DAYS 31–60

Land the first win

Job of the month: one team, one measurable, visible result — done right, not done wide.

  • Embed with the beachhead team: trainings, job aids, 1:1s, and sitting inside their real work. Adoption happens in the workflow, not in a webinar.
  • Build the one measurement piece nobody sells you: connect that team's usage to its actual outcome — hours saved, cycle time, throughput — against the baseline.
  • Stand up the first champions: identify and equip the two or three power users who'll carry it after I move to the next team.
  • Report weekly and visibly: a simple dashboard leadership sees every week, so momentum is felt, not claimed.
Visible by day 60: a documented, numbers-backed win — "this team, this metric, this much better."
DAYS 61–90

Make it a system

Job of the month: convert one win into a repeatable program that scales without me as the bottleneck.

  • Scale the proven playbook to two or three more teams — copy what worked, don't improvise a new approach each time.
  • Train-the-trainer: hand local enablement to managers and champions so adoption compounds instead of routing through one person.
  • Publish the adoption dashboard org-wide: usage → proficiency → outcomes in one view, refreshed automatically.
  • Bring leadership the ROI story and the next-quarter roadmap: what it returned, what scales next, where to invest.
Visible by day 90: a repeatable motion, a live org-wide dashboard, and a funded plan for the next quarter.

What I'd report

Leading indicators move first; lagging indicators are the ROI story

Two kinds of metrics, reported differently. Leading indicators show momentum week to week and tell you early if adoption is real. Lagging indicators take longer to move but are what justifies the budget — so I track both from day one and never report one without the other.

Leading — momentum

Moves in weeks · early signal adoption is sticking

  • Weekly active users as a % of provisioned seats
  • Usage depth — sessions and meaningful uses per active user
  • Number of use cases actually in production (not piloted)
  • Champions trained and active per team
  • Training completion / certification rate

Lagging — the ROI story

Moves in months · what leadership funds against

  • Hours saved per team, against the baseline
  • Cycle-time or turnaround reduction on a named process
  • Output / throughput change on real work
  • Confidence and sentiment shift (pre/post survey)
  • Retention of usage — no spike-and-crash after the training high

Why I can actually run this

It's not a template I found — it's what I've done

I've driven adoption at scale

Sole owner of enablement for an internal GenAI platform rolled out across ~800 staff — guides, group trainings, 1:1s, road shows, train-the-trainer, and a ~30-person AI community of practice. Adoption was the deliverable, not a side effect.

I can build the measurement layer myself

Three years building RAG systems, agents, and automation on the Anthropic API. The "stitch the sources and tie usage to outcomes" layer that nobody sells you — Python, FastAPI, data plumbing — is work I can ship, not just spec.

I'm fluent in regulated environments

Nine-plus years inside a government compliance environment — data classification, audit, access control. The instincts responsible, governed AI deployment demands are already mine.

I translate across audiences

Turning dense technical systems into the trainings and plain-language guides non-technical staff actually use is the core of my current role — and the exact skill that turns a tool nobody opens into one a team relies on.

Let's talk about your first 90 days

Open to implementation, enablement, internal-tools, and applied-AI roles in the Boston area. In-office or hybrid preferred; open to remote.