Designing an Adoption System for a Six-Week Codex Pilot
Pillar
AI Leadership
Company
Accedo
Audience
Executive, Hiring Manager, Product Leader, Design Leader
Date
2026
PLAYBOOK BRIEF
Capability
AI adoption, enablement, operating model
Leadership level
Director
Overview
I led enablement and learning for a six-week, company-wide OpenAI Codex pilot. I split developer and knowledge-worker tracks, collected real workflow problems, ran a build-in-public Slack rhythm and microsite, tracked GitHub, SSO, preview, and quota blockers, and connected experiments to quality checks.
Evidence & limits
Evidence: The pilot ran through two tracks, workflow intake, a blocker log, shared Slack, a microsite and leaderboard, follow-up sessions, and quality rules. This documents how the pilot operated, not long-term adoption or business impact. Trade-offs: A leaderboard made activity visible but did not prove impact. Build-in-public work also surfaced private access issues, so participant details and commercial terms still needed clear boundaries. Limits and failure modes: A vague use case, no owner for access blockers, login or usage counts treated as value, no artifact to share, or unreviewed experiments moving into delivery. What this proves: I can describe the six-week operating programme, participation, and shared conversations. I do not yet have evidence of durable adoption, workflow savings, improved output quality, or the final company tool decision.
The six-week pilot list
The working list for our six-week OpenAI Codex pilot included nominations, developer and knowledge-worker tracks, problem statements, workspace setup, GitHub access, SSO, preview tooling, quota issues, and follow-up sessions.
I led the enablement and learning side. Giving someone access did not give them a useful problem, help them through a blocked account, or show them what good work looked like.
Two pilot tracks
I ran developer and knowledge-worker tracks and tracked their enablement and blockers separately.
I asked participants to bring real workflow problems rather than abstract prompts. Each person needed enough freedom to try something useful, a place to show the work, help when access failed, and a quality standard before anything moved closer to delivery.
The operating rhythm
The pilot included:
nominations and track framing
problem-statement and use-case intake
enablement sessions and shared examples
workspace setup and GitHub access
a blocker log covering SSO, repository permissions, preview tooling, and quota issues
a microsite and leaderboard that made activity visible
a Slack community for work, questions, feedback, issues, and challenges
follow-up sessions that kept the six-week pilot moving
quality checks and engineering standards for work that could affect delivery
I emceed the shared conversations and kept asking people to build in public: show what you are trying, ask for help, and let someone else learn from it.
The discussion reached beyond developers. The notes include participation from functions such as HR and sales engineering.
What the leaderboard could not tell me
The leaderboard helped people see momentum. It measured activity, not impact, so I did not use it as proof that a workflow had improved.
The quality rules still mattered. Shared experimentation could not mean unreviewed work moving into delivery. Participant details, private access incidents, and commercial terms remained private.
Set up one intake row
For every proposed pilot use case, record:
person or team
real workflow
developer or knowledge-worker track
current access blocker
artifact to share
quality check or reviewer
date for the continue, change, or stop decision
This row is a reader exercise synthesised from the pilot, not a field-for-field artifact I am claiming we used. If it contains only a login, there is still no workflow to learn from.
