Context
The organisation had the same relationship with generative AI that most services businesses had in 2025: real enthusiasm, a handful of people using it well in private, no standards, and a leadership team that wanted a strategy rather than a collection of anecdotes. I was made the AI adoption lead with a broad mandate and no existing playbook.
The problem
The instinct in this situation is to run training. I'd argue the constraint is almost never capability or knowledge — it's that people can't tell which of their tasks is a good fit, don't trust the output enough to stake their work on it, and have no safe place to fail while they find out. Training that doesn't address those three things produces a spike in usage and a return to baseline six weeks later.
So the real problem was: how do you make adoption an evidence problem rather than a persuasion problem?
Constraints
- A services business, where billable hours are the unit of account and time spent learning is time not billed.
- Client confidentiality, which ruled out a large class of tools and workflows outright and made the governance question load-bearing rather than theoretical.
- A wide skill spread — from engineers who wanted to build agents to delivery staff who wanted a better way to write a status update.
- No budget assumption. Anything I proposed had to justify itself before it could ask for spend.
What I did
Picked workflows where failure is cheap and visible. The first wave deliberately targeted internal, reversible, high-frequency tasks — story writing, backlog grooming, documentation, status synthesis. Not because they were the most valuable, but because a wrong output costs a minute and everyone can see whether it worked.
Built a reusable Business Analyst agent rather than a personal tool. Using Claude Code with the Atlassian MCP, I built an agent that drafts Jira stories, grooms backlogs, and generates acceptance criteria from a brief. The important design decision was making it a template — configurable, documented, forkable — so other teams adopted and adapted it rather than requesting a feature from me. It ended up being used well beyond the team it was built for.
Put production automation behind human-in-the-loop guardrails. Using n8n orchestrating LLM APIs, I established automations that removed more than 60% of the manual effort on targeted workflows. Every one has an explicit answer to three questions: what does a wrong output cost, who catches it, and how long does catching it take. Where the cost is low and reversible, the automation runs unattended. Where it isn't, the review step is part of the design, not scaffolding to remove later.
Wrote the responsible-AI standard before the incident, not after. Internal best practices on evaluation, guardrails, and human-in-the-loop design — what a use case must demonstrate before it goes near client work, what data may never leave which boundary, and what "good enough for this use case" means in writing. Leadership cited it and peer teams adopted it, which mattered more than its content: it made AI proposals something that could be assessed rather than argued about.
Ran enablement as cohorts with artefacts, not as lectures. 50+ staff trained, with each cohort producing something real — a working automation, an agent config, a prompt library for their own practice — so the output of training was infrastructure rather than attendance.
Outcome
- More than 60% of targeted manual effort removed on the workflows we instrumented, with guardrails that survived contact with client work.
- A reusable agent pattern adopted across multiple delivery teams — the thing I actually optimised for.
- A written responsible-AI standard cited by leadership and adopted by peer teams.
- 50+ people trained, each leaving with a working artefact rather than a certificate.
What I'd do differently
I should have instrumented the baseline harder before starting. We have credible before-and-after numbers on the workflows we automated deliberately, but we're weaker on the diffuse gains — the hours people saved on their own once they knew what was possible. That's the number leadership asks for, and capturing it retroactively is nearly impossible. Next time, a two-week measurement window before any enablement runs.