Most AI training for software companies is booked for developers. Booking developers first makes sense on paper. Developers write the code, the tools are marketed at developers, and the licence spend usually sits in the engineering budget.
The trouble is that code is only one stop on the way from an idea to something a customer uses. A product owner decides what to build. An analyst turns it into stories. A designer works out how it should feel. A tester decides what proves it works. Someone in operations keeps it running. If only the developers change how they work, every one of those handoffs stays exactly as slow and as fuzzy as it was before.
So when I run my programme for teams, I ask for the whole team. This article explains why, and what whole-team training looks like in practice.
Software delivery has always depended on the whole team
Before I trained anyone on AI, I spent years running cross-functional teams. At a software company where I've been fractional CTO, I run an engineering department of five cross-functional teams made up of DevOps engineers, developers, test engineers, business analysts and product owners. At Astute, as head of engineering and DevOps, I had 25 direct reports across development, testing, business analysis and DevOps.
Running those teams taught me that delivery problems rarely live inside one role. Delivery problems live in the gaps between roles: a story that meant one thing to the analyst and another to the developer, a test written after the fact because nobody agreed what "done" meant, a design that ignored the error states. AI tools don't close those gaps on their own. A developer with a fast agent and a vague story just produces the wrong thing sooner.
I bring that view into every training engagement, because I still manage teams as well as train them. The shared way of working matters more than any one person's speed.
Who actually joined the training calls
The client groups I train are properly mixed. In the JustSolve groups, alongside developers there was a QA lead, a PMO coordinator, someone from marketing, someone handling admin, and a designer. Each person arrived with a real task from their own job. The QA lead wanted help with test case design. The PMO coordinator wanted project health checks. The marketer wanted a monthly performance report for leadership. One developer wanted to get productive faster in an unfamiliar codebase.
A mix like that changes the training. Examples have to make sense to people who don't read code, so the fundamentals get explained in plain terms. Developers hear how the tester and the analyst think about the same feature. And the non-developers stop seeing the AI tools as something that belongs to engineering.
One spec, written by the whole team
The masterclass runs on a single product idea that flows through all eight sessions. The product idea starts as a short pitch, an overview.md that teams present to the business for approval. In the second kick-off session, everyone turns that approved pitch into a product requirements document (PRD) and the top user stories, using a skill that acts like a product-owner coach. The skill reads the pitch, asks the team the questions it can't answer on its own, scores how ready the PRD is out of 100, and writes the story files with acceptance criteria and pass and no-pass examples.
Each team works from one shared machine with a single driver. Everyone else supplies context, challenges the scope and watches how the skill behaves. The single driver is deliberate. The product person knows why the feature matters. The tester knows which examples will expose a vague requirement. The developer knows which part of the stack will push back. When those people sit together while the spec is written, the PRD comes out sharper than any one of them would manage alone.
That spec then carries through the rest of the programme: project context, design decisions, acceptance tests, verification, and finally a hackathon demo. Nobody starts from a blank page in session one, and nobody builds against a requirement they never saw.
Where the group splits, and why the split is fine
Training everyone together doesn't mean pretending everyone does the same work. The checkpoint survey after the first kick-off showed a clear split. Some people would touch code: building from specs, designing QA test cases, reading unfamiliar codebases. Others never would: marketing reporting, PMO automation, admin and file cleanup.
So the second kick-off has two halves. The first hour, pitch to PRD, is for everyone and reaches a clean stopping point at the 60-minute mark. The second hour is optional git training, for the people who will work in a repository and anyone unfamiliar with git. Non-code participants leave after the first hour with a started PRD and a checklist. Nobody is pushed out, and nobody sits through an hour that has nothing to do with their job.
The team agreements at the end of the masterclass make the same point. One of the eight areas each team agrees is "kinds of work": discovery, design, tests, documentation, evidence capture, delivery and the presentation all count, and someone has to own each of them. Code is one kind of work among several.
Every function leaves with its own skill backlog
Each team leaves with a backlog of skills to build next, and the backlog is split by function. Product people get ideas such as a PRD clarifier and a scope slicer. Business analysts get a story splitter and an acceptance criteria coach. UX gets a user-flow reviewer and an accessibility scenario checker. Architecture gets a decision record writer. QA gets an acceptance test generator and a flaky test investigator. Tech leads get a plan reviewer and a PR reviewer. Operations and support get a runbook checker and an incident context builder.
A skill is a written-down way of doing a job that Claude follows the same way every time. I cover how to build one in turning repeated work into a skill. The point here is that every role on the team has repeated work worth capturing, and each person is best placed to capture their own.
The fundamentals carry across roles
What surprised some participants was how much of the core material applied to them regardless of job title. Jacqui, from the business team, put it this way:
"I found the fundamentals really stuck with me as I found this could transfer across roles and made sense to how I apply it to my work. Once I started testing and applying it, I found what worked for me."
Bryce, from the product team, described a change in how their work was organised:
"The lessons also helped me better comprehend the structure and way to use it that better defines and supports my way of work, rather than how I duplicated and scattered work prior to the classes."
The designers are the ones I watch most closely. Before the first session, one designer told me they sometimes felt they weren't really doing the work because they don't follow the code. At the end of the programme, that designer wrote:
"I have just become way more efficient really...this course has made a big difference in the way that I work."
A course pitched at developers would have left that designer exactly where they started.
What this means if you manage an engineering team
If you are an engineering manager weighing up AI training, these are the decisions I would make first.
- Enrol the roles around the code. Product owners, analysts, testers and designers shape what the developers build. If they keep working the old way, what the developers gain is lost again at every handoff.
- Train on one real piece of work. A shared product slice gives everyone the same reference point, and the spec they write together becomes the thing they build against.
- Plan for the split. Some content is for everyone and some is only for people who touch code. Design the sessions so each person can leave cleanly once the part that concerns them is done.
- Ask each function for its own backlog. Adoption sticks when every role has its own repeated work captured, owned by the person who does it.
Buying licences for the whole team is the easy part. I wrote more about what usually happens next, and what to do about it, in AI adoption after the licences.
Train the team together
My programme for engineering teams trains developers, testers, analysts, designers and product people side by side, on your own product and your own work. If you want to talk through whether the programme fits your team, book a conversation and I'll tell you plainly what I think.