The Gap Inside The Room: Designing AI Programmes For Mixed Expertise

The real divide is not between advanced firms and slow firms. It is inside the room. Three people are already automating work, twelve have tried a chatbot, and twenty-five are watching carefully because they do not want to look incompetent. Treat that group as one level and the session fragments within an hour. In a typical finance workshop, one analyst arrives with a working reconciliation script while a business partner is still deciding what data can safely enter the tool. The analyst becomes bored. The business partner goes quiet. The programme reports forty attendees trained, although neither person moved. The useful unit of analysis is not the organisation, function or grade. It is the spread of capability within the cohort. Design for that spread from the start, because averages conceal the exact people the programme is supposed to help.

Separate beginner and advanced tracks look efficient. They usually harden the gap. The beginner label tells one group they are behind before the work starts. The advanced label tells another that fundamentals no longer apply to them. Both groups then protect the identity they have been assigned. Consider a procurement team split by self-assessment. The advanced room jumps straight into agent workflows but skips basic evaluation, producing a supplier-summary tool that invents missing contract dates. The beginner room spends two hours learning interface features and never touches an actual sourcing decision. One group ships unsafe work. The other ships nothing. Mixed expertise creates friction, but that friction is useful when the method is shared. Experienced participants are forced to explain their choices. Newer participants see what competent practice looks like in context. The answer is not separate ladders. It is one ladder with different starting rungs.

The opening determines whether the expertise spread becomes an asset or an embarrassment. Name it plainly. I use a version of this script: “Some people here have built working automations. Some are using these tools for the first time. That range is deliberate. Everyone will build something real, and nobody is expected to solve the same problem in the same way.” Then prove the claim with the first exercise. Give the room ten minutes to turn a messy meeting note into three decisions, owners and deadlines. A fluent user may create a reusable extraction prompt with a validation step. A newer user may produce one reliable output manually. Both have completed the same unit of work at different depths. This opening removes the hidden contest over who already knows what. It establishes the programme’s contract: shared outcomes, visible methods and progression from each person’s actual starting point.

Mixed groups work when everyone uses the same method, even when their technical depth differs. The method should be simple enough to remember: define the task, identify the evidence, produce an output, test it, then decide who owns the result. In one live delivery, a five-person cohort included an engineer, two operations leads, a policy specialist and a colleague who had never written a prompt. They built an incident-triage workflow together. The policy specialist defined the escalation rules. The engineer connected the data source. One operations lead created test cases. The newer participant ran each output against the original incident record and found two confident misclassifications. That discovery changed the design. Nobody was reduced to observing the expert, because each stage had a named contribution and a common vocabulary. Fluency accelerated the build. Domain knowledge made it useful. Structured testing stopped it becoming theatre.

Peer learning fails when it means asking the strongest person to rescue everyone else. That creates a queue, not a learning system. Use pairs with rotating roles: one person operates, one person challenges. The operator must explain the next action before taking it. The challenger checks the evidence, asks what could fail and records the reusable step. Then they switch. For example, pair a confident marketer with a cautious compliance manager to build a campaign-review assistant. In the first round, the marketer produces draft claims quickly while compliance tests each one against the approved source. In the second, compliance operates the tool and the marketer turns the review sequence into a repeatable template. Expertise moves sideways because the task requires both kinds of judgement. The facilitator intervenes only when the pair cannot resolve a specific blockage. That keeps ownership in the room and makes teaching part of delivery rather than a separate activity.

Attendance is not capability. Satisfaction is not capability either. The test is whether each person can build and explain something useful by the end of day two. Require one individual artefact tied to real work: a tested prompt, a small workflow, an evaluation set or a documented automation. A customer-service manager might build a complaint-classification prompt using twenty anonymised cases, record four failures, revise the categories and show when a human must take over. The evidence is the artefact, the test results and the explanation of its limits. Record the starting point as well: what the person could complete without assistance before the programme and what they can complete afterwards. The fluent participant should improve rigour. The newer participant should gain independent execution. A programme succeeds when the floor rises for everyone at once. Anything less is a demonstration with an attendance sheet.