Every L&D team building an AI capability programme eventually arrives at the same sensible-sounding decision: let's map the training to roles. Developers get the technical track. Managers get the leadership track. Business users get the productivity track.
The intention is right. The execution is almost always wrong. And the error is not obvious — because the framework looks coherent on paper.
The problem is that most role-based AI frameworks map job title to training content. A developer gets a technical curriculum. A data analyst gets a different technical curriculum. A project manager gets something lighter.
But job title is a poor proxy for what actually matters: the AI interaction pattern the person performs in their work. Two developers on the same team can have completely different interaction patterns. One is building pipelines that call LLM APIs — she needs to understand context windows, token management, and retrieval patterns. The other is using AI-assisted code completion — he needs something entirely different.
When you map by title rather than by interaction pattern, you consistently either over-train or under-train the actual population. The senior engineer who never touches model code sits through a curriculum built for someone who does. The analyst who is quietly building RAG-powered dashboards gets a productivity track that does not touch what she actually needs.
The correct starting point is not the org chart — it is an interaction audit. Before designing any AI curriculum, ask: in this role, what does the person actually do with AI tools today, and what will they be expected to do in 12 months?
This produces a map of interaction patterns, not job titles. Common enterprise patterns include:
The curriculum design follows from the interaction pattern, not the title. A product manager who is integrating AI into their team's workflow needs different training than a product manager who is using Copilot to draft documents — even though both are product managers.
The second common error in role-based frameworks is treating AI capability as a single level within each role. In practice, AI capability has at least three levels: awareness, application, and design.
Awareness is understanding what AI can and cannot do in one's domain. Application is being able to use AI tools effectively for one's actual work. Design is being able to structure AI-powered workflows and evaluate their quality.
Most role-based frameworks conflate these levels. The manager track is often awareness-heavy — appropriate for some managers, but inadequate for managers who need to evaluate AI tool proposals or commission AI-enhanced programmes.
Before building a role-based AI framework, ask: are we mapping to what people are titled, or to what they actually do? The answer to that question determines whether the framework produces capability or the illusion of it.
The second question is harder: how will we know whether the capability we build is being used? The answer requires measurement that most AI programmes do not currently attempt — and that is a separate conversation worth having.
Browse our upcoming batches — live, instructor-led, delivered on Orbit.