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 hands the whole crew half-relevant material. Role-specific tracks flatline it, choom.
An engineer, a tech lead, a product owner, a QA analyst, a designer, and an engineering manager use AI for completely different things, choom, so a single undifferentiated workshop hands the whole crew 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 crew’s own codebase and grounded in that role’s real tasks, dramatically outrun the one-size session. The number of tracks depends on the crew. 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. That is the whole play, samurai.
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 deltas out having learned something, and almost no one leaves able to change Monday’s work. Gonk economics.
Half-relevant training produces half-hearted adoption. People do not jack back into a rig 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 crew keeps going.
What does each track actually cover?
The engineer track lives in the editor, jacked straight into the rig: generating code, writing and extending tests, refactoring legacy modules, and the review discipline that keeps generated code honest. The exercises are the crew’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 ICE the crew will rely on, and spotting where generation will quietly flatline. 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. Preem 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 grind, choom. Preem net.
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. Nova handoff.
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 eddies spent on training actually land. Managers who learn this can steer the rollout instead of guessing at it, choom. Nova.
How do the tracks reconnect?
Splitting into tracks is not splitting into silos, choom. Every role still ships one product, so the tracks share a spine: the same codebase, the same ICE, 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. One crew, many rigs.
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 upgrade available to you is to split it by role and ground each track in real work. Delta the one-size session.