enablement isn't evangelism

i wanted this role. i made the case for it inside the org, and that’s where i landed. ai enablement lead in my area, ways-of-working transformation, all of it. the team came together cross-discipline by design, sitting across the product development lifecycle so the people on it can actually shape how the work gets done end-to-end. the mandate reads make the place work better with ai. the arc i’m signed up for is to evolve our pdlc into an asdlc — the ai-augmented version of how we build. and there’s a roomful of expectations that don’t agree with each other about how any of that should look.

what i’m walking into isn’t a blank page. the tools are landed, the licenses are in place, and there are already people across the area doing real work with them — sharing patterns, teaching the person next to them, showing up to sessions with something to compare notes on. the journey is well underway. the question for me isn’t which tools — it’s how to extend what’s already working to the rest of the area, without falling into the easiest trap of this role.

the easy trap is well-mapped. lean on the visible thing. for us, the visible thing is the token exchange — a bi-weekly ai-and-pizza session i run here in copenhagen, where people bring what they’ve tried, what worked, what didn’t. it’s a real surface for the curious and i learn a lot from what shows up in the room. our area has development hubs across multiple countries, and the in-person format that lands in one room doesn’t automatically travel — extending the token exchange into the other hubs is one of the first concrete pieces of work i own.

and even there, if the token exchange becomes the whole job, we’ll be measuring the wrong thing. demo the magic, count attendees, report the count up — six months in, the slides look great while the day-to-day stays the same. attendance is a starting point, not the destination. adoption is the next step. habit is what i’m here for.

meet the skeptics where they are

the enthusiasts are already in, and they’re a real engine — they were going to figure it out on their own, they have, and they’re pulling others along with them. the next wave comes from somewhere else. the middle — the chasm geoffrey moore named decades ago — is the people who watched a few demos, tried it on something they cared about, got a wrong answer, and quietly stepped back.

they’re not wrong. the demo always works. the actual workflow often doesn’t, not yet. they have legitimate concerns about accuracy, traceability, and what happens when the model is confidently wrong on something a customer reads. these aren’t bad-faith objections. they’re the early signal of where the rollout needs more care.

so my first quarter isn’t a roadshow. it’s the unglamorous one. sit with the skeptics. hear what broke. work with them to find the boring workflow the tool can handle reliably, every day. earning a skeptic’s trust isn’t done by impressing them. it’s done by being right about one small thing and surviving the scrutiny.

show the boring case, not the impressive one

the impressive demo is part of why the skeptics held back in the first place. write the report in thirty seconds. summarise the hundred-page document. they watched the output, found a thing the model just made up, and quietly filed the whole thing under not yet.

the boring case is the opposite. this thing you do every monday morning that takes ninety minutes and you hate. here it is in twenty, with the seams visible. nobody writes a linkedin post about it. nobody puts it on a slide. but the person who does it every monday remembers it on tuesday, and next monday they do it the new way without being told to. that’s the unit i’m chasing — one workflow, one team, one habit, repeated.

this is the same loop as eval-driven prompt iteration, pointed at people instead of a prompt.

measure work changing, not seats warm

the metric trap is easy to fall into. seat licenses sold. tool mau. prompts run per week. attendance at the token exchange. they’re reportable, they grow, they look like progress — and they’re useful early signals. but on their own they measure activity surface, not work surface.

the metric i want, for each workflow we touch:

• before — how long does this take, how often does it fail, who hates it
• after — same three questions, same team, same workflow

if the after numbers don’t move, the rollout doesn’t get pushed further, no matter how many seats are warm. if they do move, the rollout is justified to anyone — including the skeptics, and theirs is the buy-in that turns this into the new normal.

the translator’s job, pointed inward

i wrote about translation for the engineer-to-stakeholder direction. this role needs the same translation, pointed in both directions.

upward — the leaders deciding whether this work continues see press cycles, vendor decks, and other people’s anecdotes. my job is to give them a better model. one that survives contact with their actual question, which is usually is this saving us money or is it fashion. workflow numbers translate. attendance counts don’t.

downward — engineers and operators don’t need to hear about ai enablement. they need to hear that the thing that takes them ninety minutes today might take twenty, and they get the other seventy back. the brief that lands is the one that names a thing they’d happily hand off.

future-proofing is a capability, not a project

the part of the brief i take most seriously is future-proof the organisation. that phrase usually gets reduced to use more ai, which misses what’s actually at stake.

future-proofing isn’t a tool count. it’s whether the org can absorb the next change after this one — and the one after that. the model providers will rev. the regulatory surface will shift. the tools we’re now adopting will be partly obsolete in eighteen months. what doesn’t go obsolete is the move itself — take a workflow, redesign it around what the new capability lets us do, ship the change, measure it. practiced often enough, that’s the muscle that future-proofs. one tool migration is a project. ten of them, run by the people closest to the work, is a capability.

the destination i’m working toward is the move from our current pdlc to one that’s agent-shaped end-to-end. discovery, definition, design, build, test, release, run — each stage gets the agentic capability baked in where it actually helps, not bolted on the side. that’s an asdlc in the only honest sense of the term: not a new process doc, but the old lifecycle with the new capability practiced inside it, stage by stage, one workflow at a time. that’s why the team is cross-discipline by design — every stage has a different owner, and the redesign at each stage has to be made by the people who actually run it. multi-year arc. nothing about it gets done in a quarter.

so the success condition for this role isn’t we adopted the current tools. it’s we got good at adopting whatever’s next. if i leave the seat in a year and the next wave doesn’t need an enablement lead in my area because the muscle is already there — that’s the win.

what i’m most likely to get wrong

the failure mode i’m most worried about is the one i’ve watched others fall into: confusing motion for progress. there’ll be pressure to do something visible before the skeptics have been listened to. there’ll be a tool a senior leader saw at a conference. there’ll be a quarter where reporting comes due before the work has changed, and the easy answer will be to celebrate adoption metrics instead.

the discipline i'll need most is the one i have least practice with at this scale: saying not yet, and here's why — and surviving the silence that follows.

i wanted this role. nine months from now i’ll know whether i was right to.