A playbook published by GitHub on July 22, 2025, written by the program manager director of its internal “AI for Everyone” initiative, setting out how the company went about building AI fluency across its own global workforce. Its premise is that companies often invest heavily in AI tools only to see adoption confined to a small group of early enthusiasts, and that they fail because they treat AI adoption as a technology problem when it is a change-management problem — “rewiring how people work” rather than installing software. The document presents itself as the product of that initiative and as a practical blueprint other organizations can apply.
It describes enablement as a holistic system of mutually reinforcing components that blends top-down strategy with grassroots momentum, resting on executive support and clear policies, and organizes that system as eight pillars. Most of the document then explains how to put each pillar into practice, followed by a measurement framework and a checklist phased over the first 30 days, the first 90 days, and ongoing work.
Details
The eight pillars are AI advocates (a volunteer network of internal champions), clear policies and guardrails, learning and development opportunities, data-driven metrics, a dedicated responsible individual, executive support, right-fit tooling, and communities of practice.
- Executive support. Leaders are expected to explain the “why” in terms of employees’ daily work — for engineers, eliminating toil so that Copilot handles boilerplate, unit tests and pull-request summaries — and to be transparent that AI will automate tasks and change jobs. The playbook’s example is to say not “Your job is safe” but how jobs will change and how people will be supported in learning new skills. Managers are to be challenged to rethink their teams’ workflows; senior individual contributors are given a dual mandate to use AI to elevate their own work and to scale AI fluency to others.
- Policies and tooling. An acceptable-use policy developed with IT, HR, Security and Legal is treated as a prerequisite, kept in one easy-to-find document listing approved tools and the data appropriate to each. The recommended model is tiered: tier 1 holds fully vetted tools safe for confidential company and customer data, including the company’s own first-party products; tier 2 covers all unvetted public and consumer tools, which may be used only with public, non-sensitive data. The stated rule of thumb is that a tool not on the vetted list is treated as public.
- AI advocates. Advocates are recruited simply by asking for volunteers, and act as local experts, showcase use cases from their own teams, feed their teams’ views back to the program and help co-lead training. The central program supports them with their own community channel, a direct line to leadership, and a “Train the Trainer” approach.
- Communities of practice. Rather than one AI channel, the playbook recommends distinct communities — a general-use one, a developer-focused one and function-specific ones — each with a charter and designated leaders.
- Learning and development. A centralized resource hub, a few “zero-to-one” learning paths drawn from existing external content rather than built in-house (because AI features change too quickly for internal training to stay relevant), reusable building blocks for technical users, and AI in new- hire onboarding.
- Dedicated program leadership. A directly responsible individual (DRI) or small team, described as an enabler rather than a gatekeeper, owns the strategy, change management, tool intake and policy lifecycle, adoption metrics and the case for business return. At GitHub this is resourced with a program director and a program manager.
- Metrics. Measurement proceeds in three phases: breadth of adoption (monthly active users and monthly engaged users), depth of engagement (segmenting users as dedicated, occasional or “tire kickers” by days active per month, and total AI events), and business impact, for which the playbook refers readers to GitHub’s Engineering System Success Playbook and lists metrics such as cycle time, code churn, pull-request size, developer wellbeing and perceived productivity. It notes that AI can sometimes lead to larger, more complex pull requests, which is why pull-request size is worth watching.
The playbook’s conclusion is that there is no silver bullet: adoption takes a sustained, data-driven effort, and investing in AI tools without a deliberate enablement strategy wastes resources. It is GitHub’s account of its own program and states no outcome figures for it.