AI training needs a track per role, not one shared workshop
Engineers, leads, POs, QA, designers, and managers use AI for different work, so one shared workshop gives everyone half-relevant material. Role-specific tracks outperform it.
An engineer, a tech lead, a product owner, a QA analyst, a designer, and an engineering manager use AI for completely different things, so a single undifferentiated workshop hands everyone material that is only half-relevant to their actual job. After training more than 700 practitioners, the clearest lesson is that role-specific tracks, each built on the team’s own codebase and grounded in that role’s real tasks, dramatically outperform the one-size session. The number of tracks depends on the team. The point is that training has to be role-specific, not one-size-fits-all. The fix is not more content. It is content aimed at the right person.
Why does one shared workshop underperform?
Put six roles in one room and teach them the same prompts, and you optimise for the average person who does not exist. The engineer sits through requirements-shaping material they will rarely use. The product owner sits through refactoring demos they cannot act on. The QA analyst gets generation tips but nothing on edge-case discovery or regression coverage. The designer hears about review discipline but nothing on prototyping or design-to-code handoff. The tech lead and the engineering manager get neither the review-at-scale workflow nor the planning and reporting work they actually need. Everyone leaves having learned something, and almost no one leaves able to change Monday’s work.
Half-relevant training produces half-hearted adoption. People do not return to a tool they only half-understood in a context that was not theirs. This is the same point I make about practice on real work in what 700 engineers taught me about adoption: relevance is the variable that predicts whether a cohort keeps going.
What does each track actually cover?
The engineer track lives in the editor: generating code, writing and extending tests, refactoring legacy modules, and the review discipline that keeps generated code honest. The exercises are the team’s own tickets, not toy katas.
The tech lead track moves up a level: reviewing AI-generated work at scale, shaping architecture with AI assistance, setting the guardrails the team will rely on, and spotting where generation will quietly go wrong. Leads need to judge output, not just produce it.
The product owner track sits before any code exists: turning vague intent into clear specifications, drafting acceptance criteria, exploring edge cases, and pressure-testing requirements. POs who learn this stop being a bottleneck and start feeding the engineers cleaner inputs.
The QA track focuses on coverage: generating test cases from real features, discovering the edge cases a human checklist tends to miss, and building regression coverage that keeps pace with how fast generated code now ships. QA people who learn this catch more with less manual effort.
The designer track moves fast and stays close to the product: rapid prototyping to explore options before committing, generating copy and content variants to test, and tightening the design-to-code handoff so what ships matches what was drawn. Designers who learn this hand engineers something far closer to buildable.
The engineering manager track is about oversight, not output: using AI for reporting and planning, reviewing AI-assisted work without being the bottleneck, and tracking adoption so the investment in training actually lands. Managers who learn this can steer the rollout instead of guessing at it.
How do the tracks reconnect?
Splitting into tracks is not splitting into silos. Every role still ships one product, so the tracks share a spine: the same codebase, the same guardrails, the same definition of done. A product owner who understands what the engineers can now generate writes better specs. A lead who knows what the POs are producing reviews with the right context. A QA analyst who sees what designers prototyped tests the real intent, and a manager who watches all of it can plan against reality. The tracks diverge on tasks and reconverge on the shared work.
This role-specific design is the core of how I run enablement and training, and the full programme behind the 700+ figure sits on my speaking page. If your rollout is one workshop for everyone, the cheapest improvement available to you is to split it by role and ground each track in real work.