Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 19

Organizational Adoption & Change Management

Last updated · 8 min read

19.1 Executive & Role-Based AI Literacy

Priority: Must Understand

Executive Definition: Role-based AI literacy means the level and kind of AI understanding required differs by job: a developer needs to understand agentic tool-use and code review implications, a knowledge worker needs to understand appropriate use and data handling, and an executive needs enough understanding to make investment, risk, and governance calls without being talked past by vendors or by their own technical staff. This is now a compliance requirement in some jurisdictions, not just good practice.

Why It Matters: The EU AI Act's Article 4 (in force since February 2025) legally requires providers and deployers of AI systems to ensure staff "involved in the operation and use of AI systems possess a sufficient degree of AI literacy," proportionate to each person's role, technical background, and the system they use: a binding obligation for any organization operating in or serving the EU, not a training nice-to-have. Separately, Gallup found only 8% of employees strongly agree that "AI has transformed how work gets done" at their organization despite 65% of AI users reporting improved personal productivity: a gap that typically signals literacy and process redesign lagging tool rollout, which is exactly what a literacy program is meant to close.

What I Need to Understand:

  • Article 4's proportionality principle: literacy requirements scale with role and risk, not a flat one-size-fits-all training module: your program needs role-based tiers (executive, developer, general knowledge worker) not one deck for everyone
  • The difference between tool literacy (how to use a specific product) and risk literacy (what can go wrong, when to escalate, what not to trust): most vendor-provided training covers only the former
  • Your own personal obligation as an executive setting AI strategy: enough literacy to challenge a vendor's claims and your own technical team's assumptions, not enough to build a model yourself
  • What "sufficient degree" means in practice for compliance purposes: there's no certification standard yet, so documentation of your training program and its rationale is currently your best evidence of compliance
  • The gap between adoption and transformation Gallup identifies: literacy alone doesn't close it, but its absence guarantees it stays open

Questions I Should Be Able to Ask My Team:

  1. Do we have role-differentiated AI literacy content (executive, developer, general staff), or is everyone getting the same generic training regardless of what they actually do with AI?
  2. Can we produce documentation showing who has completed what AI literacy training, mapped to their role and the systems they use: the evidence an EU regulator or auditor would ask for?
  3. What's our plan for keeping literacy content current as the tools and risks change: is this a one-time rollout or a maintained program?

Technologies / Standards / Companies to Know: EU AI Act Article 4, NIST AI RMF (as a literacy content source), ISO/IEC 42001.

Recommended Learning:

Time Investment: 1 hour

19.2 AI Champions, Communities of Practice & Use-Case Libraries

Priority: Should Understand

Executive Definition: An AI champions program identifies motivated employees embedded in business teams (not the central AI/platform team) who model real usage, mentor peers, and surface what's actually working, functioning as a peer-driven adoption layer that a top-down mandate or training rollout can't replicate. A use-case library is the artifact that program should produce: a growing, curated internal record of validated AI applications, so teams stop reinventing the same pilot in five different departments.

Why It Matters: GitHub's own internal playbook for this (a company whose product is developer tooling, so its adoption playbook is directly relevant to your developer population) treats champions as essential specifically because "buying AI tools without empowering people to use them is a fast track to failure." For an organization with both a large engineering population and a large professional/knowledge-worker population, a single central team cannot realistically drive grounded adoption in both; champions are the mechanism that scales adoption without scaling the central team headcount 1:1 with the workforce.

What I Need to Understand:

  • Champions are peer-selected/volunteer, not appointed by management: mandating "champions" top-down tends to produce compliance theater rather than genuine peer influence
  • The three-phase pattern GitHub documents: recruit volunteers (~30 days), build community infrastructure and cadence (~90 days), then hand ownership to the community itself rather than keeping it centrally run indefinitely
  • A use-case library only has value if it's curated (validated, with outcomes attached) rather than an unfiltered wiki of every experiment anyone tried: curation is the actual work, not the tooling
  • How this connects to your operating model (see AI Operating Models topic): champions are the informal complement to a formal hub-and-spoke structure, covering the reach a central CoE can't
  • Measurement is qualitative-plus-quantitative by design (adoption stories plus usage metrics): don't expect or demand a single clean ROI number from a champions program

Questions I Should Be Able to Ask My Team:

  1. Are our AI champions volunteers with real peer credibility on their teams, or are they people we assigned the title because someone needed to own it?
  2. What does our use-case library actually contain: validated, outcome-tagged examples, or an unfiltered list of everything anyone has tried?
  3. If we stopped centrally running the champions program today, would it survive on its own, or does it collapse the moment central attention moves elsewhere?

Technologies / Standards / Companies to Know: GitHub (publishes the most concrete public playbook), OpenAI Academy champion role guidance: read these as case studies from AI-tooling vendors, with the obvious caveat that they have an interest in you adopting more AI tools.

Recommended Learning:

Time Investment: 30 minutes

19.3 Employee Displacement Fear, Change Management & Acceptable Use Policies

Priority: Must Understand

Executive Definition: This topic covers three linked things you're accountable for as a leader: managing genuine, measurable employee anxiety about AI-driven job loss; running change management that acknowledges that anxiety instead of talking past it; and publishing an Acceptable Use Policy (AUP) that tells employees clearly what AI tools they may use, on what data, and under what constraints: closing the gap that otherwise gets filled by unsanctioned "shadow AI" use.

Why It Matters: Gallup found 18% of all U.S. employees believe it's likely their job will be eliminated by AI within five years, rising to 23% among employees at organizations that have adopted AI, and that fear is not evenly distributed, meaning your own workforce's number could be materially higher depending on role exposure. Organizations that have adopted AI also report both more hiring (34% vs. 28%) and more workforce reduction (23% vs. 16%) than non-adopters, so "AI means fewer jobs" is not simply true or false at the org level: it means more workforce churn in both directions, which is itself what needs managing, not just the layoff fear.

What I Need to Understand:

  • Gallup's finding that fear is rising with adoption (15% in mid-2024 to 23% now among AI adopters): meaning your own rollout, if unmanaged, likely increases anxiety even as it increases productivity, and treating these as automatically offsetting is a mistake
  • The distinction between managing fear (communication, transparency, career-pathing) and managing actual displacement (real headcount decisions): conflating the two either dismisses legitimate fear or over-promises job security you can't guarantee
  • What a real Acceptable Use Policy must specify concretely: which tools are sanctioned, what data classifications may/may not be sent to which tools, human-review requirements for AI output in specific workflows, and consequences for violation: a vague "use AI responsibly" memo is not a policy
  • The OWASP LLM Top 10's "Excessive Agency" and "Sensitive Information Disclosure" categories are the concrete risks a good AUP is written to prevent, giving you a technical anchor for policy language rather than only an HR one
  • Only 8% of employees strongly agree AI has "transformed how work gets done" at their organization (Gallup) even where usage is high: meaning most of your workforce likely still experiences AI as an add-on tool, not a redesigned way of working, which is itself a change-management gap

Questions I Should Be Able to Ask My Team:

  1. Have we actually measured employee sentiment and job-security fear related to our AI rollout, or are we assuming it's fine because usage numbers are up?
  2. Can I see our current Acceptable Use Policy, and does it name specific data classifications and specific approved tools, or is it a page of generic principles?
  3. What happens today, concretely, to an employee who pastes customer PII into an unsanctioned AI tool: is there a real enforcement mechanism, or does the policy exist only on paper?

Technologies / Standards / Companies to Know: NIST AI RMF (Govern function: the basis for AUP structure), OWASP Top 10 for LLM Applications (technical risk categories an AUP should reflect), Gallup workplace research (ongoing employee sentiment tracking).

Recommended Learning:

Time Investment: 2-3 hours